Zbornik konferencije CASE23 - Case doo

ORGANIZATORI

MINISTARSTVO ZNANOSTI, OBRAZOVANJA I ŠPORTA CASE d.o.o.

ORGANIZACIJSKI I PROGRAMSKI ODBOR

TOMISLAV CAR mag. ing. el. TOMISLAV BRONZIN

ANTE POLONIJO MISLAV POLONIJO

MR.SC. IVAN POGARČIĆ mag.inf. ZLATKO STAPI Ć

Izdavač: CASE d.o.o., Rijeka

Urednik: Mislav Polonijo

Priprema za tisak: CASE d.o.o., Rijeka

Tisak: CASE d.o.o., Rijeka

ISSN 1334-448X UDK 007.5 : 621.39 : 681.324

Copyright "Case", Rijeka, 2011

Sva prava pridržana. Niti jedan dio zbornika ne smije se reproducirati u bilo kojem obliku ili na bilo koji način, niti pohranjivati u bazu podataka bez prethodnog pismenog dopuštenja izdavača, osim u slučajevima kratkih navoda u stručnim člancima. Izrada kopija bilo kojeg dijela zbornika zabranjena je.

Case d.o.o., Šetalište XIII divizije 28, 51000 Rijeka tel: 051/217-875, tel/fax: 051/218-043, e-mail: [email protected], internet: www.case.hr

S A D R Ž A J CASEdev - RAZVOJNE TEHNOLOGIJE

� SOA I WEB USLUGE: ANALIZA PRIMJENJIVOSTI U POSLOVNOJ PRAKSI prof.dr.sc. Vesna Bosilj Vukši ć, mr.sc. Natalija Merzel, Ivan Paradinovi ć 5

� SOA I POSLOVNA PRAVILA Zlatko Siroti ć 13

� SIGURNOST U SERVISNO ORIJENTIRANOJ ARHITEKTURI mr.sc. Tomislav Vida čić , dr.sc. Sandro Geri ć 27

� ALATI ZA RAZVOJ APLIKACIJA BEZ KODIRANJA Dražen Vukoti ć, Nikola Tankovi ć 35

� AGILNO UPRAVLJANJE I OPTIMIZACIJA POSLOVNIH PROCESA mr.sc. Darije Ramljak 45

� TEHNIČKO VODSTVO U DJELATNOM RAZVOJU SOFTVERSKIH PROJEKATA Nikola Stjelja 49

� DA LI ODABRATI HTML5 ILI SILVERLIGHT ILI FLASH ZA WEB, MOBILE I DESKTOP? Dobriša Adamec, mag. ing. el. Tomislav Bronzin 55

� EVALUACIJA I KOMPARATIVNA ANALIZA O/RM ALATA Ivan Renduli ć 61

� OPENOBJECT - PLATFORMA ZA RAZVOJ POSLOVNIH APLIKACIJA Goran Cvijanovi ć 67

� JASPER REPORTS I OPEN REPORTS - ALAT I PLATFORMA ZA IZVJEŠTAJNE SUSTAVE Ksenija Bastijani ć Cvijanovi ć 75

� ONTOLOGIJA I RAZVOJ INFORMACIJSKOG SUSTAVA U JAVNOJ UPRAVI Karmen Klarin 81

� OBRASCI MODELIRANJA PODATAKA – TAKSONOMIJA Vladan Jovanovi ć, dr.sc. Mile Pavli ć, Martina Ašenbrener 87

CASEmobile - MOBILNE RAZVOJNE TEHNOLOGIJE I RJEŠENJ A

� USPOREDBA RAZVOJA MOBILNE APLIKACIJE NA NOKIA QT I MICROSOFT WP7 PLATFORMAMA mag.inf. Zlatko Stapi ć, Josip Vincek, Zoran Šaško, Miroslav Zver

93

� KAKO POVEZATI MOBILNE UREðAJE SA CLOUD-OM? mag. ing. el. Tomislav Bronzin, Vedran Kaldi 101

� RAZVOJ APLIKACIJA ZA ANDROID PLATFORMU Ognjen Ribi čić, mag.inf. Boris Tomaš, mag.inf. Zlatko Stapi ć 107

� GOOGLE APPS MOBILNE APLIKACIJE Adriana Baranek 117

CASEcloud - CLOUD COMPUTING POSLOVNA INTELIGENCIJA

� KRITIČNI FAKTORI USPJEHA IMPLEMENTACIJE ERP SUSTAVA Damir Stepani ć, prof.dr.sc. Katarina Ćurko 123

� PRIMJENA INTELIGENTNOG INTEGRALNOG INFORMACIJSKOG SUSTAVA ZA OPTIMIZACIJU PROIZVODNOG PROGRAMA prof. dr. Kova č Dragan

135

� PRIMJENA POSLOVNE INTELIGENCIJE U OSIGURANJU mr.sc. Boris Draženovi ć, Martina Draženovi ć 143

� HIJERARHIJSKI PRIKAZ SHEME BAZE PODATAKA KAO TEMELJ ZA PRETRAŽIVANJE, RUDARENJE I OLAP mr.sc. Marin Kaluža, Dino Abazovi ć

165

� INTEGRACIJA WINDOWS PHONE7 APLIKACIJA S AZURE OBLAKOM PUTEM CSLA.NET POSLOVNE LOGIKE mag.inf. Zlatko Stapi ć, Matija Besednik, Ivan Curi ć, Kristijan Kralj, Kristina Samoš ćanec

171

� INFORMATIKA IZ OBLAKA I BAZE PODATAKA – TRENDOVI I OČEKIVANJA mr.sc. Damir Vuk 179

� CLOUD COMPUTING: ŠTO S BAZOM PODATAKA (U OBLACIMA)? Vlatka Davidovi ć, Elvis Kukuljan, mr.sc. Ivan Pogar čić 185

� WINDOWS AZURE – RAČUNALSTVO U OBLAKU NA MICROSOFT PLATFORMI mag. ing. el. Tomislav Bronzin, Dobriša Adamec 191

� PRIHVAĆANJE, PROVEDBA I RIZICI CLOUD COMPUTING - „STATE OF ART“ – STANJE STVARI 2011 Miho Pitarevi ć

199

� UPRAVLJANJE ZNANJEM: PRIMJER IZ HRVATSKE POSLOVNE PRAKSE prof.dr.sc. Vesna Bosilj Vukši ć, mr. Adrian Špoljar, mr. Helena Štulina 205

� EKONOMIKA CLOUDA Berislav Bio čić, Draško Tomi ć, Dario Ogrizovi ć 215

UVOD 3

CASE 23 - UVOD

Udarne teme ovogodišnje CASE23 konferencije su: SOA, Agilne Metodologije, Razvoj mobilnih aplikacija, Cloud Computing i BI rasporeñene u tri dana sa odvojenim blokovima tema. Svaki blok sastoji se od više predavanja (ukupno 27), radionice (ukupno 6) i seminara (ukupno 7) uz jedan okrugli stol te se mogu odvojeno pratiti.

SOA – 06.06.

Servisno orijentirana arhitektura (SOA) je relativno novi koncept IT-a koji monolitne i statičke sustave (inkompatibilna rješenja) transformira u modularne, povezane i fleksibilne komponente. Naglasak je na višestrukom korištenju servisa od kojih se “slažu” aplikacije. Uvodno predavanje “SOA i web usluge…” daje teorijski okvir servisne arhitekture, njene elemente i utjecaja na sudionike u procesu razvoja IT i transformacije poslovne prakse. Prikazati će se Web servisi kao momentalno najpopularnija tehnologija za SOA dizajn u stvaranju dinamičkih aplikacija. Analiziramo koristi od primjene SOA-a kao i faktore koji utječu uspješnost i sigurnosti.

AGILNE METODOLOGIJE – 06.06.

Standardni načini razvoja procesno orijentiranih IS nisu uspjeli dovoljno kvalitetno spojiti poslovnu i IT stranu rješenja. Novi agilni pristup razvoju (upravo je deseta obljetnica “Agile Manifesta”) evoluirala je i pridonosi razvoju software novom praksom. Prikazati ćemo napredne koncepte i mehanizme za agilni razvoj i upravljanje poslovnim procesima, njihovu iterativnu optimizaciju fokusiranu na poboljšanje suradnje poslovnih korisnika i IT-a.

Na radionici o agilnim metodama razvoja softvera sudionici će se upoznati sa temeljima agilnih metoda razvoja i elementima agilnih metoda (vizija, korisničke priče, prioriteti, iteracija, retrospektiva i slično). Microsoft se takoñer sve više orijentira na agilne metode i principe pogotovo s novim Team Foundation Serverom (TFS) 2010. Biti će prikazane i besplatne i/ili open source ekvivalentne aplikacije i komparacija glavnih značajki. Imati ćemo i radionicu namijenjenu MS razvojnim inženjerima

RAZVOJNI ALATI i PLATFORME 06.06.

Penetracija računalne opreme raste i već imamo više računala po korisniku (ako uključimo i "pametne telefone"). Potrebno nam je jednostavno i intuitivno modeliranje, izrada i isporuka vlastitih ili modifikacija postojećih aplikacija (za stolna i mobilna računala). To postižemo razvojnim alatima (za izradu aplikacija) bez poznavanja specijalističkih znanja o programiranju.

Ako želimo razvijati aplikacije za „tri ekrana“ (stolna računala, mobilni ureñaji, televizija), koju tehnologiju odabrati, kakvu produktivnosti ćemo imati? Prikazati ćemo najzastupljenije komercijalne alate, njihove funkcije i njihovu komparativnu analizu. Pokazati ćemo organizaciju i OpenObject platforme i primjenu razvojnih mogućnosti kroz prikaz arhitekture modula OpenERP.

Radionica o iskustvima i primjerima razvoja Silverlight aplikacija pomoću RAD tehnika prikazuje upotrebu različitih obrazaca programiranja i arhitektura, potrebna

znanja i tehnike (za web i desktop programere) a radionica Adobe Flash/AIR obraditi će jedinstvenu razvojnu platformu koja omogućava izradu desktop aplikacija za sve veće PC operativne sustave te aplikacija za mobilne ureñaje Android, iOS i BlackBerry Tablet OS.

Organizacije su jako ovisne o ICT (proizvodne, neproizvodne, javne ustanove…) što predstavlja potencijalnu opasnost za njihovo funkcioniranje. Treba provjeriti prijetnje i procijeniti njihovu važnost za poslovanje, ranjivosti itd. Trebaju se uspostaviti korektivne i preventivne radnje (obveza po ISO 9001:2008).

MOBILNE APLIKACIJE 07.06.

Od ne tako davne 2006. g. pratimo ekspanziju mobilne tehnologije koja se razvija neslućenom brzinom a posebno oduševljava njihova primjena kroz mobilne aplikacije. Na tržištu postoje stotine tisuća zanimljivih aplikacija, te se stoga postavlja pitanje - što ponuditi korisniku, kojim putem krenuti i koju platformu odabrati? Odabir tehnologije je trenutno zbog fragmentiranosti tržišta i najvažnije pitanje za početak: da li iPhone, Android, Nokia, Blackberry, Windows Phone 7 i druge platforme s različitim mogućnostima i svojstvima. U samo 5 godina stvorena je jaka konkurencija meñu platformama (o tome će se održati okrugli stol).

Izlaskom Appleovog iPada 2010.godinu je označio razvoj tablet industrije koji je u mnogočemu revolucionarno pokrenuo cijelu industriju aplikacija za njega. Pozvano predavanje predstaviti će što uključuje razvoj za iPad (njegove kopije) te koliko se taj proces razlikuje od razvoja PC ili razvoja mobilnih aplikacija? Kako pristupiti razvoju iPad aplikacija, sa stajališta dizajna i implementacije.

Razvoj utemeljen na otvorenom kodu za Android mobilne ureñaje rezultirao je velikim interesom za ovu platformu (jednog od najpopularnijih mobilnog operativnog sustava - Android Market trenutno sadrži više od 200.000 aplikacija) pa smo uvrstili u program konferencije, predavanja, radionicu i seminar. Android seminar objasniti će proces razvoja programskog proizvoda mobilne ureñaje, od podešavanja razvojnog okruženja, razvoja programskog proizvoda, testiranja i objave proizvoda na tržište.

A kako povezati mobilne aplikacije s oblakom? Imamo predavanja o složenijim poslovnim aplikacijama (mobilnim rješenjima za Windows Phone 7, iPhone, Android, Symbian, Badu ili druge mobilne platforme) koje se oslanjaju na podatke iz oblaka u pozadini (privatni ili javni).

Flash platforma je skup alata i runtime okolina koji omogućavaju izradu aplikacija u svijetu poslovnih aplikacija, industriji igara, distribuciji audio-vizualnih sadržaja te izradi ostalih vrsta interaktivnih sadržaja (za desktop, tablet, smartphone ureñaje i potrošačku elektroniku). Na seminaru “Razvoj sa Adobe Flex i Flash platformom” dati će se osnove razvoja i prikazati ćemo i jednostavan način integracije Flash klijentskih aplikacija sa Java i PHP serverskim okolinama.

Silverlight .NET tehnologija za mobilne ureñaje (Windows Phone 7) obraditi će se na seminaru

4 UVOD

korištenje, preko web aplikacija u raznim pretraživačima (FireFox, IE; Windows/Mac) do „pravih“ monolitnih/samostojećih Windows aplikacija bez obzira radi li se o desktop, web ili mobilnim projektima.

Kako bi i na mobilnim telefonima poslovni korisnici bili produktivni Google je razvio brojne mobilne aplikacije za Google Apps koje omogućavaju da i u pokretu komunicirate, organizirate se i surañujete sa svojim suradnicima.

POSLOVNO INFORMIRANJE (BI) 08.06.

Današnji ERP sustavi podržavaju širok spektar industrija i nastavljaju ugrañivati sve više funkcionalnosti za poduzeća. Kako bi implementacija ERP sustava bila uspješna potrebno je pravilno izbalansirati kritične faktore uspjeha. ICT je podrška obavljanja svakodnevnih poslovnih aktivnosti, obavlja skladištenja podataka i njihovo korištenje, no korisnik želi i nestandardizirane informacije iz svog poslovnog sustava. Implementacija analitičkih aktivnosti na sustav (OLAP), zahtjeva umijeće čitanja sheme baze podataka i poznavanje postupaka čitanja podataka (SQL). Kako korisnik „gleda“ na podatke u svom sustavu? Moguće je korisniku ponuditi standardizirani pogled na sve podatke iz baze podataka njegovog IS-a. Na konkretnom primjeru prikazati će se postupak rješavanja i problema optimizacije proizvodnog programa a u okviru integralnog sustava upravljanja poslovanjem.

CLOUD COMPUTING 08.06.

Za krajnjeg korisnika Cloud computing predstavlja mogućnost korištenja infrastrukture, podataka i aplikacija van okvira organizacije uz znatno niže troškove. Istražujemo mogućnosti kao i ograničenja koja cloud donosi. Poslovne aplikacije korištene u cloudu promatraju se kao servisi koji se mogu naslanjati na baze podataka kao i na cjelokupnu infrastrukturu koja nalazi negdje u cloudu, nalaze se „negdje“ u „nekoj“ bazi podataka. U kakvoj je to vezi sa trendovima koje donosi informatika iz oblaka? Zbog opsluživanja velikog broja korisnika, pojavljuju se problemi skalabilnosti i performansi, te se sve više razmatraju objektne i NoSQL baze podataka, odnosno reducirani sustavi za upravljanje podacima.

Trenutno Cloud computing prolazi kroz početnu fazu a put do zrelosti ne vodi ravno. Zanimljivo istraživanje učinjeno je prošle godine u SAD-u a pokazatelji će biti prikazani u predavanju. Sigurnost je jedan od brojnih briga potencijalnih korisnika. Na sastanku na vrhu u ADS Infosecurity Europe, Cloud Security Alliance (CSA) je

najavila da će imati ključnu ulogu u razvoju sigurnosti u „oblaku“ (cloud-u) i privatnosti i pripremaju se novi standardi ISO/IEC.

Uz doba cloud computing dolazi i sve više i više aplikacija se isporučuje kao daljinski „hostane“ i upravljane usluge. Potražnja za upravljanjem Web učincima i uslugama testiranja raste. U svibnju 2011 EU je počeo konzultacije o Cloud computing utjecaju na Europu (dio Digital Agenda procesa), tj. radi se Europska cloud computing strategija koju će Komisija predstaviti u 2012. Ova strategija će imati za cilj razjasniti zakonske preduvjete razvoja cloud computing-a u Europi, potaknuti razvoj konkurentnoga europskog odgovora i zamaha cloud industrije i tržišta, te olakšati uvoñenje inovativnih usluga cloud computinga za grañane i poslovne subjekte.

Virtualizacija i računalstvo u oblaku donosi velike mogućnosti za korisnike, bolje iskorištenje vlastitih IT resursa i/ili korištenje vanjskih resursa kroz Cloud computing. U prezentaciji će se prezentirati neka od sigurnosnih rješenja za rad u “oblaku” a koja ne zahtijevaju dedicirane korisničke resurse, te rješenje za zaštitu virtualne okoline. Stvorena je nova generacija sigurnosnih rješenja koja iskorištava prednosti virtualizacije i rješava specifične opasnosti i probleme koji prijete virtualnim okolinama.

Microsoft Windows Azure platforma, predstavlja svojevrsni novi "globalni" operativni sustav i donosi niz novih koncepata za razvoj aplikacija Cloud Computinga. Predavanje i seminar su namijenjeni razvojnim inženjerima sa prikazom razvoja Azure aplikacija i funkcionalnosti Windows Azure okoline. Polaznici seminara će proći korake za kreiranje Azure aplikacije, njezino postavljanje na Windows Azure okolinu i praćenje rada Azure aplikacije.

Zahvaljujemo svim predavačima i pokroviteljima (CITUS, FOI, IEEE, Veleučilište u Rijeci, Infoprogres) do kojih je u ova krizna vremena zaista teško doći. Poslušajte predavanja, pitajte predavače i razmijenite iskustva sa kolegama. Cjelovite informacije o temama savjetovanja su u zborniku radova ili na konferencijskom CD-u (sa prezentacijama) te na internetu: www.case.hr .

Ugodan i koristan boravak na konferenciji a očekujemo vas i iduće godine u isto vrijeme na CASE24 (pripremite vaša izlaganja!). Ispunite anketu kako bi mogli poboljšati iduću konferenciju.

Tajnik organizacijskog i programskog odbora Ante Polonijo, dipl.ing., dipl.oecc.

Podaci o autoru:

Ante Polonijo, dipl.ing., dipl.oecc. CASE d.o.o., Šet. XIII divizije 28 51000 Rijeka, Croatia tel. +385 51 217 875 fax. +385 51 218 043 e-mail: [email protected]

PROFESIONALNA KARIJERA: -predavao Električna mjerenja na srednjoj stručnoj školi za elektroniku, programirao u Cobol-u u “Inžinjerskom birou” (u Zagrebu), organizator informatike i 13 godina šef ERC-a u “HEP DP Elektroprimorje” Rijeka te šef organizacije i programiranja u DINI Omišalj. Od 1986-2009.g. radi u HGK Županijska komora Rijeka na radnom mjestu savjetnika informatike i statistike, te voditelja odsjeka makroekonomske analize. (Paralelno od 1990-94 radio 1/3 radnog vremena kao voditelj grupe za informatiku u remontnom brodogradilištu “V.Lenac”). - Od 2009.g. - Konzultant u tvrtci CASE na poslovima organizacije školovanja i Konferencija (Razvoj SW-CASE, Komunikacijske tehnologije-KOM, e-business-a –e-BIZ, SmartCard, Privatnost). -Bio dugogodišnji član upravnog odbora Hrvatskog informatičkog zbora (udruge informatičara HR), zadužen za školovanje korisnika (ECDL licenca) i organizacija konferencija.

CASEdev - RAZVOJNE TEHNOLOGIJE 5

SOA I WEB USLUGE: ANALIZA PRIMJENJIVOSTI U POSLOVNO J PRAKSI

SOA AND WEB SERVICES: ANALYSIS OF THE APPLICABILITY IN BUSINESS PRACTICE

prof.dr.sc. Vesna Bosilj Vukši ć, mr.sc. Natalija Merzel, Ivan Paradinovi ć

SAŽETAK:

Servisno orijentirana arhitektura (SOA) je novi koncept u informacijskoj tehnologiji koji organizacijama donosi nove mogućnosti i prilike u uvjetima globalne konkurencije. SOA je princip softverskog dizajna koji monolitne i statičke sustave transformira u modularne i fleksibilne komponente. Koristeći ovu tehnologiju, poduzeća mogu unaprijediti fleksibilnost i prilagodljivost informatičke podrške.

S druge strane, u proteklom je razdoblju većina organizacija nakupila zbirku neefikasnih i inkompatibilnih informatičkih sustava i rješenja kod kojih svaka modifikacija može imati neželjene i nepredvidive posljedice. U doba Interneta, u situacijama kada se treba nositi sa velikim brojem dobavljača i poslovnih partnera, ili sa stotinama Web korisnika, tradicionalni pristupi programiranju pokazali su se nepraktičnima.

Ovaj rad daje pregled teorijskog okvira servisne arhitekture, njezinih obilježja i utjecaja koje ima na sudionike u procesu razvoja i transformacije poslovanja. Prikazani su Web servisi kao momentalno najpopularnija tehnologija za implementaciju SOA dizajna u stvaranju dinamičkih aplikacija. Analizirane su koristi od primjene SOA-a kao i faktori koji utječu na njezinu uspješnost. Opisani su neki primjeri i izazovi primjene Web servisa u poslovnoj praksi.

ABSTRACT:

Service Oriented Architecture (SOA) is a new concept in information technology that brings organizations new possibilities and opportunities in the environment of global competition. SOA is a software design principle that converts monolithic and static systems into modular and flexible components. Using this technology companies can improve IT flexibility and adaptability.

On the other hand, over past years, most companies have accumulated inflexible and incompatible collections of IT systems and applications in which modifications can have unintended and unpredictable effects. In the age of the Internet, it quickly became impractical to apply the custom approach when dealing with a great number of suppliers and business partners, or with hundreds of Web users.

This paper gives an overview of the SOA framework, its characteristics and influence on the participants in the process of business development and transformation. Web services, as the most popular technology for implementing SOA applications and design are presented. The benefits and the critical success factors of SOA implementation are analyzed. Some well known examples and challenges of Web services and SOA implementation in business practice are elaborated.

1. UVOD

U globalnoj poslovnoj zajednici servisno orijentirana arhitektura danas predstavlja vruću i još uvijek nedovoljno razrañenu temu. Ideja servisno orijentirane arhitekture postoji već više godina, ali je sam izraz SOA (Service Oriented Arhitecture) još uvijek novost u poslovnim krugovima. No iako su vodeći isporučitelji poslovnog softvera najavili strateški zaokret upravo u tom smjeru, rijetka su sustavna objašnjenja tog koncepta informatičke industrije. S druge strane, teško je objasniti koncept servisno orijentirane arhitekture jer se radi o čitavoj koncepciji, pa i filozofiji informacijske tehnologije koje omogućava spajanje različitih sustava i ponovno korištenje dijela starih aplikacija u kombinaciji s novim kompozitnim aplikacijama.

Ovaj rad daje pregled teorijskog okvira servisne arhitekture, njezinih obilježja i utjecaja koje ima na sudionike u procesu razvoja i transformacije poslovanja. SOA donosi mnogobrojne nove pojmove, elementa, načela i standarde. Rad se ne bavi tehničkim aspektima servisno orijentirane arhitekture, već razmatra prednosti, eventualna ograničenja, odnosno izazove pri njezinoj implementaciji u poslovnoj praksi. Prikazani su Web servisi kao momentalno najpopularnija tehnologija za

implementaciju SOA dizajna u stvaranju dinamičkih aplikacija. Analizirane su koristi od primjene SOA-a kao i faktori koji utječu na njezinu uspješnost. Opisani su neki primjeri i izazovi primjene Web servisa u poslovanju.

2. ŠTO JE SERVISNO ORIJENTIRANA ARHITEKTURA?

2.1 Pojam servisno orijentirane arhitekture

Vjerojatno najkompetentnija a ujedno i najšira definicija servisno orijentiranog pristupa u razvoju informacijskih sustava dana je u referentnom modelu servisno orijentirane arhitekture predstavljenom od strane tehničkog odbora zaduženog za ovu tematiku unutar Organizacije za unapreñenje strukturiranih informacijskih standarda (OASIS). Definicija (OASIS, 2006) kaže da je: "Servisno orijentirana arhitektura (SOA) izraz za organiziranje i korištenje distribuiranih usluga koje mogu biti pod kontrolom različitih vlasničkih domena."

Definicija koju je dao IBM (2010) kaže: „Servisno orijentirana arhitektura (SOA) je poslovno orijentiran pristup dizajnu informacijskih sustava koji podržava integriranje poslovanja kroz povezane, ponovljive

6 CASEdev - RAZVOJNE TEHNOLOGIJE

poslovne zadatke ili servise koji su dostupni preko mreže.“ U ovoj se definiciji naglašava da se radi o poslovno orijentiranom pristupu dizajnu informacijskih sustava. Servisno orijentirana arhitektura je pojam koji se koristi upravo u procesu dizajna informacijskih sustava. Iako danas imamo alate i razvojna okruženja koja omogućavaju razvoj kompletnih informacijskih rješenja na bazi servisa, ovaj način dizajna trebao bi prvenstveno premostiti jaz izmeñu postojećih aplikacija i novih tehnologija ili pak meñu aplikacijama proizašlim iz različitih razvojnih okruženja. Korisnici aplikacija koje su razvijene kao servisi nemaju informaciju o tome na kojem one operativnom sustavu rade niti koje resurse koriste. Jedino što zanima korisnika je da li usluga koju pruža servis zadovoljava njegove potrebe. Servisi se pronalaze na mreži i ugrañuju u postojeće ili nove informacijske sustave te postaju grañevni elementi njihovog dizajna.

Prema Natis i Schulte (2003) Gartner, Inc. Stamford, Connecticut, U.S.A., jedna od vodećih konzultantskih kompanija na području informatičke tehnologije, definirala je servisno orijentiranu arhitekturu kao „vrstu složenog programiranja koje organizacijama omogućava da dijele logiku i podatke meñu raznim aplikacijama i korisničkim modelima“. Ova definicija u centar stavlja karakteristiku servisno orijentirane arhitekture da služi kao most meñu različitim aplikacijama koji im omogućava dijeljenje softverskih rješenja i informacija.

W3C, internacionalni konzorcij za razvoj Web standarda, u svom rječniku pojmova vezanih uz Web servise, dao je definiciju koja kaže da je servisno orijentirana arhitektura: „set komponenti koje je moguće pozvati i čiji opis sučelja je moguće objaviti i pronaći“ (World Wide Web Consortium, 2010). Segment servisno orijentirane arhitekture na koji se ova definicija oslanja spada u njene osnovne postavke. Ponuditelji pojedinih komponenti i potencijalni korisnici moraju biti u mogućnosti vidjeti jedni druge. Opseg tržišta na kojem će se susretati ponuditelji i korisnici može varirati ovisno o vrsti ponude. Može biti lokalnog karaktera, unutar jednog poduzeća, a može biti namijenjen širokoj publici. Shodno tome će i javno objavljeni podaci o servisima imati lokalni (intranet, lokalna mreža) ili globalni (Internet) karakter.

Teško da se u jednoj rečenici mogu izreći svi bitni elementi servisno orijentirane arhitekture. Servisno orijentirana arhitektura u dizajnu softvera ne bavi se procesom proizvodnje programskog koda odnosno klasičnim programiranjem. Ne postoji poseban programski jezik koji bi na neki novi revolucionarni način zamijenio stare metode programiranja. Ono što se promijenilo je okruženje u kojem se odvija poslovanje. Informacijski sustav poduzeća više nije izoliran od vanjskog svijeta i informatička rješenja se moraju prilagoditi novim uvjetima poslovanja. Postoji ekonomska opravdanost, a u nekim uvjetima i nužnost, da se pristup do pojedinih poslovnih funkcija, odnosno korištenje njihovih usluga, omogući i drugim informacijskim sustavima u okruženju. Da bi pojedini dijelovi programa mogli pružati informacije nekompatibilnim sustavima iz okruženja moraju se uspostaviti standardizirana pravila razmjene informacija. Servisno orijentirana arhitektura u dizajnu informacijskih sustava podrazumijeva korištenje distribuiranih dijelova programskog koda odnosno poslovnih funkcija kao softverskih usluga.

2.2 Obilježja servisno orijentirane arhitekture

Servisi su samostalne programske cjeline koje obavljaju neki programski zadatak. Iako općeprihvaćena, ova

definicija nije sasvim točna. Postoji razlika izmeñu servisa i usluge koja se nalazi u njegovoj pozadini. Usluga o kojoj ovdje govorimo je kompjuterski program napravljen da bi se obavio odreñeni posao. Ona kao takva može funkcionirati i izvan servisno orijentirane arhitekture. Servisi koji se kreiraju po pravilima servisne arhitekture predstavljaju vezu izmeñu ovih funkcionalnih programskih cjelina koje obavljaju odreñeni posao i programa koji ih žele koristiti. Servisi su mehanizam koji omogućava pristup jednoj ili nizu usluga koristeći unaprijed definirano sučelje i izvodi se u skladu sa pravilima korištenja koja su navedena u opisu servisa (OASIS, 2006). Pravila gradnje servisa i uspostavljanja veza definirana su propisanim standardima. Web servisi su trenutno najraširenija vrsta servisa razvijenih po principu servisno orijentiranog programiranja. Koriste Internet kao medij za distribuciju, protokole za prijenos kao što je SOAP (Simple Object Access Protocol), WSDL jezik za opis servisa (Web Services Description Language) i BPEL jezik za izvoñenje poslovnih procesa (Business Process Execution Language) koji povezuje servise u funkcionalnu cjelinu (Leymann et al, 2010).

Osim tehničkih uvjeta i standarda koji nisu u fokusu ovog rada, za uspješnu primjenu Web servisa moraju biti zadovoljene tri osnovne pretpostavke: (1) mora postojati mjesto na kojem će se ponuditelji usluga i njihovi korisnici pronalaziti; (2) mora biti omogućena interakcija meñu njima i (3) mora biti poznat rezultat njihove interakcije. Osim toga, karakteristike koje mora imati servis da bi zadovoljio uvijete servisno orijentiranog dizajna softvera su: � Višestruka upotrebljivost. Ako se fokusiramo na

interne procese u postojećoj aplikaciji, svaka operacija koja pretpostavlja manipulaciju podacima može se realizirati kao servis i objaviti u internom katalogu servisa. Srodni postupci pretvoreni u funkcije grupiraju se u jedan servis. Ako servise promatramo sa šireg aspekta i ako im je namjena da se koriste eksterno, od strane vanjskih korisnika, onda se višestruka upotrebljivost podrazumijeva. Servis za koji ne postoje zainteresirani korisnici nema smisla razvijati kao servis niti ga javno objavljivati.

� Slobodno povezivanje. Važan element izgradnje softvera u uvjetima stalnih promjena i sve veće kompleksnosti poslovanja i ono čemu teži teorija servisno orijentirane arhitekture je upravo razvoj standarda i slobodno povezivanje servisa i njegovih korisnika. Slobodno povezani servisi lako se povezuju s aplikacijom a isto tako lako se zamjenjuju nekim drugim servisom ovisno o potrebama poslovnog procesa. Nije potrebno dirati programski kod niti servisa niti aplikacije koja ga poziva. Sve se rješava na komunikacijskom nivou pod okriljem alata za upravljanje koji sustav pozivanja servisa drže pod nadzorom. Slobodno povezivanje znači i da korisnik može birati sa kojim servisom će raditi bez tehnoloških ograničenja. Zahvaljujući slobodnom povezivanju, korišteni servis se može zamijeniti drugim servisom koji obavlja istu funkciju.

� Neovisnost o razvojnoj i korisničkoj platformi korisnika. Činjenica je da poduzeća danas posluju u uvjetima heterogene infrastrukture po pitanju operativnih sustava, instaliranih aplikacija, sistemskog softvera i ostalih programskih alata kao što su baze podataka i slično. Rad preko servisa omogućava razvoj novih modula softvera u novom razvojnom okruženju i povezivanje sa postojećim informacijskim sustavom preko standardiziranog


sučelja. Nove poslovne funkcije tako se jednostavno nadovezuju na postojeći sustav bez obzira na razlike u razvojnom okruženju pojedinih programskih dijelova. Servisi se angažiraju bez da pozivatelj zna tehnologiju na kojoj su razvijene njihove funkcije. Jedini dio servisa koji je vidljiv korisniku je onaj koji se javno objavljuje kroz opis i definiciju servisa te uvjete njegova korištenja. Logika funkcioniranja programa kroz koje se realiziraju pojedine funkcije servisa ostaje skrivena od korisnika.

� Mogućnost komponiranja u složenije sustave. Servisi nisu zamišljeni i nisu napravljeni da bi funkcionirali samostalno. Kombiniranje servisa još je jedan doprinos ideji o višestrukom korištenju programskog koda. Korisnik ni po čemu ne može znati da li je servis koji trenutno koristi samostalna cjelina ili je složen od drugih servisa. Takva situacija čini složenijim pitanje pouzdanosti sustava. Kad je servis složen od više servisa i sustav je distribuiran, veća je vjerojatnost da će doći do problema u funkcioniranju jer više sudionika u transakciji znači i veću mogućnost da neki od njih neće biti dostupan.

� Servisi moraju biti dostupni preko mreže. Pristup do servisa mora biti omogućen preko mreže. Ako su ponuditelj servisa i korisnik servisa na istom računalu, mreža nije potrebna da bi se ostvarila interakcija. Bez obzira na tu činjenicu, servis mora biti napravljen tako da podržava mrežni pristup.

� Servisi moraju biti neovisni o fizičkoj lokaciji. Jedan od podataka koji je nužno navesti u opisu servisa prilikom njegova objavljivanja u katalogu je njegova lokacija na mreži. Lokacija servisa je promjenjiva kategorija. Korisnici servisa ne moraju pozivati servis koristeći njegovu apsolutnu adresu na mreži. Lokacija servisa može biti dinamički podatak koji se čita provjerava svaki put kad se poziva servis.

� Servisi moraju biti opisani i objavljeni. Jedino što servis treba objaviti da bi potencijalni korisnici mogli stupiti u interakciju sa njime su opis servisa i uvjeti razmjene podataka. Servis se u svakom momentu može pojaviti u registru servisa i u svakom momentu se može odjaviti. Korisnici su ti koji se moraju nositi s tom pojavom. Nekad će se dogoditi i ekstremne situacije u smislu da u registru neće biti niti jednog odgovarajućeg servisa ili da će ih biti više. Najrjeñe će se dogoditi idealna situacija da se nudi jedan servis i da je taj upravo onaj pravi.

� Servisi moraju imati odgovarajuću razinu kvalitete. Kvaliteta servisa se mjeri postignutim stupnjem pouzdanosti, raspoloživosti i sigurnosti u pogledu prijenosa podataka te zadovoljavajućim vremenom odaziva na upit.

3. WEB USLUGE: PRIMJENA I ISKUSTVA IZ POSLOVNE PRAKSE

3.1 Implementacija servisnog rješenja

Proces dizajniranja softvera na bazi servisa započinje onim što i inače pokreće poslovanje a to je potražnja. Stranu koja izražava potrebu za gotovim, univerzalno primjenjivim, softverskim rješenjima možemo identificirati kao jednog od dva osnovna sudionika u procesu razvoja softvera na principima servisno orijentirane arhitekture. Druga strana je strana ponude. U trenutku kad su se ispunili tehnološki preduvjeti pojavila su se rješenja kojima je cilj zadovoljiti potražnju. Ponuditelj servisa i korisnik servisa dvije su osnovne funkcije u modelu korištenja servisnog rješenja.

Vrlo je vjerojatno da će se na tržištu pojaviti posrednici izmeñu onih koji raspolažu odreñenim informacijama i resursima i onih koji te informacije i resurse trebaju. Kao što danas imamo softverske kuće koje se bave izradom aplikacija koje se prilagoñavaju pojedinim korisnicima tako će se vjerojatno neka poduzeća specijalizirati za izradu i održavanje servisa. Kako će se u praksi urediti odnosi izmeñu vlasnika informacija i onih koji će ih prezentirati korisnicima putem servisa je stvar njihovih meñusobnih ugovornih odnosa. Ponekad će se možda i nekoliko različitih vlasnika informacija organizirati i svoje informacije prezentirati kroz jedan servis ukoliko u tome pronañu zajednički interes.

Da bi ponuditelji servisa i njegovi potencijalni korisnici mogli stupiti u vezu potrebno je uspostaviti mehanizme za objavljivanje i pronalaženje usluge servisa. Kao jednostavna i učinkovita tehnika pokazali su se katalozi servisa. Za sada nema univerzalnih i standardiziranih metoda za pronalaženje raspoloživih kataloga niti za pronalaženje odgovarajućih servisa unutar raznih kataloga (Konuru i Mukhi, 2003). Katalozi mogu biti javni – dostupni svima, lokalni – na nivou intraneta ili pak namijenjeni odreñenoj skupini korisnika. Kada bi se katalozi s vremenom specijalizirali po područjima koja pokrivaju to bi barem djelomično olakšalo pretraživanje. Usluge koje nude pojedini servisi se takoñer poklapaju. Postoji čitav niz servisa koji pokrivaju isto područje ali ne na isti način. Pojedine funkcije unutar tih servisa mogu se znatno razlikovati tako da je put do konačnog rješenja ili informacije potpuno različit ovisno o tome koji se servis koristi. Problem kod pronalaženja servisa u katalogu je da ne postoji formaliziran pristup za pretraživanje koji bi mogla koristiti računala već se za sada koristi pretraživanje po ključnim riječima (Pedrinaci et al, 2006). Programeri su ti koji pronalaze i implementiraju servise koji zadovoljavaju potrebe korisnikove aplikacije. Čovjek je odlučujući faktor u

Slika 1: Osnovni model korištenja servisnog rješenja (Cervatnes i Hall, 2003)


odabiru servisa i to je ono što predstavlja opasnost za budućnost njihove implementacije.

Da bi mogao donijeti odluku o tome da li će koristiti servis, korisnik mora znati: (1) koju uslugu odnosno informaciju servis pruža; (2) koje funkcije servis koristi; (3) pod kojim uvjetima ponuditelj servisa daje servis na korištenje i (4) kako se servis može pozvati. Na koji način će aplikacija uspostaviti kontakt sa servisom, preko kojih protokola i tehnologija, nije odreñeno teorijom servisno orijentirane arhitekture već pravilima njene konkretne primjene. Ono što teorija uvjetuje je postojanje definiranog sučelja i opisanog postupka uspostave interakcije sa servisom kod konkretne primjene.

Kod implementacije servisno orijentiranih rješenja s aspekta korisnika razlikujemo: (1) razvoj i korištenje servisa za vlastite potrebe; (2) razvoj servisa u svrhu pružanja usluga vanjskim korisnicima i korištenje eksternih servisa u ulozi korisnika; (3) razvoj servisa za komunikaciju sa drugim poslovnim subjektima (B2B); razvoj servisa za komunikaciju unutar državnih institucija; (4) razvoj servisa za komunikaciju državnih institucija i privatnog sektora (B2G) i (5) razvoj servisa kao tehnička podrška u ulozi posrednika. S obzirom na broj organizacija koje koriste servisno orijentirana rješenja razlikujemo unutarorganizacijsko i meñuorganizacijsko umrežavanje.

3.2 Iskustva iz poslovne prakse

Prepreke, izazovi i prednosti primjene Web usluga u poslovnoj praksi

Iako je primjena servisno orijentirane arhitekture i Web usluga relativno novi poslovni koncept, do danas je napravljen cijeli niz istraživanja o rezultatima njegove primjene u poslovnoj praksi. Paradinović (2009) u diplomskom radu daje kvalitetan prikaz istraživanja koje je provedeno 2007.godine u Njemačkoj (Barnes, 2007). Tijekom istraživanja ispitanici su ocjenjivali (ocjenama na Likertovoj skali od 1-5) važnost meñorganizacijske primjene Web usluga u odreñenom području. Podrška

transakcijama u platnom prometu ocjenjena je kao najvažnije područje primjene (58% ispitanika), a slijede: podrška portalima (52%), povezivanje baza podataka (51%) i podrška izvještavanju (40%). Oko 30% ispitanika dalo je visoku važnost „out-taskingu“, a samo 23% eksternalizaciji poslovanja. U okviru istraživanja identificirano je i 15 najvećih prepreka meñuorganizacijskoj implementaciji Web usluga.

Rezultati su prikazani tablicom 1. Nedovoljna standardizacija ocijenjena je kao najznačajnija sa visokih 77,6 posto. Ovo je vrlo važan podatak jer predstavlja kontradikciju sa jednim od glavnih ciljeva ove tehnologije, standardizacijom. S druge strane, najniži stupanj važnost tvrtke su pridodale zadržavanju informacija od strane poslovnih partnera nakon transakcije, samo 27,7 posto, te zloupotrebi informacija, 17,0 posto.

Može se zaključiti da i dalje postoji veliki broj prepreka nad korištenjem Web usluga prilikom meñuorganizacijske suradnje. U cilju iskorištavanja punog potencijala ove tehnologije vrlo je važno pronaći načine savladavanja spomenutih prepreka. Pri identifikaciji problema meñuorganizacijskog povezivanja iz velikog broja navedenih prepreka definirana su četiri najvažnija faktora od kojih svaki objedinjuje veći broj prethodno navedenih prepreka. Kompanije su kao najvažniji faktor rangirale problem tehničke i ekonomske integracije (80,0 posto). U tom kontekstu otkriveno je da veliki broj tvrtki smatra potrebnim ulaganja u daljnje obrazovanje i osposobljavanje, dok je samo nekolicina poduzeća iznijela potrebu preoblikovanja njihove organizacijske strukture. Drugi najvažniji faktor su sigurnosni problemi (62,0 posto). 87,0 posto tvrtki navelo je da su povećali ulaganja u sigurnosne tehnologije a 72,7 posto uočilo je potrebu za razvojem i uvoñenjem dodatnih sigurnosnih smjernica za svoje zaposlenike. Treći faktor zbog svoje kompleksnosti nije posebno imenovan. Naime u njemu su objedinjene prepreke poput složenosti integracije postojećih procesa, nedovoljne kvalitete usluge, nepostojanja potreba za proširenjem mreže te sporog povećanja broja korisnika.

Tablica 1: Prepreke meñuorganizacijskog razvoja Web usluga (Barnes, 2007)

VARIJABLA % odgovora za ocjene „visoka važnost“ i „relativno visoka važnost“

Nedovoljna standardizacija 77.6 %

Složenost integracija IT infrastrukture 66.0 %

Sporo povećavanje broja korisnika 55.1 %

Složenost integracije postojećih procesa 54.0 %

Sigurnosni problemi 52.0 %

Pravni problemi 49.0 %

Nedovoljna sigurnost Web usluga 48.0 %

Nedostatak potrebnih znanja zaposlenika 44.9 %

Gubitak kontrole nad vlastitim podacima 41.7 %

Nemogućnost identificiranja zlouporabe od strane transakcijskih partnera

38.6 %

Nedovoljna kvaliteta usluge 38.3 %

Veći troškovi u odnosu na koristi 36.2 %

Nepostojanje potreba za proširenjem mreže 34.8 %

Zadržavanje informacija od strane poslovnih partnera nakon transakcije

27.7 %

Zloupotreba informacija 17.0 %


Posljednji faktor, objedinjen pod nazivom nepovjerenje prema transakcijskim partnerima (59,2 posto) je, u usporedbi sa drugim analiziranim čimbenicima, manje važan, ali ukazuje na činjenicu kako se Web usluge prvenstveno koriste za povezivanje s dobro poznatim poslovnim partnerima.

Slične rezultate pokazala su i druga istraživanja o primjeni Web usluga u poslovnoj praksi. Tako prema rezultatima istraživanja The Open Group SOA Working Group (2009) poslovni stručnjaci najvažnijim izazovom smatraju probleme koji nastaju pri pronalaženju i identifikaciji servisa. Osim toga, istraživanja pokazuju da poslovna praksa kao nedostatak prepoznaje činjenicu da se servisno orijentirana arhitektura ne bavi pitanjima vezanim uz vlasništvo, pravna pitanja i ugovorne obveze, sigurnost i povjerenje i ostale pravne aspekte (Laskey i Laskey, 2009). Schmidt et al.(2006) kao nedostatak, odnosno rizik kojem se izlažu poslovni subjekti pri korištenju SOA-a navode problem povjerenja i sigurnosti. Malatras et al (2008) velikim nedostatkom smatraju dodatne troškove koji nastaju pri uvoñenju servisno orijentirane arhitekture u organizaciju.

Osim nedostataka i izazova, primjena Web usluga zasigurno donosi i brojne prednosti. U istraživanju koje je proveo Wheller (2006) razlikuju se poslovne prednosti i IT prednosti. Poslovne prednosti odnose se na sposobnost organizacije da brže reagira na promjene u poslovnim zahtjevima, veći povrat ulaganja, niže troškove razvoja, neovisnost o IT platformi, poboljšanje zadovoljstva kupaca zbog kvalitete usluge, te bolju skalabilnost i usklañenost poslovanja. Neke od prednosti koje IT-u donosi primjena Web usluga jesu: mobilnost koda, veći stupanj ponovnog korištenja koda, efikasnije testiranje koda i manje grešaka u razvoju. Merzel (2010) u magistarskom radu sistematizira aktualne teorijske izvore i navodi niz prednosti unutarorganizacijske primjene servisno orijentirane arhitekture i Web usluga, kao što su: fleksibilnost informacijskog sustava, razmjena informacija meñu aplikacijama koje rade na raznim operativnim sustavima, komunikacija meñu aplikacijama koje su razvijene u različitim programskim jezicima i različitim alatima, mogućnost postepenog redizajniranja i reorganizacije sustava, smanjeni troškovi razvoja te višestruko korištenje jednom razvijenih rješenja.

Primjeri implementacije Web usluga u poslovnoj praksi

Servisno orijentirana arhitektura i Web usluge jednako dobro funkcioniraju i unutar jednog poduzeća i izmeñu ponuditelja i vanjskih korisnika. U tekstu koji slijedu prikazi su primjeri nekih svjetskih i jedne domaće organizacije koje su implementirale i ponudile svojim korisnicima Web usluge.

Na bazi infrastrukture koja je prvotno bila razvijena za interne potrebe, Amazon danas nudi Web usluge koji omogućavaju: udomljavanje tuñih aplikacija, uslugu arhiviranja i skladištenja, uslugu brze isporuke željenih sadržaja, elektroničko poslovanje, iznajmljivanje kompjuterske infrastrukture za velike i zahtjevne obrade, angažiranje vanjskih suradnika za povremene poslove, usluge automatskih pretraživača te razvoj i udomljavanje Web stranica za vanjske naručitelje.

I eBay je pokrenuo poseban program za korisnike koji žele koristiti Web usluge. Najveći broj transakcija sa eBay platformom i njihovim Web servisima započet će i odnosit će se na razne vrste pretraživanja, kupnju, prodaju, ureñivanje i komentiranje. Pristup eBay Web servisima može biti besplatan ili uz naknadu. Besplatni

pristup je limitiran a različite licence uz godišnju fiksnu naknadu i mjesečne troškove omogućavaju veći nivo korištenja. Cijeli sustav eBay aukcija postavljen je kao sredstvo za ostvarivanje profita pa su i Web servisi prvenstveno namijenjeni profesionalnim korisnicima koji putem Internet aukcija ostvaruju zaradu.

Flickr omogućava objavljivanje i razmjenu foto i video materijala diljem svijeta. Preko Internet preglednika fotografije i video materijali mogu se učitati sa računala, poslati mailom ili mobitelom. Slike se mogu ureñivati, mogu se dodavati specijalni efekti, mogu se tematski organizirati kao albumi, kategorizirati, razmjenjivati ili koristiti samo za svoje potrebe ili za odreñeni krug ljudi, mogu se označavati mjesta gdje su foto materijali snimljeni i.t.d. Osim ove osnovne usluge, u sklopu svoje ponude, flickr nudi niz servisa koje zainteresirani korisnici mogu koristiti za potrebe razvoja svojih aplikacija. Popis svih servisa dan je na njihovim stranicama, što predstavlja jednu vrstu privatnog kataloga servisa, sa opisom njihovih funkcija. Za amaterski nivo korištenja servisi su besplatni, a za korištenje servisa u profesionalne svrhe potrebno je sklopiti ugovor.

Razmjena znanja od osobite je važnosti u znanstvenom okruženju. Sveučilište iz Manchestera i Europski bioinformatički institut, kao dio Europskog laboratorija za molekularnu biologiju, su u srpnju 2009. godine pokrenuli registar Web servisa kao podršku znanstvenicima koji se bave istraživanjima na području medicine, agronomije i farmacije. Ova vrsta sistematiziranih znanja i standardiziranog pristupa, ima za cilj ubrzati rad biomedicinskih znanstvenika. Razvoj kataloga biocatalogue.org financira vlada Velike Britanije.

PayPal još od 2004. godine ima u svojoj ponudi Web servise koji vanjskim partnerima omogućavaju ugradnju PayPal funkcionalnosti u poslovne aplikacije. Servisi koje nude nisu besplatni i podrazumijevaju sklapanje ugovora izmeñu ponuditelja i korisnika servisa.

I u Republici Hrvatskoj postoji niz poduzeća i organizacija koje razvijaju i nude korištenje Web usluga. Dobar primjer je FINA (dostupno na: http://www.fina.hr/Default.aspx?sec=1277) koja u aktualnoj ponudi ima 4 usluge: � info.BIZ. Omogućuje brz i jednostavan način

pristupa informacijama o uspješnosti poslovanja i financijskome položaju poduzetnika te poslovnoj okolini u kojoj djeluju.

� WEB-BON – informacija o bonitetu - BON-1 na internetu. Korištenje servisa omogućava uvid u informacije o bonitetu poduzetnika te preuzimanje tih informacija u elektroničkom obliku – u PDF formatu, potpisana elektroničkim potpisom i namijenjen je za dokazivanje vlastite financijske sposobnosti.

� WEB servis JRR - Jedinstveni registar računa - (JRR). Evidencija o više od 350.000 redovnih kunskih računa poslovnih subjekata, računa proračuna i računa za naplatu zajedničkih prihoda proračuna, otvorenih u bankama i u Hrvatskoj narodnoj banci. Podaci o računima ažuriraju se svakodnevno.

� WEB servis RGFI - Registar godišnjih financijskih izvještaja - (RGFI). Središnji izvor informacija o uspješnosti poslovanja i financijskom položaju pravnih i fizičkih osoba koji su obveznici poreza na dobit te pravnih i fizičkih osoba u stečaju. Korištenjem navedenog servisa omogućen je uvid i preuzimanje godišnjih financijskih izvještaja i izvadaka iz Registra za razdoblje od 2002.


4. ZAKLJU ČAK: OČEKIVANI TRENDOVI IMPLEMENTACIJE SERVISNO ORIJENTIRANE ARHITEKTURE I WEB USLUGA

Gartner Inc. (2009), vodeća istraživačko-savjetodavna kompanija u svijetu na području informatičkih tehnologija, objavila je 2009. dijagram (Slika 2) koji prikazuje krivulju očekivanja od pojedinih informatičkih pojmova, tehnologija i pokreta u njihovom razvojnom ciklusu. Razvojni ciklus raščlanjen je na faze od trenutka kad se novi pojam pojavi, preko početne euforije i naglog skoka očekivanja, zatim nagli pad interesa i onda normalni rast očekivanja koji je u skladu s razvojem i usvajanjem nove tehnologije.

Ako pogledamo gdje se na krivulji trenutno smjestio pojam servisno orijentirane arhitekture, možemo zaključiti da je ona prošla fazu euforije i na nju se počinje gledati iz realne perspektive. Kako se ova tehnika bude razvijala tako će i očekivanja rasti u skladu s postignutim rezultatima. Servisno orijentirana arhitektura u izgradnji informacijskih sustava do sada se već pokazala kao iskoristiva teorija. Ona postepeno zauzima svoje mjesto kako pri izgradnji novih tako i u daljnjem razvoju postojećih informatičkih rješenja. U oba slučaja do izražaja dolaze sve pozitivne strane ovog pristupa.

Koncept servisa kao malih programskih cjelina koje obavljaju jednostavne funkcije i na taj način postaju alat za izgradnju najrazličitijih kompleksnih rješenja posebno su prepoznale firme koje različite informacije i usluge pružaju preko Interneta. Korisnicima se daje na raspolaganje niz alata (servisa) i prepušta im se da ih

koriste unutar svojih programskih rješenja u skladu sa svojim potrebama.

Sustav je maksimalno fleksibilan i sposoban je brzo se prilagoñavati potrebama na tržištu. Ponuditelji su u mogućnosti brzo razvijati i na tržište stavljati nova rješenja, a korisnici su ih u mogućnosti brzo i jednostavno adaptirati. Servis koji više ne zadovoljava njegove potrebe korisnik može jednostavno zamijeniti nekim koji mu više odgovara, a isto tako svoj sustav može kontinuirano nadograñivati novim servisima koji mu dodaju novu vrijednost. Pri tome se vrijeme potrebno za razvoj i implementaciju novog softvera znatno skraćuje jer se ugrañuju gotova rješenja za čije je održavanje i funkcioniranje odgovoran ponuditelj. Korisniku preostaje samo koordinirati i pratiti rad servisa kako bi se na vrijeme uočili problemi i poduzele odgovarajuće akcije.

Tržište je to koje diktira razvoj novih servisa i samo o odnosu ponude i potražnje ovisi nastanak i opstanak pojedinih servisa i njihovih funkcija. Rješenja koja se nude i koja se pokažu kao dobra brzo će biti prihvaćena i korištena dok će se nezanimljiva, nepotrebna i zastarjela rješenja gasiti jednakom brzinom. Korištenje servisa ovisit će o njihovoj sposobnosti automatskog prilagoñavanja različitim okruženjima, reagiranja na promjene u poslovnom okruženju, održavanja funkcionalnosti u uvjetima neispravnog rada sustava, optimiziranja s obzirom na resurse kojima korisnik raspolaže te sposobnosti zaštite od prijetnji iz okoline. Usprkos brojnim prednostima koje donosi servisno orijentirana arhitektura, poduzeća koja u budućnosti planiraju daljnja ulaganja u Web usluge trebale bi posvetiti veću pozornost na probleme i izazove identificirane i prikazane u ovom radu.

Slika 2: Krivulja očekivanja od pojedinih informatičkih tehnologija (Gartner, 2009)


Literatura:

1 Barnes, S. (2007), „E-Commerce and V-Business: Digital Enterprise in the Twenty-First Century“, Elsevier.

2 Cervantes H., Hall R.S. (2003), "Automating Service Dependency Management in a Service-Oriented Model, Proceedings of the 6th Workshop of the European Software Engineering Conference/Foundations of Software EngineeringComponent Based Software Engineering (September 2003), 379-382

3 Gartner (2009), „Hype Cycle for Emerging Technologies – 2009“, dostupno na: http://www.gartner.com

4 IBM - International Business Machines Corporation (2010), „Service oriented Architecure – SOA“, dostupno na: http://www-01.ibm.com/software/solutions/soa/

5 Konuru R., Mukhi N. (2003), "Requestor Friendly Web Services", First European Workshop on Object Orientation and Web Services (EOOWS).

6 Laskey, K.B. i Laskey, K. (2009), „Service oriented architecture, Wiley Interdisciplinary Reviews: Computational Statistics“, John Wiley & Sons, Inc., 101-105.

7 Leymann F., Roller D. (2010), "Business Processes in a Web services world", dostupno na: http://www.ibm.com/developerworks/library/ws-bpelwp/

8 Malatras, A., Asgari, A., Baugé, T., Irons, M. (2008), A service-oriented architecture for building services integration, Journal of Facilities Management, Vol.6, No. 2, 132-151.

9 Merzel, N. (2010), Magistarski rad: Analiza primjene servisno orijentirane arhitekture u poslovanju poduzeća, Ekonomski fakultet Sveučilišta u Zagrebu, Poslijediplomski znanstveni studij „Informatički menadžment“, mentor: prof.dr.sc. Vesna Bosilj Vukšić.

10 Natis Y.V., Schulte, R.V. (2003), "Service Oriented Architecture", Gartner (2:SPA-19-5971), April 14, dostupno na: http://www.gartner.com

11 OASIS (2006), „Reference Model for Service Oriented Architecture 1.0", Committee Specification 1, 2 August 2006, dostupno na: http://www.oasis-open.org/committees

12 Paradinović, I. (2009), Diplomski rad: Servisno orijentirana arhitektura i Web usluge, Ekonomski fakultet Sveučilišta u Zagrebu, mentor: prof.dr.sc. Vesna Bosilj Vukšić.

13 Pedrinaci C., Moran M., Norton B. (2006), "Towards a Semantic Event-Based Service-Oriented Architecture", The 5th International Semantic Web Conference (ISWC 2006), Athens.

14 Schmidt, S., Steele, R., Dillon, T., Chang, E. (2006), Fuzzy Service Quality Review in Service Oriented Architectures, Proceedings of IEEE International Conference on Fuzzy Systems, Vancouver, 2247-2254.

15 The Open Group SOA Working Group (2009), "SOA Governance Framework, San Francisco“, dostupno na: http://www.mikethearchitect.com/2009/09/open-group-soa-governance-framework.html

16 Wheller, S. (2006), "SYSPRO on SOA: A Guide to Service Oriented Architecture“, Mancherster SYSPRO Ltd., dostupno na: http://www.scribd.com/doc/26415680/SYSPRO-Service-Oriented-Architecture.

17 World Wide Web Consortium (2010), "Web Services Glossary", dostupno na: http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/

Podaci o autorima:

prof.dr.sc. Vesna Bosilj Vukši ć Ekonomski fakultet - Zagreb Trg J.F.Kennedya 6 10000 Zagreb Tel 01/2383-333 Fax 01/2335-633 e-mail: [email protected] Vesna Bosilj Vukšić je redovita profesorica na Katedri za informatiku Ekonomskog fakulteta Sveučilišta u Zagrebu i nositeljica nekoliko predmeta iz područja upravljanja poslovnim procesima i znanjem. Područje njezinog istraživanja je upravljanje poslovnim procesima i znanjem, te razvoj poslovnih informacijskih sustava. Voditeljica je znanstvenog projekta Ministarstva znanosti, obrazovanja i športa RH i članica meñunarodnih znanstveno-istraživačkih projekata. Vesna Bosilj Vuksic is a professor of Business Process Management, Simulation Modelling and Business Computing at the Faculty of Economics and Business, University of Zagreb. Her current research interests are in business process management and information systems development. She participates actively in research within the framework of the Ministry of Science and Technology's scientific projects, she is a leader of the project “Information, process and knowledge management systems” funded from the Croatian Ministry of Science, Education and Sports” (2007-) and is a member of international scientific research projects. Vesna Bosilj Vuksic has been a consultant for business process change on several projects in public and private sector.


12

mr.sc. Natalija Merzel Lipovica d.o.o. Donja Vlahinička, Lipovečka 22 44317 Popovača e-mail: [email protected] Natalija Merzel je direktorica ekonomsko - financijskih poslova u trgovačkom društvu Lipovica d.o.o. koje se bavi proizvodnjom aluminijskih radijatora i odljevaka u tlačnom i kokilnom lijevu. Voditelj je i koordinator službi financija, knjigovodstva, plana i analize te informatičkog odjela. Magistrirala je na Ekonomskom fakultetu u Zagrebu na temu analize primjene servisno orijentirane arhitekture u poslovanju poduzeća.

Ivan Paradinovi ć

Ivan Paradinović roñen je 1982. u Zagrebu. Diplomirao je na Ekonomskom fakultetu u Zagrebu, smjer Poslovne Informatike. Trenutno djeluje kao sound designer, glazbeni producent i remikser u tonskom studiju Soundcage, te kao community manager projekta Music Brands. Ukratko, kreativac sa širokim područjem interesa koje uključuje viralni i gerilski marketing, društvene mreže, psihologiju potrošača te primjenu Web usluga u segmentima digitalne glazbe i video gaming industrije.


SOA I POSLOVNA PRAVILA

SOA AND BUSINESS RULES

Zlatko Siroti ć

SAŽETAK:

Iako je IT tehnologija uvijek bila (ili trebala biti) vezana uz poslovnu tehnologiju koju podržava, SOA još više naglašava povezanost poslovnih procesa i IT aplikacija koje ih podupiru. Poslovni procesi (Business Processes, BP) su zato (uz pojam servis) jedan od fundamentalnih pojmova u SOA arhitekturi. Poslovni procesi izvode se uz zadovoljavanje nekih poslovnih pravila (Business Rules, BR), od kojih su neka usko vezana za pojedini proces, a druga se mogu primijeniti na različite poslovne procese. U spoju SOA arhitekture i poslovnih pravila, stroj za poslovna pravila (rules engine) postaje odvojena komponenta (odvojeni servis) koji izvršava neka poslovna pravila - ona koja su zajednička za više procesa, a neka poslovna pravila – ona koja su vezana samo za jedan proces, izvodi sam proces.

ABSTRACT:

Although the IT technology has always been (or should be) related to business technology that supports, SOA further emphasizes the connection between business processes and IT applications that supports them. Business Processes (BP) are therefore (beside the term of service) one of the fundamental terms in SOA architecture. Business processes are carried out with the satisfaction of certain business rules (BR), some of which are closely tied to a particular business process, while other can be applied to different business processes. In combination of SOA architecture and business rules, business rules engine (rules engine) becomes a separate component (separate service) that executes some business rules - those that are common to several processes. Some business rules - those that are related only to one process, runs the process itself.

1. UVOD

IT industrija je oduvijek tražila način kako da poveća produktivnost i smanji rizik kod izrade softvera. Od samih početaka su se rješenja tražila u drugim, starijim i razvijenijim industrijama / inženjerskim područjima, kod kojih se izrada novih proizvoda temelji na već izrañenim komponentama (dijelovima, poluproizvodima). Softversko inženjerstvo je prošlo put od špageti programiranja, preko strukturiranog programiranja, modularnog programiranja, objektnog programiranja i dr. Može se reći da SOA arhitektura (Service-Oriented Architecture, servisno-orijentirana arhitektura) nije nikakvo revolucionarno rješenje, već je nastavak tog puta (napomena: izraz "SOA arhitektura" je redundantan, dovoljno bi bilo reći samo SOA, ali čini nam se da je pogodniji za uporabu od same skraćenice).

Kako organizacije mogu uvoditi nove mogućnosti u svoje IT aplikacije? Jedan način je pokušaj zamjene starih rješenja s novima, tj. bacanje starih rješenja. Takav način ponekad ima svojih opravdanja, npr. ako su postojeća rješenja takva da ih je praktički nemoguće (ili neisplativo) mijenjati. No, bacanje starih rješenja je generalno riskantna i/ili skupa strategija. U većini slučajeva bolja je strategija - izrada novih funkcionalnosti i njihova integracija u postojeći sustav. Takav (evolucijski) pristup u pravilu smanjuje rizik i troškove. SOA arhitektura je okvir (framework) koji je danas prihvaćen u IT industriji za proširivanje postojećih aplikacija, ali i za izradu novih aplikacija.

Iako je IT tehnologija uvijek bila (ili trebala biti) vezana uz poslovnu tehnologiju koju podržava, SOA arhitektura još više naglašava povezanost poslovnih procesa i IT aplikacija koje ih podupiru. Poslovni procesi (Business Processes, BP) su zato (uz pojam servis) jedan od fundamentalnih pojmova u SOA arhitekturi. Poslovni

procesi izvode se uz zadovoljavanje nekih poslovnih pravila (Business Rules, BR), od kojih su neka usko vezana za pojedini proces, a druga se mogu primijeniti na različite poslovne procese.

U radu se prikazuju implementacije poslovnih pravila u SOA arhitekturi. U 2.točki se prikazuju poslovni procesi, tj. modeliranje / upravljanje poslovnim procesima. U 3.točki se daje kratki prikaz SOA arhitekture. U 4.točki se prikazuju poslovna pravila (neke definicije, klasifikacije, implementacije izvan SOA arhitekture). U 5.točki prikazuje se implementacije poslovnih pravila u SOA arhitekturi, pomoću alata Oracle SOA Suite.

2. POSLOVNI PROCESI

Postoje različite definicije pojma "poslovni proces", a jedna od njih je i ona navedena u [8]. Prema toj definiciji, poslovni proces je: � skup aktivnosti i zadaća podržan resursima; � koje (aktivnosti) koriste različite vrste informacija

(strukturirane i nestrukturirane); � nalaze se u meñusobnim interakcijama

(predviñenim i nepredviñenim); � upravljane su menadžerskim politikama i principima

(poslovna pravila i kriteriji odlučivanja); � s ciljem da proizvedu izlaz koji je u skladu s finalnim

rezultatom (strategije i ciljevi).

Dalje se u [8] navodi da procesi mogu biti sastavljeni od podprocesa, da proces može biti servis i da servis može biti proces, i da postoje dva tipa procesa – automatski (koje izvodi neki stroj) i neautomatski (temeljeni na ljudskoj intervenciji). U [8] se radi striktna razlika izmeñu procesne logike (process logic) i logike odlučivanja (decision logic), gdje je procesna logika ona koja je usko vezana za odreñeni proces (čini njegov dio), a logika


14

odlučivanja (koju čine menadžerske politike i principi) se ne odnosi na jedan proces, već se može primijeniti u više procesa i implementira se pomoću poslovnih pravila (business rules).

U [7] se navodi da se aktivnosti vezane za dizajniranje i izvršavanje poslovnih procesa nazivaju upravljanje poslovnim procesima (Business Process Management, BPM). Često se skraćenica BPM koristi za izraz Business Process Modeling (modeliranje poslovnih procesa), a u [7] se kaže da ta dva izraza mogu značiti jedno te isto (no, moglo bi se reći i da je modeliranje poslovnih procesa samo podskup od upravljanja poslovnim procesima). U [7] se navode sljedeći najvažniji termini vezani za upravljanje poslovnim procesima: � definicija procesa (process definition): osnovni

algoritam ili ponašanje procesa; � instanca procesa (process instance): jedna pojava

procesa za specifični ulaz; � aktivnost ili zadaća (activity or task): korak procesa; � automatska aktivnost / zadaća (automated activity /

task): korak u procesu koji se direktno izvršava pomoću nekog stroja (execution engine);

� ručna (manual) aktivnost / zadaća: korak u procesu koji se izvršava uz pomoć čovjeka.

U [7] se naglašava da BPM nije podesan za sve aplikacije, već samo za one aplikacije koje su procesno orijentirane. Aplikacija je procesno orijentirana ako ima sljedeće karakteristike: � aplikacija ima dugo trajuće (long-running) procese:

od starta do cilja procesa prolaze sati, dani, pa čak i tjedni, mjeseci, ili još dulje vrijeme;

� procesi (aplikacije) posjeduju perzistenciju: budući da procesi dugo traju, njihovo se stanje pohranjuje u bazu podataka;

� procesi najveći dio vremena "spavaju": najveći dio vremena procesi provedu u neaktivnom stanju, čekajući na neki dogañaj koji će ih okinuti;

� orkestracija sistemske ili humane komunikacije: procesi su odgovorni za upravljanje i koordinaciju komunikacije izmeñu različitih sistemskih ili humanih aktora.

Treba naglasiti kako nije nužno da procesno orijentirana aplikacija ima sve ove karakteristike. Kao primjer aplikacije koja npr. ima kratkotrajne procese koji nikad ne spavaju, a ipak je podesna za BPM, [7] navodi Message Broker aplikaciju. Za razliku od toga, [7] navodi ATM aplikaciju (Automated Teller Machine, bankomat) kao nepodesnu za BPM.

BPM je podržan različitim standardima, kako navodi [7] možda i sa previše njih. Najvažniji od tih standarda su sljedeći: � Business Process Execution Language for Web

Services (BPEL4WS, ili WS-BPEL, ili skraćeno samo BPEL), je BPM specifikacija koja je bila inicirana od strane velikih IT firmi (IBM, Microsoft, Oracle, BEA – BEA je danas u vlasništvu firme Oracle), a koju danas podržava neprofitna organizacija OASIS (Organization for the Advancement of Structured Information Standards); BPEL process je web servis sa pridruženom procesnom definicijom definiranom u XML-temeljenom jeziku BPEL; BPEL for Java (BPELJ) je BPEL ekstenzija koja omogućava da se Java kod ugradi u definiciju procesa;

� sličan standard je Business Process Modeling Language (BPML), koji je napravila organizacija Business Process Modeling Initiative (BPMI); ta je organizacija napravila i Business Process Modeling

Notation (BPMN); za razliku od BPEL-a ili BPML-a, koje su XML notacije, BPMN je sofisticirana grafička notacija; njen daljnji razvoj preuzela je organizacija OMG (Object Management Group), koja danas vodi brigu i o standardima kao što su CORBA, UML i drugi; postoje mapiranja izmeñu BPMN (grafičke) i BPEL (XML) notacije, ali ta mapiranja nisu savršena - BPEL definicija koja se dobije automatskom pretvorbom (pomoću odgovarajućeg softverskog alata) iz BPMN dijagrama, često je praktički nečitljiva (za čovjeka);

� Web Services Choreography Description Language (WS-CDL) je standard organizacije World Wide Web Consortium (W3C); za razliku od procesne orkestracije, koja se odnosi na unutarnja zbivanja (unutar jednog procesa) i opisuje se pomoću jezika kao što je BPEL, koreografija opisuje zbivanja izmeñu više procesa, tj. web servisa.

Kako navodi [7], dobro BPM rješenje trebalo bi raditi sljedeće: � modelirati (design) procese: pojednostavljeno

rečeno, rezultat je dijagram toka koji prikazuje korake koji se izvršavaju za rješavanje odreñenog poslovnog problema; za razliku od najvećeg broja objektno-orijentiranih modela, koji prvenstveno služe IT timu, model procesa služi i poslovnim i tehničkim analitičarima;

� izvršavati (run) procese: na temelju modeliranog procesa, BPM rješenje trebalo bi omogućiti automatsko izvršavanje procesa, na taj način da se model mapira u izvršnu notaciju, koja se izvršava na stroju za izvršavanje (runtime engine);

� nadgledati i administrirati (monitor and administer) procese: nadgledanje procesa važno je zbog detekcije iznimaka i zbog mogućnosti postavljanja real-time upita na stanje procesa; administracija procesa obuhvaća real-time instaliranje novih procesa, izmjenu procesa, suspendiranje, ponovno pokretanje ili terminiranje procesa.

Slika 1. prikazuje kako bi trebalo izgledati "dobro" BPM rješenje po [7]. U centru rješenja je stroj za izvršavanje (runtime engine), koji izvršava programe pisane u jeziku BPEL. No, poslovni i tehnički analitičari dizajniraju

Slika 1. Komponente dobrog BPM dizajna; Izvor: [7]


procese grafički, pomoću alata koji podržava BPMN. Taj alat uključuje dio koji pretvara (mapira) BPMN dijagrame u BPEL XML kod. Izvršavanje procesa voñeno je ljudskim i računalnim interakcijama. Postoje dva tipa računalnih interakcija: interne i eksterne. Interne interakcije temelje se na integracijskim tehnologijama kao što su web servisi, ali i na Java EE, COM ili drugim tehnologijama. Pritom se može, ali i ne mora koristiti XML kao format za razmjenu poruka. Eksterne interakcije su, tipično, temeljene na web servisima, voñene preko koreografije ili B2B suradnje. BPM sistem administratori koriste grafičku konzolu za monitoriranje i administraciju procesa. Stroj za izvršavanje koristi bazu podataka za realizaciju perzistencije.

Kako navodi [7], tri su teoretska izvora za BPM: � pi-kalkulus (pi-calculus), kojega je izmislio škotski

matematičar Robin Milner u 90-tim; to je algebarski sustav za izgradnju procesa koji meñusobno komuniciraju preko kanala; pi-kalkulus procesi se pišu kao skupovi jednadžbi, koristeći specifičnu sintaksu; kada jedan proces šalje informaciju drugom, uključuje i ime kanala koji će se koristiti da drugi proces pošalje odgovor; to je ime varijabla, što znači da se kanal može dinamički mijenjati u ovisnosti od promjenjivih uvjeta – to se naziva mobilnošću;

� Petrijeve mreže (Petri net) je izmislio matematičar Carl Adam Petri u 60-tim; Petrijeva mreža je proces, čiji su glavni dijelovi lokacije (places), tranzicije (dogañaji koji upravljaju razvojem procesa), oznake (tokens) i lukovi (koji spajaju tranzicije s lokacijama); glavno pravilo klasičnih Petrijevih mreža je jednostavno: tranzicija se okida samo onda kada sve ulazne lokacije (koje vode do tranzicije) sadrže token, a nakon što se tranzicija okine, token se miče sa svake ulazne lokacije na svaku izlaznu lokaciju (lokaciju do koje vodi luk koji izlazi iz tranzicije);

� stroj (konačnih) stanja, ili stroj sa (konačnim) stanjima ((finite) state machine) ima bogatu povijest, u razvoju su sudjelovali i Turing, Moore, Mealy, Harel (zadnji je zaslužan za UML dijagram stanja); za razliku od dijagrama toka procesa, dijagram stanja je čišći i kompaktniji način prikaza procesa, jer je deklarativan, a dijagram toka je proceduralan; zanimljivo je da je UML dijagram akcija mješavina dijagrama toka procesa i dijagrama stanja; smatra se da je stroj stanja imao manje utjecaja na BPM nego pi-kalkulus i Petrijeve mreže.

3. SERVISNO ORIJENTIRANA ARHITEKTURA

Kako se navodi u [2], organizacije u privatnom i javnom sektoru sve su ovisnije o informacijskoj tehnologiji (IT), a u nekim područjima (npr. telekomunikacijske usluge, bankarstvo) je kompetitivnost organizacija primarno vezana uz informacijska rješenja koja koristi. Menedžeri koji upravljaju IT sustavima u tim organizacijama danas su često suočeni s kontradiktornim zahtjevima. S jedne strane, korisnička očekivanja u odnosu na raspoloživost, pouzdanost i performanse sve su veća, vrijeme u kojem treba razviti nove mogućnosti sve je kraće, od IT sustava se očekuje da budu na raspolaganju ubrzo nakon neplaniranih dogañaja (nezgoda) i sl. S druge strane, budžet koji je na raspolaganju IT sektoru je sve manji i manji.

Organizacije mogu uvoditi nove mogućnosti u svoje IT aplikacije na taj način da zamijene stara rješenja s novima, tj. bace stara rješenja. Takav način ponekad ima

svojih opravdanja, no, bacanje starih rješenja je generalno riskantna i/ili skupa strategija. U većini slučajeva bolja je strategija - izrada novih funkcionalnosti i njihova integracija u postojeći sustav. Takav (evolucijski) pristup u pravilu smanjuje rizik i troškove. SOA arhitektura je okvir (framework) koji je danas široko prihvaćen u IT industriji za proširivanje postojećih aplikacija, ali i za izradu novih aplikacija.

SOA arhitektura počiva na jednostavnoj ideji, po kojoj postoje davatelj usluge (service provider) i primatelj usluge (service consumer). No, za razliku od uobičajenog pristupa da je primatelj usluga čovjek, u SOA arhitekturi su i davatelj i primatelj softverski entiteti. SOA arhitektura nije samo IT tehnologija, već je ona i pristup po kojem poslovni korisnici sudjeluju u razvoju i nadgledanju softverskih rješenja. Servis treba podržati prije svega poslovnu funkciju, a ne čistu tehničku funkciju.

Kao davatelji usluga u SOA arhitekturi često se koriste web servisi, ali to nije jedina tehnologija koja se može/smije koristiti. U [2] se navode sljedeće karakteristike davatelja usluga: � nezavisan je od bilo kojeg primatelja usluge; može

se promatrati kao crna kutija, kod koje nije važna unutrašnjost (npr. u kojem jeziku je servis pisan), već samo ono što daje;

� specificira točno definirani skup funkcija koje pruža i način kako se pozivaju, tj. ima strogo definirano sučelje (interface);

� ima odreñeno ime i može se locirati pomoću odreñene vrste registra (registry);

� ima mehanizam oporavka (recovery) u slučaju grešaka;

� u toku svog rada može pozvati druge davatelje usluga, odnosno davatelj usluge u tom slučaju postaje primatelj usluge.

Razmjena poruka izmeñu SOA servisa najčešće se radi pomoću XML-baziranih jezika. Inače, u [6] autori navode kako je XML (eXtensible Markup Language) možda najvažniji programski jezik ikada napravljen. No, XML zapravo nije jezik (unatoč svom imenu), već je samo šablona za izradu XML-temeljnih jezika ili protokola. Na XML-u se temelji i najpoznatiji protokol za opis poruka (koje se šalju izmeñu SOA servisa) – SOAP. U [2] se navodi kako je SOAP, kada je prvo definiran, bio akronim za Simple Object Access Protocol, ali se u meñuvremenu to značenje izgubilo, jer protokol nije niti jednostavan, niti se odnosi na vezu meñu objektima, tako da je to danas ime bez posebnog značenja. Nekad se smatralo da je SOAP nužan za "pravu" SOA arhitektu, tj. da svaka razmjena poruka izmeñu servisa mora ići preko SOAP protokola. No, iako se SOAP protokol u načelu može koristiti za svaku interakciju, postoje slučajevi kada je zbog efikasnosti bolje odabrati drugi protokol, i pri tome i dalje ostajemo unutar SOA arhitekture. Npr. ako se koristi neki Java EE (Java Platform, Enterprise Edition) aplikacijski server, tada JMI (Java Method Invocation) ili Java Messaging uobičajeno predstavljaju bolji izbor nego SOAP, zbog boljih performansi, ali i zbog boljeg uklapanja tih protokola u Java okolinu.

Osim SOAP protokola, nekad se smatralo da je za "pravu" SOA arhitektu neizostavno nužan i SOA UDDI registar (Universal Description, Discovery, and Integration). Tu se još javlja i WSDL (Web Service Description Language), XML-temeljeni jezik pomoću kojeg se kreira XML dokument koji opisuje web servis, njegovo sučelje i način korištenja. Slika 2. prikazuje kako dva servisa komuniciraju na "idealan" SOA način:


16

Slika 2. pokazuje kako se servis Credit Checking prijavljuje u UDDI registar (pri čemu se koristi jezik WSDL), čime stavlja na znanje okolini svoje postojanje i prikazuje funkcije koje može pružiti. Servis Order Processing traži usluge nekog servisa kao što je Credit Checking, a to traži na način da koristi usluge infrastrukturnog servisa Service Broker, koji traži informacije o traženom servisu u UDDI registru. Nakon što ih nañe, Service Broker šalje informaciju o traženom servisu (Credit Checking) prema servisu tražitelju usluge (Order Processing), preko WSDL definicije. Nakon toga servis primatelj usluge (Order Processing) komunicira preko poruka pisanih u SOAP protokolu sa servisom davateljem usluge (Credit Checking).

Treba naglasiti da je uloga UDDI registra da pruža informacije o raspoloživim uslugama u realnom vremenu, bez obzira na dinamičnost okruženja. U relativno statičnom okruženju (gdje se servisi rijetko dodaju, uklanjaju ili mijenjaju), sa relativno malim brojem davatelja usluga, UDDI registar ne bi bio nužan, jer bi se informacije o davateljima usluga mogle meñusobno "podijeliti" izmeñu servisa.

Na slici se vide i adapteri (prilagoñivači). U [6] se daje lista različitih vrsta adaptera: � web servis adapteri; � adapteri za emulaciju terminala; � dokument-bazirani adapteri, npr. oni za Electronic

Data Interchange (EDI); � adapteri za middleware; � adapteri za transakcijske strojeve (transaction

engine), npr. adapteri za IBM CICS, BEA (sada Oracle) Tuxedo i sl.;

� adapteri za podatke (često se baziraju na standardima ODBC i JDBC) i drugi.

Razvoj i održavanje softvera nikad nije bio lagan posao, zato jer jedino što je stalno kod softvera jesu – stalne promjene! Promjene u SOA arhitekturi još su kompleksnije. Zbog toga (ali ne samo zbog toga) se u [6] zagovara postojanje SOA repozitorija (repository). Iako se na prvi pogled čini da repozitorij kopira neke funkcije koje ima registar, glavna razlika izmeñu registra i repozitorija je u tome da je registar vrlo dinamičan – promjene koje se dešavaju sa/u servisima moraju se odmah odraziti u registru (u realnom vremenu). Promjene u repozitoriju nisu tako dinamičke. Kako se navodi u [6], SOA repozitorij trebao bi sadržavati i izvorni kod aplikacija (koje je firma napravila) i zapise o svim promjenama na aplikaciji (change management).

Repozitorij bi trebao sadržavati i podatke o poslovnim procesima, pa bi služio i kod modeliranja poslovnih procesa. Takoñer, služio bi i za SOA testiranje, te za SOA upravljanje (governance):

Bitno je to da se zadržavaju svi postojeći softverski alati (na slici 3. je prikazano u pravokutniku Software Development), ali se nadopunjuju sa specifičnim alatima za SOA arhitekturu, kao što su alati za BPM, alati za SOA testiranje i SOA governance, sve podržano sa registrom i repozitorijem.

4. POSLOVNA PRAVILA

Krajem 70-tih pojavili su se opisi slojevite arhitekture informacijskih sustava, tzv. troslojne arhitekture (three-tier architecture). U to je vrijeme pojam "tier" imao poprilično drugačije značenje od onoga kojeg (pretežno) ima danas. Danas se "tier" (obično) upotrebljava kao oznaka za fizički sloj, dok je nekad to bila oznaka za logički sloj. Kad se govori o logičkim slojevima, danas se obično upotrebljava termin "layer". Troslojna arhitektura poprimila je veliku popularnost tek 90-tih, dobrim dijelom zahvaljujući promociji koju je napravila Gartner grupa.

"Klasičan" opis troslojne arhitekture navodio je tri sloja: sloj korisničkog sučelja (User Interface), sloj aplikacijske logike (Application Logic) i podatkovni sloj (Storage). Tijekom vremena se broj (logičkih) slojeva povećavao, pa npr. Java EE specifikacija navodi četiri sloja: sloj korisničkog sučelja (Client Tier), sloj prezentacijske logike na serveru (Web Tier), sloj poslovne logike, tj. poslovnih objekata i poslovnih pravila (EJB Tier) i podatkovni sloj (Data Tier). Neke klasifikacije navode pet ili više slojeva. U svakom slučaju, svugdje se javlja sloj (ili podsloj) poslovnih pravila.

U [4] se navodi da je pristup razvoju aplikacija na temelju poslovnih pravila, ili skraćeno BRA pristup (Business Rules Approach), nastao evolucijom iz tri izvora: � umjetna inteligencija (Artificial Intelligence, AI), i to

naročito iz dijela AI koji se bavi ekspertnim sustavima (Expert Systems);

� modeliranje podataka (Data Modeling); � reinženjering poslovnih procesa (Business Process

Reengineering, BPR), koji je kasnije evoluirao u upravljanje poslovnim procesima (Business Process Management, BPM).

Slika 2. Interakcija servisa u SOA arhitekturi; Izvor: [6]

Slika 3. Razvoj SOA softvera pomoću tradicionalnih alata i

specifičnih SOA alata; Izvor: [6]


Navodi se da je nakon prestanka buma oko umjetne inteligencije (krajem 80-tih) veliki broj proizvoñača ekspertnih sustava prešao na područje izrade rules engine-a.

Što se tiče utjecaja vezanih oko modeliranja podataka, taj je utjecaj dolazio iz područja SQL baza podataka, naročito kada su autoriteti iz područja modeliranja podataka (meñu kojima i Barbara von Halle, autorica knjige [17]) osnovali sredinom 90-tih Business Rules Group (BRG). Ta se grupa inicijalno fokusirala na poslovna pravila koja se mogu direktno implementirati u informacijskoj tehnologiji, naročito u SQL bazama podataka. Kasnije je Ron Ross (autor knjige [16]) usmjerio BRG na poslovni aspekt poslovnih pravila, što je danas dovelo do OMG standarda Semantics of Business Vocabulary and Business Rules (SVBR) i Business Motivation Model (BMM).

Postoje brojne definicije pojma "poslovno pravilo". Npr. u [16] se navode tri (kratke) definicije, sa različitih polazišta: � poslovna definicija (business definition): Propis

namijenjen da utječe ili upravlja poslovnim ponašanjem;

� definicija sa stanovišta analitičara poslovnog sustava (business system definition): Atomičan (atomic) dio višestruko uporabljive (reusable) poslovne logike, specificiran deklarativno;

� formalna definicija (formal definition): Koncept reprezentiran pomoću terma (term), fakta (fact) ili pravila (rule).

U [16] se navode i ovi temeljni principi BRA pristupa (The Basic Principles of the Business Rule Approach): � pravila trebaju biti izražena i napravljena eksplicitno; � pravila trebaju biti izražena na jasan način; � pravila trebaju postojati nezavisno od procedura i

radnih tokova (workflows); � pravila trebaju biti izgrañena na faktima, a fakti

pomoću terma; � pravila trebaju voditi ili utjecati na ponašanje u

željenom smjeru; � pravila trebaju nastati iz identificiranih i važnih

poslovnih faktora; � pravila trebaju biti pristupačna autoriziranim

korisnicima; � pojedino pravilo smije imati samo jedan izvor

(single-sourced); � pravila trebaju biti specificirana direktno od ljudi koji

posjeduju relevantna znanja; � pravilima se mora moći upravljati.

U [16] se navodi i funkcionalna klasifikacija poslovnih pravila (Functional Categories of Rules: The BRS Rule Classification Scheme), koja se temelji na tome kako pravila reagiraju na dogañaje. Budući da odreñeno pravilo može reagirati na jedan od moguća tri načina, po ovoj klasifikaciji postoje tri osnovne vrste pravila: � pravilo koje odbacuje (rejector): pravilo koja

odbacuje dogañaj ako bi njegovo izvršavanje rezultiralo povredom pravila; to su pravila koja štite sustav od pogrešnih podataka (ili pogrešnih stanja);

� proizvoñač (producer): pravilo koje izračunava ili derivira vrijednost na temelju neke matematičke funkcije; ima podvrste (computation rule, derivation rule);

� projektor (projector): bilo koje pravilo koje pokreće neku akciju (koja nije odbacivanje) kada se desi relevantni dogañaj; ima podvrste (enabler, copier, executive, koje imaju svoje podvrste).

U [17] se može naći nekoliko definicija pojma poslovno pravilo, uključujući i one drugih autora. Treba naglasiti da se tamo u poslovna pravila ne ubrajaju tzv. pravila radnog toka (workflow rules), već samo pravila koja se odvijaju unutar individualne transakcije baze.

Mnogi zagovornici primjene poslovnih pravila drže da je pristup razvoju aplikacija na temelju poslovnih pravila (Business Rules Approach to Application Development) sljedeći glavni evolucijski korak u razvoju aplikacija, koji slijedi iza objektno-orijentiranog pristupa (Object-Oriented Approach). Takvo je mišljenje prikazano i u [17], s tim da se zagovara posebna komercijalna tehnologija za pravila, tj. specijalizirani softver za upravljanje pravilima (rules engine), koji može omogućiti: � manju potrebu za pisanjem programskog koda; � kraće vrijeme razvoja; � reduciranje grešaka kod programiranja; � brzo proširivanje; � isporuku pravila nezavisno od SUBP-a, srednjeg i

prezentacijskog softvera; � isporuku vidljivih pravila (nesakrivenih); � omogućavanje višestrukog korištenja pravila; � omogućavanje specifikacije pravila samo na jednom

mjestu; � automatsko izvršavanje pravila.

No, ne slažu se svi da softver za poslovna pravila treba biti striktno odvojen od ostalog softvera, pa i od softvera baza podataka.

U [3] Date (jedan od najvećih autoriteta za relacijske baze podataka) navodi 12 odredbi za "stroj za pravila" (rules engine) i navodi da stroj za pravila može (i mora) biti nezavisan od "podatkovnog" SUBP-a, ali kaže da stroj za pravila mora biti sam po sebi takoñer SUBP (5.odredba), i to relacijski SUBP (6.odredba). Pravila moraju biti izvršna, tj. moraju biti programski kod, a ne tekst (1.odredba) i moraju biti deklarativno navedena, a ne proceduralno (2.odredba). No, iako je današnji SQL standard relacijski potpun u podršci deklarativnih ograničenja (jer dozvoljava bilo koji izraz u CHECK klauzuli za deklaraciju ograničenja), u praksi rijetko koji SUBP to realizira (npr. Oracle RSUBP ne realizira). Najčešća je izlika (proizvoñača SUBP-a) da bi to jako usporilo rad sustava. Zbog takvog stanja u praksi, Date nije protiv proceduralnih rješenja, pa ni protiv okidača baze podataka – treba ih koristiti ako ne postoji (deklarativna) alternativa. Naime, nepodržavanje poslovnih pravila na bazi rezultira time da je integritet podataka u bazi ovisan o aplikaciji. Jedna aplikacija se može pridržavati poslovnih pravila, a da pritom druga aplikacija to ne radi (najčešće nenamjerno). Nepodržavanje poslovnih pravila na bazi znači i to da netko zlonamjeran može mijenjati podatke u bazi podataka izvan kontrolirane aplikacije, i na taj način namjerno narušiti integritet podataka.

Kod rada sa bazama podataka, čini se adekvatnom definicija (i klasifikacija) poslovnih pravila iz [12] (bez obzira što je riječ o Oracle publikaciji, čini nam se primjenjivom i na druge relacijske baze podataka): "Poslovna pravila su ograničenja koja se primjenjuju na stanje sustava ili na promjenu stanja sustava (Constraint Rules), autorizacijska pravila, koja odreñuju koji korisnici mogu raditi i što mogu raditi u sustavu (Authorization Rules), ili akcije koje se automatski pokreću nakon promjene stanja sustava (Change Event Rules)".


18

Oracle navodi da se ta njihova klasifikacija može izraziti i u terminima UML metode. Invarijantama (Invariant) se mogu nazvati ograničenja na stanje sustava, pretkondicijama (PreCondition) se mogu zajedno nazvati ograničenja na promjenu stanja sustava i autorizacijska pravila, a postkondicijama (PostCondition) se mogu nazvati akcije koje se automatski pokreću nakon promjene stanja sustava.

Ova (alternativna) Oracle klasifikacija je bliska (barem po terminologiji) metodi Design By Contract (DBC). Pojednostavljeno rečeno, DBC se zasniva na ideji da svaka metoda klase (procedura ili funkcija), uz "standardni" programski kod, treba imati još dva dodatna dijela - pretkondiciju (precondition) i postkondiciju (postcondition). Klasa treba imati još jedan dodatni dio - invarijantu (invariant). Ugovor (contract) se zasniva na tome da metoda "traži" od svog pozivatelja (neke druge metode) da zadovolji uvjete definirane u pretkondiciji (plus uvjete definirane u invarijanti), a ona (pozvana metoda) se tada "obvezuje" da će na kraju zadovoljiti uvjete definirane u postkondiciji (plus uvjete definirane u invarijanti). Ideja je na neki način upravo suprotna od tzv. defanzivnog programiranja, koje zagovora da se u svim mogućim trenucima pokušava što više toga provjeriti. DBC metoda je opisana u [10], a realizirana je u programskom jeziku Eiffel (autor DBC metode i jezika Eiffel je isti).

Kako se navodi u [5], svi BRMS sustavi (Business Rules Management System, sustavi za upravljanje poslovnim pravilima) poslovna pravila predstavljaju kao rečenice, koje obično sadrže riječi IF i THEN. Rečenica IF A THEN B tada predstavlja produkcijsko pravilo. Lijeva strana (u ovom slučaju A) se zove antecedent ili pretpostavka, a desna strana konzekvent ili posljedica, što je u skladu s terminologijom (matematičke) logike. Produkcijsko pravilo ima, dakle, oblik logičke implikacije, što se u logici obično piše kao A => B. Važno je to da BRMS sustav, kao i ekspertni sustav općenito, može stvarati nova pravila na temelju već poznatih pravila, odnosno može deduktivno zaključivati, što se obično naziva (deduktivno) inferenciranje (inference).

Kako kaže [5], deduktivno inferenciranje nije jedini način zaključivanja u BRMS sustavima, ali je daleko najčešći. Drugi način zaključivanja je induktivan – stvaranje pravila na temelju konkretnih podataka. Data mining (rudarenje podacima) i strojno učenje su specifične varijante te metode.

Kod deduktivnog inferenciranja, poznate su strategije povezivanja unaprijed, povezivanja unatrag i mješovitog povezivanja (Forward / Backward / Mixed Chaining Strategies). Strategija povezivanja unaprijed može se prikazati na ovom primjeru poslovnih pravila (iz [5]):

Rule 1: A and B and C implies D

Rule 2: D and F implies G

Rule 3: E implies F

Rule 4: F implies B

Rule 5: B implies C

Rule 6: G implies H

Rule 7: I implies J

Rule 8: A and F implies H

Pretpostavimo da znamo kako su A i F istiniti, a želimo zaključiti (na temelju navedenih pravila) da li je H istinito. Uočimo da se odmah može iz 8. pravila zaključiti da je H istinito. No, povezivanje unaprijed radi krećući se od početka (a možemo zamisliti i da nema 8. pravila), pa bi krenulo od 4. pravila, jer je to prvo pravilo (po redu) kod

kojeg je istinit antecedent (u ovom slučaju F), pa se na temelju toga izvodi istinitost konzekventa (u ovom slučaju B). Sada znamo da je uz A i F, istinit i B, pa krećemo ispočetka, opet od 1. pravila. Sljedeća tablica pokazuje zbivanje kroz korake (iteracije):

Vidimo da se već u 5. iteraciji došlo do potvrde istinitosti za H, a takoñer vidimo i da 6. i 7. iteracija nisu donijele nikakve nove rezultate u odnosu na 5. iteraciju. Budući da su rezultati 5. i 6. iteracije isti, nije bilo potrebno raditi 7. iteraciju. Da smo u našem slučaju došli do toga da su rezultati dvije iteracije isti, ali da nismo potvrdili istinitost H, zaključili bismo da H nije istinito. Ovakvo zaključivanje povezivanjem unaprijed ima svojih prednosti. Ako pustimo da se iteriranje zbiva sve dok ne doñemo do dva stupca s istim rezultatima, time dobijemo sve moguće odgovore (za zadane ulazne podatke). Meñutim, takav način zaključivanja bi kod velikog broja pravila bio jako spor. Istina, možemo prekinuti kod one iteracije koja daje potvrdan odgovor, ali ako polazna hipoteza nije točna, onda će tek postojanje dva ista stupca moći to pokazati.

Za razliku od povezivanja unaprijed, povezivanje unatrag radi tako da pretpostavimo kako je ono što želimo dokazati već istinito. U našem prethodnom slučaju, pretpostavili bismo da je H točno (uz A i F) i vidjeli bismo da li tu pretpostavku možemo dokazati. Zaključivanje povezivanjem unazad na prethodnom primjeru izgledalo bi ovako [5]:

Trying to prove H

Try rule 6

Trying to prove G

Try rule 2

F is true, trying to prove D

Try rule 1

A is true, trying to prove B

Try rule 4

It works. B is true

Backtrack to trying rule 1

Trying to prove C

Try rule 5, it works C is true

Apply rule 1, D is true

Apply rule 2, G is true

Apply rule 6, H is true

Goal achieved; stop.

Povezivanje unatrag staje kod dokazivanja H i (općenito) ne nalazi sve rezultate (na temelju zadanih ulaza).

Tablica 1. Rezultati kod zaključivanja (naivnim) povezivanjem unaprijed; Izvor: [5]


Povezivanje unaprijed i povezivanje unatrag mogu se kombinirati (na različite načine), čime se dobiju strategije mješovitog povezivanja.

Postoji puno bolji algoritam za povezivanje (naročito u odnosu na prikazani naivan algoritam povezivanja unaprijed), a zove se Rete algoritam (latinski i talijanski rete znači mreža). Dizajnirao ga je Charles L. Forgy sa Carnegie Mellon University, i publicirao ga 1974. Rete algoritam je osnova za skoro sve BRMS sustave, s tim da se koriste različite modifikacije izvornog Rete algoritma (naročito one koje smanjuju potrebu za količinom RAM memorije).

5. IMPLEMENTACIJA POSLOVNIH PRAVILA SA ORACLE SOA SUITE

Prvi komercijalni RSUBP pod imenom Oracle ponudila je 1979. godine kompanija Relational Software Inc. (osnovana je 1977.), koja se kasnije preimenovala u Oracle Corporation. Već 80-tih godina se Oracle nije bavio samo sustavima za baze podataka, već i izradom aplikacija uz pomoć vlastitih 4GL alata/jezika Forms i Reports. Ti su alati prvo služili za izradu mainframe aplikacija, od 90-tih i klijent-server aplikacija, a od 2000. podržavaju i Internet rad (ali ne kao servlet/JSP aplikacije). Oracle se rano uključio u Java "struju", pa već od (otprilike) 2000. nudi i vlastiti Java EE aplikacijski server. Oracle je rano krenuo i u SOA arhitekturu. Oracle

je 2009. kupio firmu BEA, značajnu na području aplikacijskih servera i SOA arhitekture, a ove godine (2010.) i firmu Sun (koja je vlasnik Jave).

5.1 Oracle Fusion arhitektura i Oracle SOA Suite

Na slici 4. je prikazano kako Oracle pokušava u svojoj Fusion arhitekturi objediniti tradicionalni model (web) aplikacija i SOA model:

Zanimljivo je kako se u [11] objašnjava potreba za novom (fuzioniranom) arhitekturom, iako se poslovni procesi u svojoj biti nisu promijenili. Prema [11], dosadašnja rješenja često su temeljena na batch obradama, i to iz (barem) dva razloga. Prvo, prije SOA arhitekture Human Workflow se nije mogao (lako) uklopiti u tradicionalna softverska rješenja. Drugo, dosta transakcija je dugotrajno, i ne uklapaju se u standardne kratkotrajne transakcije baze podataka. SOA je tu dala svoj doprinos pomoću asinkronih transakcija i pomoću koncepta kompenzacije (compensation). Kompenzacija je postupak oporavka od grešaka, sličan po konceptu ROLLBACK operaciji u bazama podataka (nažalost, često kompleksan za programiranje).

Oracle SOA Suite je (složeni) softver za SOA arhitekturu, koji se kupuje kao dodatna opcija iznad Oracle WebLogic Suite (aplikacijski server dobiven kupovinom firme BEA). No, na Oracle SOA Suite vežu

Slika 5. Oracle SOA, BPM i Governance: Izvor [15]

Slika 4. Oracle Fusion arhitektura kao evolucija tradicionalnog modela; Izvor: [11]


20

se i drugi alati. Kako pokazuje slika 5., to su BPM Suite, alat za upravljanje poslovnim procesima (modeliranje, simuliranje, optimizacija procesa) i alat Governance. Ta dva alata dijele zajedničke komponente sa Oracle SOA Suite (postoji, ali nije prikazan na slici, i Data Integration Suite, koji čine servisi za integriranje podataka):

Oracle SOA platforma (koju uglavnom čini Oracle SOA Suite) može se prikazati kao na slici 6. (BAM uobičajeno znači Business Activity Monitoring, a CEP znači Complex Event Processing tj. procesiranje složenih dogañaja; CEP komponenta monitorira streams, tj. potoke dogañaja i povezuje naizgled nepovezane dogañaje u uzorke, a aplikacije su obično risk management, fraud detection, intrusion detection, compliance):

Kako je već rečeno, SOA Suite nije jednostavan alat. Za njegovo funkcioniranje potrebno je instalirati ove alate: � Oracle RSUBP; � Oracle WebLogic Server; � Oracle SOA Suite; � Oracle JDeveloper (za razvoj); � SOA ekstenzija za JDeveloper (za razvoj).

Nakon toga je potrebno: � kreirati u Oracle bazi sheme za Oracle SOA Suite

komponente; � kreirati repozitorij (pomoću Repository Creation

Utility); � kreirati WebLogic domenu za SOA projekt (koristeći

WebLogic Configuration Wizard).

Da bi olakšao rad sa različitim komponentama i smanjio potrebu za učenjem brojnih alata za dizajniranje, Oracle je u JDeveloper-u napravio Composite Editor, u kojem se različite SOA komponente (uključujući i poslovna pravila) mogu definirati na grafički način, kao na slici 7.

5.2 Oracle Business Rules

Što se tiče poslovnih pravila, Oracle tu ima dvije varijante. Starija varijanta, koja je nastala oko 1995. godine, kada se zahuktalo istraživanje oko poslovnih pravila (otprilike tada je nastala i organizacija Business Rules Group, BRG), bavi se implementacijom poslovnih pravila unutar (Oracle) RSUBP-a.

No, budući da se Oracle vrlo brzo uključio u Java "struju" (koja je takoñer krenula 1995.), napravio je rješenje poslovnih pravila i izvan baze. Zapravo, Oracle je iskoristio open source rješenje Jess. Kako se navodi u [5], Jess je pisan u potpunosti u Javi, a napravio ga je Ernest Friedman-Hill sa Sandia National Laboratories (Livermore, CA). Jess je originalno bio inspiriran CLIPS jezikom za ekspertne sustave. Koristeći Jess, može se napisati Java softver koji radi inferenciranje na temelju deklarativnih pravila. Jess koristi Rete algoritam, a podržava i povezivanje unaprijed i unatrag (forward / backward chaining). Oracle je preuzeo i prilagodio Jess kao vlastito rješenje za stroj za pravila (rules engine) - Oracle Business Rules.

Oracle Business Rules može se koristiti i u SOA arhitekturi i izvan nje. Oracle Business Rules sastoji se od sljedećih komponenti, koje se koriste za vrijeme modeliranja ili izvoñenja: � Oracle Business Rules RL Language: jezik sličan

Javi za pisanje poslovnih pravila; � Oracle Business Rules SDK: Java biblioteka za

manipulaciju poslovnim pravilima; � Oracle Business Rules Designer: ekstenzija za

JDeveloper IDE, vizualni alat za kreiranje i

Slika 6. Oracle SOA platforma; Izvor: [15]

Slika 7. SCA (Service Component Architecture) Composite Editor; Izvor: [15]


modificiranje poslovnih pravila; interno koristi Oracle Business Rules SDK;

� Decision Component: mehanizam za objavljivanje poslovnih pravila kao servisa u Oracle SOA aplikaciji;

� Oracle Business Rules Engine: namijenjen za Java EE aplikacije (ne-SOA).

Decision Service komponente mogu raditi na dva načina, statefull i stateless, kao što pokazuje slika 8.

5.3 Modeliranje poslovnih pravila u Oracle Business Rules (OBR) Designeru

Integracija poslovnih pravila sa BPEL-om i ostalim elementima SOA arhitekture počinje već za vrijeme modeliranja poslovnih pravila. Oracle JDeveloper je alat kroz koji se mogu modelirati poslovne činjenice (engl. business terms), poslovna pravila i poslovni procesi. Poslovna činjenica je bilo što od interesa za posao. U Oracle Business Rules (OBR), poslovne činjenice nazivaju se svojstva (engl. properties).

U SOA aplikaciji, najveći broj poslovnih činjenica modelira se korištenjem XML shema editora u

JDeveloperu, ili se preuzima iz definicije postojećih SOA servisa.

Poslovna pravila imaju IF dio i THEN dio. IF dio testira jednu ili više poslovnih činjenica. Ako test proñe, izvršava se jedna ili više akcija iz THEN dijela, a akcija može biti dodavanje ili mijenjanje poslovnih činjenica.

Primjer jednog složenijeg pravila je:

IF (ako) je ukupni iznos artikala koji su označeni kao pogodni za besplatnu isporuku i koji se otpremaju na istu destinaciju veći od 40$

THEN (tada) isporuka tih artikala je besplatna.

Na slici 9. prikazuje se kako se to pravilo definira u Oracle JDeveloperu, u alatu koji se naziva Oracle Business Rules (OBR) Designer.

U nekim slučajevima je pogodnije poslovno pravilo umjesto u IF … THEN … obliku, definirati u obliku tablice odlučivanja. To su slučajevi kada nekoliko sličnih pravila koristi kombinacije vrijednosti za više poslovnih činjenica.

Npr. pretpostavimo da želimo kreirati isporuku kada svi artikli za odreñenu destinaciju postoje na zalihi, ili kada

Slika 8. Decision Service arhitektura; Izvor: [13]

Slika 9. Primjer jednog složenijeg pravila definiranog sa JDeveloper OBR Designerom; Izvor: [14]


22

su samo neki artikli na zalihi, ali je kupac ili visoko rangiran ili je to kupac koji plaća isporuku koja će uslijediti unutar 7 dana, ili kada je to kupac koji ne plaća isporuku ali će isporuka uslijediti unutar 14 dana (u pravilu).

Trebamo odluke tipa da/ne za svaku kombinaciju narudžba/destinacija, temeljeno na 5 poslovnih činjenica: 1. svi artikli postoje na zalihi (da/ne oznaka) 2. neki artikli postoje na zalihi (da/ne oznaka) 3. kupac je visoko rangiran (da/ne oznaka) 4. kupac je onaj koji ne plaća isporuku (da/ne oznaka) 5. odgoda isporuke (definirana kao dani izmeñu datuma

narudžbe i maksimalnog datuma kada će doći roba koje nema na zalihi).

Te se poslovne činjenice mogu definirati koristeći XML shemu i importirati u OBR Designer, ili se mogu direktno implementirati u OBR Designeru, koristeći OBR Rule Language, kako pokazuje slika 10.

Te poslovne činjenice onda možemo koristiti u tablici odlučivanja, kako pokazuje slika 11.

5.4 Definiranje poslovnih procesa korištenjem BPEL-a i poslovnih pravila

Poslovni proces uobičajeno prima na ulazu XML dokument, poziva neke servise, te vraća XML dokument kao izlaz. Poslovni proces je takoñer servis, za kojeg se kaže da orkestrira druge servise. Tipični servisi koje proces Narudžbe može pozivati jesu servis za poreze, servis za prikaz stanja zaliha, servis za isporuku i dr. Zapravo, poslovna pravila su isto ugrañena u BPEL kao servisi, sa XML dokumentima koji sadrže poslovne činjenice.

Slika 12. prikazuje fragment BPEL procesa za narudžbe (interni procesi prikazani su žutom, a eksterni plavom bojom):

Kada se odlučuje o tome koji dio poslovnog procesa modelirati kao BPEL dijagram, a koji dio kao poslovna pravila, uobičajeno se [14] poslovna pravila primjenjuju za rješavanje složenih odluka o tome što dalje raditi u poslovnom procesu i za deklarativni pristup, validaciju, spajanje i transformaciju XML dokumenata.

5.5 Testiranje, stavljanje u implementaciju i praćenje poslovnih pravila

Da bi se na pravi način testirali BPEL procesi koji koriste poslovna pravila, potrebno je testirati web servise koje proces poziva, poslovna pravila koja koristi, te sam proces koji orkestrira te servise i pravila.

Poslovna pravila i tablice odlučivanja mogu se jedinično testirati (unit testing) kroz OBR Designer, bez potrebe da se modelira poslovni proces (koji ih koristi), a pogotovo ne treba ništa staviti u implementaciju (engl. deployment). To uveliko poboljšava produktivnost, jer se poslovna pravila i poslovni procesi mogu razvijati paralelno. Uobičajeno najteži dio kod testiranja BPEL procesa je simulacija eksternih procesa koje BPEL proces poziva. Oracle SOA radno okruženje (engl. framework) za testiranje olakšava taj dio testiranja.

Nakon testiranja, SOA aplikacija se kroz JDeveloper priprema za stavljanje u implementaciju i implementira se na aplikacijskim serverima (jednom ili više), pri čemu se repozitorij XML dokumenata realizira kroz sustav za

Slika 10. Definiranje fakta u OBR Designeru kroz OBR Rule

Language; Izvor: [14]

Slika 11. Tablica odlučivanja (Decision Table) u OBR Designeru; Izvor: [14]


upravljanje bazom podataka. Više BPEL strojeva (BPEL engines) može raditi paralelno u grozdu (klasteru) aplikacijskih servera, omogućavajući lakšu skalabilnost i veću raspoloživost. S druge strane, stroj za BPEL i stroj za poslovna pravila (BR engine) rade unutar iste JVM, što ubrzava komunikaciju meñu njima.

Za vrijeme izvršavanja se sa Oracle Enterprise Managerom može monitorirati stanje sustava. Što se tiče Decision Service komponenata, mogu se promatrati greške ili statistike o performansama na razini sustava, što prikazuje slika 13.

6. ZAKLJU ČAK

Iako je IT tehnologija uvijek bila vezana uz poslovnu tehnologiju, SOA arhitektura još više naglašava povezanost poslovnih procesa i IT aplikacija koje ih podupiru. Neki drže da je SOA arhitektura sljedeća stepenica u razvoju softvera, jer postoji mišljenje da objektno-orijentirane metode nisu donijele obećani napredak na povezivanju IT tehnologije sa poslovnim sustavom. Neki navode da je jedno od mogućih objašnjenja i to da dosadašnje objektno-orijentirane metode nisu zaista bile prave OO metode.

Poslovni procesi izvode se uz zadovoljavanje nekih poslovnih pravila (Business Rules, BR), od kojih su neka usko vezana za pojedini proces, a druga se mogu primijeniti na različite poslovne procese.

Kako se navodi u [5], i SOA i poslovna pravila imaju jedan zajednički cilj – povećanje razine apstrakcije softverskih sučelja, jer ta sučelja moraju prije svega

podržavati poslovni sustav, a ne informacijski sustav. Kako se navodi, ako nam je glavni cilj da IT bolje povežemo sa poslovnim sustavom, onda SOA arhitektura sama za sebe nije dovoljna, već trebamo separirati poslovna pravila od programskog koda. U takvom spoju SOA i poslovnih pravila, stroj za poslovna pravila (rules engine) postaje odvojena komponenta (odvojeni servis) koji izvršava neka poslovna pravila (ona koja su zajednička za više procesa), a neka poslovna pravila (koja su vezana samo za jedan proces) izvodi sam proces.

Danas ima dosta proizvoñača BRMS sustava (sustava za upravljanje poslovnim pravilima), a neki od njih su i proizvoñači SOA rješenja (naročito se to odnosi na najveće igrače: IBM, Microsoft i Oracle). Što se tiče SOA rješenja, često ona sadrže (ili su bar vezana za) i BPM softver (softver za upravljanje poslovnim procesima). Takvi integrirani alati često su vrlo kompleksni i često traže poznavanje većeg broja formalnih jezika, koji nisu jednostavni (bez obzira da li su grafički ili negrafički).

U toj kompleksnosti, javljaju se i takvi pristupi da se razvoj softverskih rješenja mora pojednostaviti, odnosno napraviti na način koji bi omogućio poslovnim ljudima (neinformatičarima) da (više) sudjeluju u razvoju softvera. Ti pristupi izgledaju obećavajući, s tim da vjerojatno vrijedi ova istina: jednostavnije stvari mogu se (ili bi se trebale moći) napraviti na jednostavan način, a teške stvari mogu se (nažalost) napraviti samo na težak način - ali ne teži nego što je nužno.

Slika 12. Fragment BPEL procesa za obradu narudžbi; Izvor: [14]


Literatura:

1 Buelow, H. i dr. (2009): Getting Started with Oracle SOA Suite 11g R1 – A Hands-On Tutorial, Packt Publishing

2 Bye, P. (2007): Service-Oriented Architecture: Delivering for Business (white paper), Unisys Corporation, www1.unisys.com:8081/eprise/main/admin/micro/doc/Service_Oriented_Architecture.pdf (lipanj 2010.)

3 Date, C.J. (2005), Database in Depth, O'Reilly Media

4 Debevoise, T. (2010): The Past, Present, and Future of Business Rules Towards True Business Enablement (white paper), Innovations Software Technology Corp., www.visual-rules.com/white-paper-debevoise-business-rules-history.html (lipanj 2010.)

5 Graham, I. (2006): Business Rules Management and Service Oriented Architecture - A Pattern Language, John Wiley & Sons

6 Hurwitz, J. i ostali (2007): Service Oriented Architecture For Dummies, Wiley Publishing

7 Havey, M. (2005): Essential Business Process Modeling, O'Reilly Media

8 Martin, W. (2006): Role of Business Rules in SOA (white paper), Wolfgang Martin team, www.innovations-software.com/fileadmin/pdf-en/white-paper/business-rules-processes-soa.pdf, (lipanj 2010.)

9 Martin, W. (2008): Rule-Based Composition of Agile Business Services (white paper), Wolfgang Martin team, www.wolfgang-martin-team.net/whitepaper.php (lipanj 2010.)

10 Meyer, B. (1997), Object-Oriented Software Construction, Prentice Hall

11 Mills, D. i dr. (2010), Oracle JDeveloper 11g Handbook - A Guide to Oracle Fusion Web Development, McGraw-Hill

12 Oracle priručnik (2000): CDM Standards and Guidelines Library Volume 1 Requirements Modeling using Oracle Designer

13 Oracle priručnik (2009): User's Guide for Oracle Business Rules 11g Release 1

14 Oracle whitepaper (2008): Smart Business Processes using Oracle Business Rules

15 Oracle workshop materijal (2010): Oracle SOA Suite 11g (materijal s workshop-a održanog u Oracle Hrvatska, Zagreb, 08.-09.02.2010)

16 Ross, R.G. (2003): Principles of the Business Rule Approach, Addison Wesley

17 Von Halle, B. (2002), Business Rules Applied: Building Better Systems Using the Business Rules Approach, John Wiley & Sons

18 Vrček, N. (2009): Sigurnost otvorenih sustava (materijali s predavanja), FOI Varaždin

Slika 13. Praćenje izvršavanja poslovnih pravila; Izvor: [14]


Podaci o autoru:

Zlatko Siroti ć, dipl.ing. Istra informatički inženjering d.o.o. Ruže Petrović 12 52100 Pula e-mail: [email protected] Autor radi više od 25 godina na informatičkim poslovima. Najveći dio radnog vijeka proveo je u poduzeću Istra informatički inženjering d.o.o, Pula, gdje radi i sada. Radio je na svim poslovima u izradi softvera: analiza, dizajn, programiranje, uvoñenje, obuka korisnika, održavanje. Oracle softverske alate (baza, Designer CASE, Forms 4GL, Reports, JDeveloper IDE, Java) koristi zadnjih 15 godina. Objavljivao je stručne radove na kongresima "Hotelska kuća", na konferencijama CASE, KOM, HrOUG (Hrvatska udruga Oracle korisnika), u časopisima "InfoTrend" i "Ugostiteljstvo i turizam", a neka njegova programska rješenja objavljena su na web stranicama firmi Quest i Oracle.


SIGURNOST U SERVISNO ORIJENTIRANOJ ARHITEKTURI

SECURITY IN SERVICE-ORIENTED ARCHITECTURE

mr.sc. Tomislav Vida čić, dr.sc. Sandro Geri ć

SAŽETAK:

Zašto servisno orijentirana arhitektura predstavlja novu prijetnju sigurnosti informacijskih sustava? Odgovor se krije u samoj prirodi servisno orijentiranih arhitektura. Jedna od temeljnih karakteristika servisno orijentiranih arhitektura je višestruka uporaba servisa, što automatski znači da sigurnosni propust u nekom servisu znači višestruku ranjivost odreñenog informacijskog sustava koji koristi taj servis. Nadalje sama implementacija servisa može biti nesigurna, na primjer naslijeñeni sustavi koji su se u praksi dokazali kao sigurni, implementirani u servisno orijentiranu arhitekturu mogu biti izloženi napadima. Samim time što servisno orijentirana arhitektura ima distributivni karakter, mrežna infrastruktura postaje posebno osjetljiva na napade. U ovome radu baviti ćemo se temeljnim problemima sigurnosti u servisno-orijentiranim arhitekturama.

ABSTRACT:

Why Service Oriented Architecture represents a new threat to the security of information systems? The answer lies in the nature of service-oriented architecture. One of the fundamental characteristics of service-oriented architecture is a service reusability, which automatically means that a security flaw in one service leads to a multiple vulnerabilities of specific information system that uses this service. Further implementation of the service itself may be uncertain, for example, legacy systems that have in practice proven to be safe, implemented in a service-oriented architecture can be exposed to attacks. Thus the service-oriented architecture has the distribution character of the network infrastructure becomes very vulnerable to attacks. In this paper we address the fundamental security issues in service-oriented architectures.

1. UVOD

Servisno-orijentirane arhitekture (SOA), kao jedan od novijih oblika arhitektura informacijskih sustava predstavljaju izazov u području implementacije ICT tehnologija. SOA predstavlja iznimno kompleksan oblik IS čija implementacija podrazumijeva rješavanje kompleksnih problema iz tehnoloških, organizacijskih, zakonodavnih i posebice sigurnosnih aspekata.

Kako se danas kao temeljna tehnologija za implementaciju SOA-e nametnula tehnologija web servisa, suvremene SOA-e su naslijedile i prednosti i nedostatke te tehnologije, pa tako i njezine sigurnosne elemente. Na razini implementacije, SOA sigurnosna rješenja se uglavnom temelje na sigurnosnim mehanizmima implementiranima u web servise, poput: trusted communication, SOAP, WS-Security, WS-SecureConversation, trusted services, WS-Policy, WS-PolicyAssertions, WS-PolicyAttachment, WS-SecurityPolicy, WS-Authorization, WS-Privacy, i WS-Trust, WS-Federation.

Sa organizacijskog aspekta uvoñenje sustava sigurnosti u SOA-u ima iste ciljeve kao i uvoñenje sustava sigurnosti u bilo koji drugi oblik arhitekture informacijskog sustava – osigurati raspoloživost, tajnost i integritet resursa IS-a. No, kako se SOA razlikuje od tradicionalnih arhitektura potrebno je donekle modificirati sigurnosne mehanizme i načine njihove primjene. Pri tome važnu ulogu imaju specifični sigurnosni standardi i protokoli definirani za upotrebu na programskoj tehnologiji web servisa, ali i primjenjivi i na SOA-u, pri čemu je najvažniji web service security standard, o čemu će biti riječi u ovom radu.

2. UVOD U SIGURNOST SERVISNO-ORIJENTIRANIH ARHITEKTURA

SOA ima neke karakteristike koje ju čine jedinstvenom i različitom u odnosu na „tradicionalne“ arhitekture informacijskih sustava. Zbog toga primjena SOA-e zahtijeva djelomično drugačiji pristup i način organizacije sustava informacijske sigurnosti u odnosu na sustave sigurnosti kod „tradicionalnih“ arhitektura IS-a [6]. Razlike proizlaze iz različitosti koncepta SOA-e u odnosu na tradicionalni IS. Uobičajeno je da se SOA sastoji od više programskih komponenti (web servisa) koje mogu biti razvijene u različitim programskim tehnologijama, od strane različitih tvrtki ili pojedinaca, a koje mogu djelovati na različitim programskim platformama, te pod različitim sustavima informacijske sigurnosti. Sve te komponente povezane zajedno čine i trebaju osigurati funkcionalnost jednaku onoj tradicionalnog informacijskog sustava, te jednaku razinu informacijske sigurnosti. Slika 1. pokazuje strukturu temeljnog poslovnog modela servisno-orijentirane arhitekture [20][22], a slika 2. prikazuje konceptualni primjer servisno-orijentirane arhitekture uz razlikovanje interne i eksterne SOA-e [6] [12][20].

Slika 1. Temeljni poslovni model SOA-e


Promatrajući temeljni poslovni model SOA-e vidljivo je da on sadrži tri temeljne komponente – tražitelja usluge (npr. tvrtku koja traži programsku komponentu, to jest web servis odreñene funkcionalnosti), pružatelja usluge (npr. tvrtku koja je razvila, oglašava i prodaje – odnosno iznajmljuje svoje servise), te registar (direktorij) servisa (npr. web mjesto oglašavanja i pretraživanja ponude servisa). Registar servisa se koristi od strane tražitelja usluge (za pronalaženje željenog servisa) i pružatelja usluge (za oglašavanje raspoloživih servisa). Nakon što tražitelj usluge pronañe i identificira željeni servis u registru servisa sklapa se ugovor o razini usluge (eng. service level agreement) izmeñu tražitelja i pružatelja usluga, te traženi servis može biti ugrañen u servisnu arhitekturu tražitelja usluga. SOA se obično sastoji od više servisa, pri čemu svaki servis istovremeno može biti uključen u više različitih servisnih arhitektura. Ako SOA ne prelazi organizacijske granice tada se radi o tzv. internoj SOA-i, ako pak SOA prelazi organizacijske granice (npr. kod povezivanja više informacijskih sustava u procesu upravljanja opskrbnim lancem) tada se radi o tzv. eksternoj SOA-i (Slika 2).

Sigurnost servisno orijentiranih arhitektura usko je vezana uz poslovne potrebe za sigurnošću. Tradicionalne monolitne aplikacije svoju sigurnost su temeljile na osiguravanju pristupa, što znači da je korisničko sučelje u neku ruku bilo temeljna točka na kojoj se je identificirao korisnik. Sigurnost unutar aplikacije je ostavljeno na brigu proizvoñaču aplikacije. No, u svijetu servisno orijentiranih arhitektura servisi su postali problem platforme na kojoj se aplikacija temelji, pa je definiranje pristupa servisima i sama struktura izgrañena na njima postala složenija i prilično kompleksnija. Autentifikacija na razini korisničkog sučelja tek je prvi korak, nakon kojeg se na temelju korisničkog identiteta i dodijeljene mu uloge provjera odvija kroz kompozitnu aplikaciju za svaki servis zasebno. Slika 3. prikazuje usporedbu sigurnosti IS-a prije i poslije SOA.

Servisno orijentirane arhitekture izmijenile su dosadašnju sliku sigurnosti informacijskih sustava. Za razliku od čvrstih veza u tradicionalnim arhitekturama servisno orijentirane arhitekture imaju daleko labavije veze izmeñu autorizacija i autentifikacije. Tabela 1. prikazuje sigurnosni utjecaj s obzirom na različite oblike distribuiranih arhitektura. Sigurnosni aspekti su modelirani kao dio servisnih ugovora koji su temeljeni na deklarativnim modelima kriptografskih protokola i potrebnih sigurnosnih tokena. Kreirane su i nove XML sigurnosne tehnologije kao što je WS SOA. Različiti koncepti distribuiranih aplikacija sadrže različite

elemente na koje posebno treba obratiti pozornost s obzirom na sigurnost.

Slika 3. Usporedba sigurnosti informacijskih sustava prije i

poslije servisno orijentiranih arhitektura

Izazovi koji se pojavljuju u servisno orijentiranim arhitekturama dijele se na dva temeljna dijela, a to je kako osigurati svaki servis zasebno i kako osigurati krajnju kompoziciju servisa. Osim toga ozbiljno shvaćanje sigurnosti na razini korporacije zahtjeva integriranje i upravljanje sigurnošću na razini korporacije, jer sigurnost informacijskog sustava u velikoj mjeri predstavlja problem poslovanja, a ne problem tehnologije.

Slika 4. Sigurnost kao poslovni proces

Slika 2. Konceptualni primjer SOA-e


Iz toga proizlaze 4 temeljna sigurnosna izazova u domeni SOA-e [6][9]: 1. Sigurnost i nadzor nad podacima, 2. Razvoj i implementacija SOA-e, 3. Autorizacija i 4. Zahtjevi za gotove (eng. off the shelf) komponente.

Sukladno tome životni ciklus upravljanja sigurnošću može se promatrati i kao poslovni proces Slika 4.

Kao što je vidljivo iz slike 5. koja prikazuje sigurnosni standard ISO-7498-2 upravljanje sigurnošću informacijskih sustava je prilično kompleksan zadatak. Temeljni elementi upravljanja sigurnošću su: � Sigurnosni servisi, � Sigurnosni mehanizmi i � Sigurnosni objekti.

Slika 5. ISO-7498-2 sigurnosni standard

Sigurnosni servisi predstavljaju jedan od temeljnih elemenata upravljanja sigurnošću u servisno orijentiranim arhitekturama. Identifikacija je proces u kojem se utvrñuje da li je identitet korisnika ispravan. Provjera autentičnosti je proces kojim servis potvrñuje da korisnik može koristiti odreñeni identitet na temelju zaporke, certifikata, tokena, itd. Autorizacija je proces kojim se odreñuje da li odreñeni identificirani entitet ima

ovlasti pristupa nekim uslugama u nekoj sigurnoj domeni. Provjera integriteta podataka je proces u kojem se potvrñuje da sadržaj odreñenih poruka nije mijenjan. Povjerljivost podataka ima za cilj zaštititi podatke od neautoriziranog otkrivanja. Obično se za osiguravanje povjerljivosti podataka koristi postupak enkripcije. Revizija odreñuje odgovornost pojedinih nositelja odgovornosti. Nerazdvojnost podataka ima ulogu kod osiguranja potvrde kod dviju strana koji su razmijenili poruke koji potvrñuju tu razmjenu.

Sigurnosni mehanizmi postoje da bi osiguravali i podržali sigurnosne servise. Dijelimo ih na dvije temeljne kategorije i to na: specifične sigurnosne mehanizme koji se koriste da bi osigurali specifične sigurnosne servise i na opće sigurnosne mehanizme koji nisu specifični za odreñene servise. Specifični sigurnosni mehanizmi sadrže nekoliko temeljnih mehanizama sigurnosnih zaštita i to: mehanizam enkripcije, mehanizmi digitalnog potpisa, mehanizme kontrole pristupa, mehanizme provjere integriteta podataka, mehanizme razmjene autentifikacije, mehanizme nadopunjavanja prometa, kontrole rutanja podataka i mehanizme ovjere podataka. Mehanizmi enkripcije služe za osiguranje povjerljivosti podataka. Tu postoji cijeli niz algoritama koji služe za enkripciju podataka kao što su DES ili RSA, no koji nisu dio ISO standardizacije. Mehanizmi digitalnog potpisa osiguravaju nepovredivost sadržaja podataka, a uključuju proceduru potpisivanja i verifikacije. Oba mehanizma predstavljaju temelj za izgradnju mehanizma za razmjenu autentifikacije. Mehanizmi kontrole pristupa na temelju informacija o korisniku odlučuju do kojih resursa će korisnik imati pristup. Mehanizmi koji osiguravaju integritet podataka onemogućavaju promjenu podataka. Mehanizmi nadopunjavanja prometa osiguravaju povjerljivost tokova podataka na način da skrivaju stvarne količine podatkovnog prometa. Mehanizmi rutanja podataka koriste se za izbjegavanje slanja osjetljivih podataka kroz nesigurne kanale. Mehanizmi ovjere podataka služe za provjeru integriteta i porijekla podataka. Opći sigurnosni mehanizmi sastoje se od mehanizma pouzdane funkcionalnosti, mehanizma sigurnosnih oznaka, detekcije dogañaja, sigurnosne revizijske oznake, sigurnosnog oporavka. Mehanizam pouzdane funkcionalnosti uključuje kombinaciju softverske i hardverske funkcionalnosti koja osigurava pouzdan pristup sigurnosnim mehanizmima. Mehanizmi sigurnosnih oznaka omogućavaju da svaki resurs ima sigurnosnu oznaku koja označava razinu osjetljivosti podataka. Mehanizmi otkrivanja dogañaja otkrivaju dogañaje legalnih i ilegalnih aktivnosti nad podacima. Sigurnosne revizijske oznake omogućavaju otkrivanje i istragu prošlih dogañaja veznih uz sigurnost. Mehanizmi sigurnosne obnove uključuju mehanizme rješavanja zahtjeva oporavka zbog sigurnosnih propusta.

Sigurnost servisno orijentiranih arhitektura predstavlja prilično kompleksno područje koje danas još uvijek ima dosta prostora za daljnje istraživanje. Servisno

Tabela 1. Sigurnosni utjecaj s obzirom na različite oblike distribuiranih arhitektura

Objektno - orijentirani Komponentno temeljeni dizajn Servisno orijentirani sa web

servisima

Paradigma Temeljni elementi za

izgradnju aplikacije su objekti.

Implementacijski model je ovisan o tehnologiji komponenti

u kojoj su izvedeni.

Servisi su kreirani kao anonimne i standardizirane

aplikacije.

Sigurnosni

utjecaji

Proizvoñači osiguravaju sigurnosne mehanizme,

autentifikaciju, autorizaciju i reviziju tokom izvoñenja

(npr. Java authentification and authorization services).

Komponentni model osigurava specifične modele sigurnosti.

Interoperatibilni industrijski sigurnosni standardi barataju

sa sigurnosti porukama, identifikacijom i sigurnosti

servisa. (npr. WS-Security)


orijentirana arhitektura je interoperatibilna što znači da uključuje najrazličitije mehanizme zaštite. Temeljne sigurnosne funkcije koje sadrže informacijski sustavi su: � Autentifikacija (ovjera), � Autorizacija, � Auditing (revizija), � Uvjerenje (osiguranje)

Autentifikacija se bavi provjerom autentičnosti nekog zahtjeva. Često je to na razini sustava servis koji se bavi obradom pravila sustava i provedbom sigurnosnih protokola. Autorizacije se obično izvode na lokalnoj razini pa su na taj način na odreñeni način i zaštićene. U servisno orijentiranim arhitekturama sve se svodi na servise, pa se tako neke autorizacije mogu implementirati na globalnoj razini, a neke se mogu mapirati na servise i njihove operacije. S dizajnerske perspektive autorizacije se mogu vidjeti na oba sustava i servisne razine. Auditing servisi osiguravaju otkrivanje i odgovore na pitanja koji su u vezi sa objektima koji izvode aktivnosti. Servisi osiguranja predstavljaju skup sistemskih procesa koji povećavaju sigurnost sustava u koji su uključeni.

Dva temeljna problema i dalje predstavljaju popriličan problem u SOA informacijskim sustavima: � Enkripcija i dekripcija i � Kontrola pristupa.

Za problem enkripcije i dekripcije razvijeni su standardi kao što je WS-Security. On poruku formatiranu kao XML kriptira i ona time nije čitljiva drugim sustavima.

3. SIGURNOSNI ZAHTJEVI SERVISNO ORIJENTIRANIH ARHITEKTURA

Temeljni funkcionalni zahtjevi koje sigurnost mora riješiti su: povjerljivost, integritet podataka, autentifikacija, autorizacija i zaštita od napada u informacijski sustav. Povjerljivost onemogućava otkrivanje informacija neovlaštenim korisnicima ili sustavima. Integritet podataka se odnosi na onemogućavanje manipuliranja podacima bez potrebnih dozvola i odobrenja. Autentifikacija predstavlja proces ovjere korisnika, a zaštita od napada osigurava da napadači ne mogu dobiti kontrolu nad aplikacijama. Osim funkcionalnih zahtjeva postoje i nefunkcionalni zahtjevi sigurnosti servisno orijentiranih arhitektura, one su interoperatibilnost, upravljivost i jednostavnost. Interoperatibilnost omogućava kompatibilnost usluga, upravljivost je pojam kojim se označava lakoća upravljanja sigurnosnim rješenjem i jednostavnost predstavlja kompleksnost ugradnje sigurnosnog rješenja u postojeći informacijski sustav.

Kako bi se uspostavila tražena razina sigurnosti, te razriješili spomenuti sigurnosni problemi kod servisno orijentiranih arhitektura, najčešće se koristi model sigurnosti definiran Web Services Security Model (WSS) standardom usvojenim od strane organizacije OASIS. [7][9]

WSS definira proces uvoñenja sigurnosti web servisa kroz uspostavu 4 specifična područja [7] [9][25]: � Trusted communication koje obuhvaća SOAP,

WS-Security, WS-Secure Conversation, � Trusted service koje obuhvaća WS-Policy, WS-

Policy Assertions, WS-Policy Attachment, WS-Security Policy,

� WS-Authorization, WS-Privacy i � Trusted Web koje obuhvaća WS-Trust, WS-

Federation.

Odnosi izmeñu navedenih područja implementacije sigurnosnih mehanizama u obliku sigurnosnih slojeva prikazani su na slici 6. [7] [25].

Slika 6. Arhitektura WSS standarda

Ako se promatra temeljni poslovni model servisno-orijentirane arhitekture (prikazan na Slici 1.), tada se primjena WSS standarda ponajprije odnosi na stranu pružatelja usluga – prilikom razvoja web servisa potrebno je implementirati i u sam programski proizvod uključiti pojedine sigurnosne mehanizme koje definira WSS (npr. komponente Trusted communication, WS-Authorization, WS-Privacy). No, WSS se reflektira i na stranu tražitelja usluga, i to ponajprije kroz procese koreografije i orkestracije web servisa (procesi povezivanja više web servisa u jedinstvenu cjelinu nove SOA arhitekture), pri čemu je naglasak na primjeni i implementaciji komponenti definiranih Trusted service, Trusted Web i WS-Authorization slojevima.

3.1 Trusted Communication

Budući da se sva interakcija i upravljanje web servisima kao programskom tehnologijom temelji na razmjeni XML poruka, WSS standard definira tzv. sloj razmjene poruka (eng. trusted message-spanning layer) koji treba osigurati tajnost i povjerljivost prilikom razmjene poruka izmeñu web servisa. Spomenuti sloj služi kao temelj za izgradnju dodatnih sigurnosnih mehanizama poput infrastrukture javnog ključa (PKI), Kerberosa, SSL-a i drugi [9][25]. Uz to, omogućava upotrebu sigurnosnih tokena, definiranih sigurnosnih domena, elektroničkog potpisa (naprednog, XML el. potpisa), te različitih metoda kriptiranja podataka [7]. Sloj Trusted Communication se realizira kao dodatno zaglavlje poruka (koje služi za definiranje već spomenutih sigurnosnih mehanizama poput elektroničkog potpisa, sigurnosnih tokena, kriptografskih mehanizama i algoritama) u elementima SOAP poruke (zaglavlju i tijelu SOAP poruke). U sklopu takvog zaglavlja poruka moguće je definirati tzv. „politiku povjerenja“ (eng. trust based policy) koja (poput elektroničkog potpisa) potvrñuje vjerodostojnost razmijenjene poruke i njezina pošiljatelja (drugog web servisa). Kako bi to omogućio WSS protokol sadrži okvir namijenjen definiraju takvih „politika povjerenja“ tzv. WS-Secure Conversation, koji korisnicima omogućuje definiranje „politika povjerenja“ te njihovu višestruku primjenu kod razmjene SOAP poruka [7][9][25].

3.2 Trusted Services

U okviru WSS standarda potrebno je definirati sigurnosne politike primjenjive na web servisa upravljane ovim standardom, te njihov opis pristupnim sučeljima web servisa. Pri tome koriste se sljedeće komponente WSS-a [9][25]:


� WS-Policy: definira temeljnu politiku sigurnosti, izjavu o politici sigurnosti te modele primjene politike sigurnosti.

� WS-Policy Assertions: definira općenite elemente politike sigurnosti (izjave, zaduženja prilikom implementacije...).

� WS-Policy Attachment: definira način povezivanja općenite politike sigurnosti definirane prethodnim komponentama sa servisima, uključivanjem u WSDL opis servisa ili povezivanjem kroz UDDI.

� WS-Security Policy: služi za opis elemenata sigurnosne politike pogodnih za WSDL i/ili UDDI opis servisa, te

� WS-Security: definira elemente sigurnosti razmjene poruka, provjera integriteta poruka te razmjene sigurnosnih tokena.

WS-Policy prvenstveno služi kao unaprijed definirani model pomoću kojeg je moguće definirati različite elemente sigurnosnih mehanizama korištenih kod WSS-a i to na razini prijenosa informacija (npr. razmjene poruka), korištenja resursa (web servisa), te čak na razini implementacije end-to-end poslovnih procesa [7][9][25] (pri čemu su sastavni dijelovi WS-Policy komponente i SAML i XACML).

3.3 Trusted Web

Jedan od glavnih ciljeva kod implementacije servisno-orijentirane arhitekture jest omogućiti ostvarivanje direktne i sigurne veze izmeñu svih uključenih servisa, odnosno posredno izmeñu tražitelja i pružatelja usluga čiji servisi su uključeni u arhitekturu. U okviru WSS standarda to je zadaća Trusted Web komponente. Postojanje sigurne i povjerljive veze izmeñu komponenti servisno-orijentirane arhitekture će omogućiti i sigurno funkcioniranje takve arhitekture u cijelosti. To se može postići samo uz pretpostavku da su isti ili podjednako kvalitetni sigurnosni mehanizmi implementirani u svim komponentama SOA-e. U tom slučaju WSS standard definira postojanje tzv. domena povjerenja (eng. trust domain) koje osiguravaju postojanje potrebne razine sigurnosti na razini komponenti, a zatim posredno i na razini čitave arhitekture [7]. Kod komunikacije i interakcije izmeñu više domena povjerenja WSS standard definira potrebu korištenja pouzdane treće strane, tzv. „sigurnosnog posrednika“ koji ima zadaću osigurati pouzdanu razmjenu sigurnosnih mehanizama (kriptografski ključevi, algoritmi, sigurnosni tokeni) potrebnu za osiguravanje pouzdane komunikacije izmeñu dvije ili više „domena povjerenja“.

3.4 Sigurnost SOA-e i sigurnost „tradicionalnih“ arhitektura IS-a

Može se zaključiti da WSS standard predstavlja pokušaj da se standardiziraju opći sigurnosni mehanizmi koje je potrebno primijeniti kako bi se postigla željena razina sigurnosti kod servisno-orijentiranih arhitektura, a da se pri tome koriste postojeća sigurnosna rješenja primjenjiva i na „tradicionalne“ arhitekture. Pri tome WSS ne specificira konkretne mjere i mehanizme, i ne razvija nove (poput elektroničkog potpisa, kriptografskih mehanizama ili kontrole pristupa), već uzima i koristi postojeća, gotova rješenja. WSS standard je prvenstveno usmjeren na osiguranje potrebne razine sigurnosti uz zadržavanje karakteristika kao što su interoperabilnost, fleksibilnost, dinamično rekonfiguriranje servisno-orijentiranih arhitektura. Na primjer, ako se WSS standard i njegovi mehanizmi koriste za osiguravanje interakcije izmeñu dviju internih

arhitektura organizacije A i organizacije B (slika 2), odnosno izmeñu njihovih single-sign-on (SSO) mehanizama, mehanizmi WSS-a se neće baviti detaljima uključenih SSO mehanizama već će samo djelovati na razini njihove meñusobne interakcije i razmjene poruka.

Osim WSS standarda postoji i mnogo drugih sigurnosnih rješenja i standarda koji imaju sličnu namjenu, poput CAPI (eng. Microsoft Crypto API), CDSA (eng. Common Data Security Architecture), GSS (eng. Generic Security Services), i GAA (eng. Generic Authorization and Access Control) [7], SAML, AON, RBS (eng. Rule Based Security) i drugi.

SAML je akronim (eng. Security Assertion Markup Language) i predstavlja okvir za razmjenu informacija vezanih uz sigurnost izmeñu dviju sigurnih strana. Koristi SSO (eng. Single Sign On) način logiranja. SAML se temelji na tri komponente i to: potvrde (autentizacije, atributi i autorizacije), protokol i povezivanje. Potvrde se razmjenjuju izmeñu strana i servisa uporabom protokola i veza. SAML se temelji na XML standardu.

AON je kratica za (eng. Application oriented networking) koji uključuje mrežne ureñaje namijenjene integraciji više računala. AON sadrži: sposobnost poboljšavanja XML poruka, osigurava siguran i brzi protok XML i ne XML poruka, osigurava konstantnu primjenu pravila koji se odnose na sigurnost prijenosa i unaprjeñuje XML tehnologije i servisnu arhitekturu.

Sigurnost temeljena na pravilima odvaja logiku sigurnosti i poslovnu logiku na taj način osiguravaju konzistentnost primjene sigurnosne politike izmeñu različitih aplikacija. Kod takve sigurnosne politike bitno je osigurati jednostavni razvoj i administraciju, konzistentnost sigurnosne provjere i interoperatibilnost sigurnosnih rješenja.

SOA model sigurnosti sastoji se od pet temeljnih servisa i to: autorizacijski servisi, autentifikacijski servisi, servisi identiteta, servisi povjerenja i servisi revizije (Slika 7.). Autorizacijski servisi bave se kontrolom pristupa servisima na setu pravila. Autentifikacijski servisi sastoji se od sigurnosnog tokena servisa koji može generirati i validirati autentifikacijska ograničenja. Servisi identiteta upravljaju, dijele, centraliziraju i omogućavaju identifikaciju informacija od strane više različitih izvora. Servisi povjerenja imaju sposobnost zaštite osjetljivih informacija od otkrivanja i mogu otkriti neautorizirane promjene na podacima. Servisi revizije osiguravaju mehanizam slanja, spremanja i izvještavanja na podacima poslanih tokom nekog dogañaja na sustavu.

4. VRSTE NAPADA NA INFORMACIJSKE SUSTAVE TEMELJENE NA SERVISNO-ORIJENTIRANIM ARHITEKTURAMA

Slika 7. Holistički model sigurnosti servisno orijentiranih

arhitektura


Napadi na informacijske sustava temeljene na servisno orijentiranim arhitekturama u biti se ne razlikuju mnogo od napada na koje su izložene Web aplikacije. Sigurnosne prijetnje koje su, prema statistikama najčešće u domeni SOA-e su:

� Uskraćivanje ili degradacija usluge (eng. Distributed Denial of Service (DDoS)) - Prijetnja koja djeluje na smanjivanje dostupnosti informacijskog resursa. Dostupnost, u kontekstu sigurnosti IS-a, podrazumijeva "da sve unaprijed definirane računalne mogućnosti, sama računalna infrastruktura, programska podrška i mogućnosti upotrebe moraju biti na raspolaganju legalnom korisniku". Do uskraćivanja usluga može doći na različite načine, npr. fizičkim napadom (palež, eksplozije, fizičko uništenje opreme), isključivanjem pomoćnih ureñaja (el. energija, agregati, klimatizacijski ureñaji), prirodnim katastrofama i slično, a svi oni rezultiraju fizičkim oštećenjem opreme ili zatrpavanje i preopterećenjem računalnog sustava (brisanje podataka, pretrpavanje prostora na disku, preopterećivanje procesora računala, zagušivanje mrežnog prometa)

� XMLDoS (eng. XML denial of service) je napad koji iskorištava DTD odnosno Document Type Defintion, odnosno mogućnost povlačenja entiteta koji su definirani u DTD-u. Rekurzivnim povlačenjem entiteta XML može prouzročiti DoS.

� Stražnja vrata - programsko rješenje koje se koristi kod razvoja softvera kako bi se olakšao pristup programera pojedinim dijelovima aplikacije može biti zloupotrebljeno za privilegiran pristup resursima računala bez ikakvih sigurnosnih provjera i kontrola.

� Otmice vremena korištenja elektroničkog servisa - korištenje tuñeg računala za izvršavanje nelegalnih aktivnosti u vremenu kad ga korisnik računala ne koristi, a nije se odjavio sa sustava (npr. prilikom odlaska na kratku pauzu ostavlja se nezaštićeno računalo);.

� Spoofing - je napad u kojemu počinitelji dolaze do željenih podataka koristeći se ponajprije slabostima Interneta i nedovoljnom pažnjom korisnika. Riječ je o napadu u kojem počinitelji od korisnika pomoću prijevara izvlače povjerljive podatke (poput brojeva kreditnih kartica, IP adresa, zaporki, e-mail adresa) te ih iskorištavaju za kasnije aktivnosti.

� Sniffing – ili njuškanje za zaporkama je vrsta napada koja koristi programe koji prate mrežni promet s ciljem "hvatanja" dijelova u kojima korisnik unosi svoje korisničko ime i zaporku.

� Umetanje SQL koda (eng. SQL Injection) - umetanje SQL-meta znakova u korisnički upit s ciljem izvršavanja upita u back-end sustavu baze. Obično se realizira kroz slanje upita s jednostrukim navodnikom (‘) – rezultat je poruka s detaljnim informacijama o back-end sustavu baze ili čak i omogućen pristup back-end dijelovima baze (uvijek ispunjiv Boolean upit). Za ovaj napad je bitno da se podaci dobiveni od strane servisa izvode direktno na SQL serveru i da naravno postoje ovlasti izvoñenje ubačenih SQL-a. Ova vrsta napada se sprječava provjerom podataka dobivenih od strane korisnika.

� Manipulacija cijenama - napad karakterističan samo za e-poslovanje. Ukupan iznos za plaćanje

se sprema u skriveno polje dinamički kreirane web stranice te napadač koristi proxy poslužitelj web aplikacije kako bi izmijenio iznos u trenutku njegove razmjene izmeñu web poslužitelja i korisničkog web preglednika.

� Buffer overflow - Slanje velike količine podataka (bitova) web aplikacijama koje nisu razvijene s ciljem obrade velikih količina podataka rezultira neželjenim posljedicama. Cilj napada je dobiti informaciju o pogrešci koja najčešće sadrži detaljnu putanju admin dijela poslužitelja.

� XSS - Cross-site scripting je napad usmjeren na krajnjeg korisnika. Temelji se na nedostatnoj verifikaciji od strane web aplikacije i povjerenju krajnjeg korisnika u URL web mjesta koje je napadnuto. Korisnik unosi podatke u web formu, koja ih obrañuje i ispisuje ih na web stranici zajedno sa originalnim korisničkim unosom. Ako nad podacima nije izvršen parsing napadač može umetnuti dio JavaScript koda kao korisnički unos. Takvim kodom moguće je modificirati URL, a korisnik ne sluteći prijevaru jednim klikom na “provjereni URL” pokreće izvoñenje skripte na svom računalu. Najčešći motiv XSS napada je: ukrasti cookie (zbog informacija o sesiji koje on sadrži), preusmjeriti korisnika na napadačevo web mjesto s kojeg će se izvršiti maliciozni kod pomoću ActiveX kontrola, realizirati phishing prijevaru – preusmjeriti korisnika na web stranicu koja izgleda kao originalna, ali to nije.

� Napad na XML – iskorištava činjenicu da se odreñeni vanjski podaci mogu implementirati u XML datoteku kroz DTD (eng. Document Type Definition). Neki programi koji koriste XML mogu specificiranjem neke druge datoteke pristupiti neautoriziranim podacima. Ovdje valja napomenuti da SOAP ne koristi DTD.

� Ubacivanje XPath-a – Xpath je jezik koji opisuje lokaciju podataka u XML-u i na odreñeni način je analogan SQL-u. Pa je napad temeljen na ubacivanju XPatha analogan napadu temeljenom na ubacivanju SQL-a. Ovaj napad se može blokirati na način da podaci koji se šalju u XPath sami ne sadrže XPath.

� Opasni SOAP prilozi – kao i e-mail poruke i SOAP poruke mogu sadržavati priloge. Ti prilozi mogu biti opasni ako su veliki i teški za obrañivanje ili još gore ako sadrže datoteke zaražene virusima. Rješenje za ovaj oblik napada je blokiranje priloga u SOAP porukama, filtriranje na temelju MIME tipova ili skeniranjem poruka antivirusnim alatom.

� Napad referencom XML potpisa – temelji se na činjenici da XML potpis uključuje referentni element koji pokazuje na potpisane podatke. Aplikacija koja obrañuje XML mora diferencirati referentni URL. To može predstavljati problem ako su referentni podaci veliki čime se blokira daljnja obrada.

5. ZAKLJU ČAK

Proces implementacije sigurnosnih mehanizama u SOA okolinu predstavlja jedan od temeljnih procesa uspješne implementacije i primjene SOA-e. Kao jedna od 4 temeljne karakteristike SOA-e (interoperabilnost, fleksibilnost i raspoloživost, heterogenost, sigurno upravljanje komponentama) upravo se sigurnost naglašava kao najvažnija. Zbog toga proces uvoñenja i primijene sigurnosnih mehanizama treba provoditi paralelno sa procesom izgradnje SOA-e.


Uvoñenje sustava sigurnosti u servisno-orijentiranu arhitekturu ima iste ciljeve kao i uvoñenje sustava sigurnosti u bilo koji drugi oblik arhitekture informacijskog sustava – osigurati raspoloživost, tajnost i integritet resursa IS-a. No, kako se SOA razlikuje od tradicionalnih arhitektura potrebno je donekle

modificirati sigurnosne mehanizme i načine njihove primjene. Pri tome važnu ulogu imaju specifični sigurnosni standardi i protokoli definirani za upotrebu na programskoj tehnologiji web servisa, ali i primjenjivi i na servisno-orijentirane arhitekture, pri čemu je najvažniji web service security standard.

Literatura:

1 Bertino, E, Martino, L., Paci, F., Squicciarini, A., Security for Web Services and Service-Oriented Architectures, Springer Heidelberg Dordrecht,2010.

2 Biberstein, N., Bose, S., Fiammante, M., Jones, K., Shah, R., Service-oriented Architecture Compass, IBM Press, 2006.

3 Devlin, B., Opening the door to a service oriented architecture, IBM Workplace, Portal and Collaborative Products for SOA, IBM, 2006.

4 Dragičević, D., Kompjuterski kriminalitet i informacijski sustavi, IBS, Zagreb, 2004

5 Gerić, S., Hutinski, Ž., Managing the security of information system, MIPRO 2005, Opatija, 2005., pp. 175-191.

6 Gerić, S., Hutinski, Ž., Service Oriented Security, MIPRO 30th International Convention, Proceedings of Information System Security, Opatija, 2007., pp. 125 - 132.

7 Gerić, S., Hutinski, Ž., Standard Based Service-Oriented Security, Proceedings of the 18th international conference "Information and intelligent systems", Varaždin, Croatia, september 2007, pp. 327 - 335

8 Hafner, M., Breu, M., Security Engineering for Service-Oriented Architectures, Springer-Verlag, Berlin Heidelberg, 2009.

9 Hinton, H., Hondo, M., Hutchinson, B, Security Patterns within a Service-Oriented Architecture, IBM Press, 2005.

10 Kaal, N., Service-oriented Security, <http://techupdate.zdnet.com>, 23.03.2007.

11 Kanneganti, R., Chodavarapu, R., SOA Security, Manning Publications, Grenwich, 2008.

12 Keen, M., et al: Patterns: Extended Enterprise SOA and Web services, <http://www.ibm.com/redbooks>, 15.04.2006.

13 Gossels, J., Mackey, R., Service oriented architecture: Security Challenges, SystemsExperts, 2005, < www.systemexperts.com/tutors/ServiceOrientedArchitectures.pdf>, (15.02.2006.)

14 Lunt, T.F. et al, A Real-Time Instrustion-Detection Expert System (IDES), Computer Science Laboratory, SRI International, Menlo Park, Carolina, 1992.

15 Taylor, K., Austin, T., Cameron, M., Charging for Information Services in SOA, < portal.acm.org/citation.cfm?id=1063532&dl=ACM&coll= ACM&CFID=15151515&CFTOKEN=61618>, 24.02.2006.

16 Trcek, D., Managing Information Systems Security and Privacy, Springer, 2004.

17 Vrček, N., Gerić, S., Kermek, D., The State of Development and Applicability of Service Oriented Architectures, IIS 2006, Proceedings of the 17th international conference "Information and intelligent systems", Varaždin, Croatia, september 2006, pp. 77. - 85.

18 ISO/IEC 17799:2005, Code of practice for information security management, British Standard Institution, London, 2005.

19 NIST – An Introduction to Computer Security: The NIST Handbook, Special Publication 800-12, (08.06.2005.), <http://ts.nist.gov/ts/htdocs/230/235/pubs.htm>,

20 Putting the SOA Infrastructure Together: Lessons from SOA Leaders, SOA Leaders Council Whitepaper, <http://www.soaleaders.org>, 23.03.2006.

21 Security risk management CARNet CERT, <http://www.cert.hr/documents.php?lang=hr&page=5>, (15.05.2004.)

22 Service-oriented architecture expands the vision of web services, <http://www-128.ibm.com/developerworks /library/ws-soaintro.html>, 27.04.2006.

23 Solutions to SOA security, <http:www.developer. com/design/print.php/3607471>, (12.07.2006.)

24 Service-oriented modelling and architectures, <http://www-128.ibm.com/developers/webservices/ library/ws-soa-design-1/>, 24.04.2006.

25 Service-oriented architecture in Pervasive environment, <http://www-128.ibm.com/developers/websphere/library/ techarticles/0409_ammanud/>, 03.04.2006

26 SOA and Web services: New to SOA and web services, <http://www.ibm.com/developerworks/webservices>, 12.03.2006.

27 SOA Security Model, <www.oasis-open.org/committees/download.php/17573/06-04-00008.000.pdf>, 23.04.2007.

28 Web Service Security, OASIS, 2006, < http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf>, 19.03.2007.


Podaci o autorima:

mr. sc. Tomislav Vida čić, email: [email protected] Mr. sc. Tomislav Vidačić magistrirao je na Fakultetu organizacije i informatike u Varaždinu. Ima višegodišnje radno iskustvo vezano uz projektiranje i izgradnju informacijskih sustava te složenih aplikativnih rješenja. Tokom svoje karijere radio je na nizu informatičkih projekata koji su se odnosili na područje kemijske industrije, logistike, grañevine, medicine i bankarstva. Radi u Hrvatskoj poštanskoj banci u sektoru informatike u direkciji aplikativnih rješenja. Živi i radi u Varaždinu. Tomislav Vidacic have master's degree from the Faculty of Organization and Informatics. He has experience related to design and build information systems and complex software solutions. During his career he worked on many IT projects that are related to the field of chemical industry, logistics, construction, medicine and banking. He works in Croatian Postal Bank in sector of informatics.

dr. sc. Sandro Geri ć tel: +385 (0)42 390 857 fax: +385 (0)42 213 413 email: [email protected] Dr. sc. Sandro Gerić doktorirao je na Fakultetu organizacije i informatike u Varaždinu s temom disertacije iz područja servisno-orijentiranih arhitektura. Praktično informatičko obrazovanje nadopunjavao je nizom seminara, radionica o programskim alatima i ostaloj programskoj podršci te studijskih boravaka na fakultetima. Sudjelovao na nizu znanstvenih i stručnih projekata iz područja primjene informacijskih tehnologija. Od 2002. godine radi na Fakultetu organizacije i informatike Varaždin, Sveučilišta u Zagrebu, gdje održava nastavu iz kolegija Sustavi temeljeni na znanju, Upravljanje odnosima s klijentima, Elektroničko i mobilno poslovanje na preddiplomskom i diplomskom studiju. Znanstveno i stručno je usmjeren na projektiranje i razvoj servisno-orijentiranih arhitektura, sigurnost informacijskih sustava te istraživanje učinaka primjene suvremenih informacijskih i komunikacijskih tehnologija. Autor je dvadesetak znanstvenih i stručnih radova. Sandro Gerić have doctorate from the Faculty of Organization and Informatics in Varaždin. His areas of interest are the security of information systems, electronic commerce, web services, service-oriented architecture. Practical IT education complemented by a series of seminars and workshops. He is the author of several scientific papers. He works at the Faculty of Organization and Informatics as a research assistant.

Sveučilište u Zagrebu, Fakultet organizacije i informatike

Pavlinska 2

42000 Varaždin


ALATI ZA RAZVOJ APLIKACIJA BEZ KODIRANJA

CODELESS DEVELOPING TOOLS

Dražen Vukoti ć, Nikola Tankovi ć

SAŽETAK:

Penetracija računalne opreme meñu stanovništvom ubrzano se primiče omjeru jedno računalo po korisniku, s tendencijom rasta na više računala po korisniku. Tom trendu značajno pridonose sveprisutniji "pametni telefoni". Kako bi se iskoristio kreativni i potrošački potencijal ogromnog broja korisnika, pojavljuje se potreba da se omogući jednostavno i intuitivno modeliranje, izrada i isporuka vlastitih ili modifikacija postojećih aplikacija kako za stolna, tako i za mobilna računala. Tu potrebu zadovoljava nova generacija razvojnih alata koji omogućavaju izradu aplikacija bez potrebe za poznavanjem specijalističkih znanja o programiranju. U radu se opisuju i klasificiraju takvi alati i tehnike na kojima su zasnovani.

ABSTRACT:

Computer hardware is gaining its share in human population towards one computer per user, with a tendency to become more than one computer per single user. Smartphone market is significantly contributing that trend. To use the creative and consumer potential of such vast amount of users, there is a need to enable intuitive and easy modeling, developing and deploying new or modifying existing desktop or mobile applications. This need is satisfying by the new generation of development tools, enabling creating applications with ease and no coding. This work will describe and classify such tools and underlying techniques.

1. UVOD

Svjedoci smo prave poplave raznovrsne računalne opreme u svim segmentima stanovništva. Njihova zajednička karakteristika ogleda se u činjenici da omogućava pokretanje različitih korisničkih programa (aplikacija) koji pokrivaju raznolike potrebe krajnjih korisnika. Na taj trend značajno utječu ureñaji koje svrstavamo pod zajednički naziv mobilnog računalstva (engl. mobile computing), a u koje ubrajamo netbook, smartphone i tablet računala. Njihovoj popularnosti pridonose karakteristike koje klasična stolna (engl. desktop) računala nisu imala: mobilnost, dostupnost, intuitivnost korisničkog sučelja korištenjem dodirnog ekrana te ugrañene različite vrste senzora poput kamere, GPS navigacije, raspoznavanja govora ili akcelerometra. Ove karakteristike omogućile su njihovu primjenu u najrazličitijim situacijama i zadacima, od privatnih do poslovnih. Na tržištu se pojavljuje veliki broj aplikacija koje pokušavaju udovoljiti potrebama ogromnog broja potencijalnih korisnika koji se mjeri u stotinama milijuna. Iako je prema istraživanjima (Mobile Entertainment-a ) 80-90% svih preuzetih (engl. downloaded) aplikacija besplatno, a prosječna cijena onih koje se plaćaju je tek 1$, radi se o milijardama preuzimanja i izuzetno značajnom i potentnom tržištu.

Pored ovog trenda, pojavljuje se i trend rasta specijalizirane računalne opreme čijeg postojanja često nismo ni svjesni, a dio su pojave koju nazivamo sveprisutno računarstvo (engl. Ubiquitous Computing). Sveprisutno računarstvo naglašava masovnost računala, geografsku raspodijeljenost, uklopljenost u okolinu, umreženost i funkcionalnost. Za razliku od virtualne stvarnosti koja ljude stavlja u svijet računala u kojem je izazov samo računarstvo, sveprisutno računarstvo stavlja računala u svijet ljudi s namjerom poboljšanja

kvalitete života. (Žagar M., Projekt: „Programsko inženjerstvo u sveprisutnom računarstvu“ ). Rezultat ove pojave je generiranje izuzetno velike količine strukturiranih i nestrukturiranih informacija koje je potrebno na odgovarajući način obraditi i prezentirati korisnicima.

Ova dva trenda dodatno produbljuju jaz izmeñu ponude i potražnje kvalitetnih aplikacija koje će zadovoljiti sve veće potrebe korisnika u segmentima kako privatnog, tako i poslovnog života. Zbog toga se sve više radi na iznalaženju novih načina za kreiranje robustnih, skalirajućih, klijentskih ili web aplikacija u što kraćem vremenu i sa što manjom potrebom za specifičnim, specijalističkim znanjima o programiranju.

U nastavku rada opisuje se postupak izrade aplikacija na klasičan način i uz upotrebu alata za razvoj aplikacija bez kodiranja. Nakon toga se daje klasifikacija takvih alata i pregled njihovih tipičnih predstavnika, a na kraju je iznesen zaključak i predviñanje daljnjeg razvoja na ovom području.

2. KLASIČAN NAČIN RAZVOJA APLIKACIJA

Često se pojam razvoja aplikacija i programiranja poistovjećuju iako se radi o bitno različitim procesima. Pojam razvoja aplikacija (engl. Application Development) obuhvaća sve faze razvoja računalne aplikacije ili informatičkog sustava koji može biti složen od više komplementarnih aplikacija. Postoje različite metodologije koje se bave definiranjem procesa u razvoju aplikacija. Neke od uobičajenih i općeprihvaćenih faza (McConnell ) u razvoju aplikacija su: analiza, dizajn, programiranje, testiranje, implementacija, održavanje i podrška.


Ove faze se mogu provoditi kaskadnim („vodopadni“ - engl. Waterfall) ili spiralno - iterativnim postupkom. Kaskadni postupak podrazumijeva da je svaka prethodna faza u potpunosti dovršena prije nego se može prijeći na sljedeću fazu. Pogreške u ranijim fazama (analiza i dizajn), teško se ispravljaju u kasnijim fazama i povezane su sa značajnim troškovima ili pomicanjem rokova. Meñutim, pogreške ili nesporazumi u fazi analize i dizajna postaju vidljive tek u fazi testiranja što predstavlja velike rizike za prohekt. Stoga su razvijeni spiralno – iterativni postupci koji takoñer prolaze kroz slične faze, ali počinju od manjeg broja funkcionalnosti koje se postupno, u iteracijama nadopunjuju novim funkcionalnostima. Cilj spiralno-iterativnih postupaka je što prije dobiti funkcionalni prototip aplikacije i tako smanjiti rizike razvoja. Spiralno-iterativni postupci imaju svoje različite inačice za što brži razvoj, a koje zajednički prema pojmu koji je uveo James Martin ( ) nazivamo RAD (engl. Rapid Application Development). Neke od najpoznatijih inačica RAD metoda su Agile Software Development, Extreme Programming, Joint Application Design, Lean Software Development i Scrum.

Za razliku od pojma razvoja aplikacija, pojam programiranja predstavlja iako ključan, samo jedan od spomenutih elemenata u procesu razvoja. U nekim slučajevima RAD pristupa, procesi analize, planiranja, dizajna i testiranja implicitno su uključeni u proces programiranja te često dolazi do poistovjećivanja ova dva pojma.

Sam pojam programiranja ili kodiranja označava pisanje programskog koda, odnosno skupa instrukcija računalu koje opisuju način na koji računalo treba izvršiti odreñeni zadatak ( ). Pri tome se koristi odgovarajući programski jezik koji u zavisnosti od stupnja apstrakcije, može pripadati jednoj od 4 generacija programskih jezika: 1GL (binarni kod), 2GL (asemblerski kod), 3GL (viši programski jezici) i 4GL (problemski orijentirani jezici). Nadodavanjem grafičkog sučelja za unos programskih naredbi na jezike treće i četvrte generacije dobije se hibrid kojega proizvoñači iz marketinških razloga neopravdano nazivaju 5GL. Svaka sljedeća generacija programskog jezika donosi značajan napredak u produktivnosti programiranja, a u praksi se najčešće prilikom generiranja izvršnog strojnog koda koristi postupak koji prevodi naredbe višeg programskog jezika u niži, sve do 1GL odnosno do strojnog koda.

Tijekom povijesti razvoja informatike, razvijeno je mnoštvo programskih jezika za razne svrhe, od kojih su samo neki postali općeprihvaćeni. Na stranicama HOPL, the History of Programming Languages ( ) katalogizirano je preko 8500 različitih programskih jezika. Razvijene su i posebne metrike za mjerenje zastupljenosti programskih jezika (npr. langpop.com ), a može se utvrditi da prvih 50 najzastupljenijih jezika koristi preko 95% programera.

Većina aplikacija sastoji se od nekoliko uobičajenih elemenata: ekranskog korisničkog sučelja (engl. User interface), programske logike, sustava za pohranu podataka (DBMS) i sustava za izvješćivanje (engl. Reporting). U skladu sa time, postoje i posebni programski alati namijenjeni izradi, ispravljanju i testiranju navedenih elemenata, a ponekad su svi zajedno objedinjeni u jedan integrirani razvojni alat - IDE (engl. Integrated Development Environment). Ovakvi integrirani razvojni alati ili razvojna okruženja značajno unaprjeñuju i olakšavaju proces programiranja koji po svojoj prirodi zahtijeva popriličnu količinu specifičnog, specijalističkog znanja o korištenom programskom jeziku kao i o uporabi samog razvojnog alata.

Iako postoje alati koji podupiru i ostale faze u razvoju aplikacija, npr. alati za voñenje i upravljanje projektima, alati za planiranje, alati za testiranje, implementaciju i korisničku podršku, sam proces programiranja je jedini proces koji se može u velikoj mjeri, a ponekad i u potpunosti automatizirati. Moderna IDE okruženja sadrže mnoštvo vizualnih pomagala koja olakšavaju kreiranje ekranskog korisničkog sučelja, modeliranje i povezivanje sa bazom podataka ili izradu kompleksnih izvješća. Meñutim, svaka zahtjevnija programska logika koja čini okosnicu aplikacije, mora se napisati u odabranom programskom jeziku. U tom dijelu nastupaju alati za razvoj aplikacija bez programiranja koji su na tragu tome da se postupak programiranja maksimalno olakša, a u nekim slučajevima i ukine.

3. RAZVOJ APLIKACIJA BEZ POTREBE ZA KODIRANJEM

Prilikom razvoja aplikacija redovito se pojavljuje problem nerazumijevanja izmeñu osoba koje posjeduju znanje o problemskoj (poslovnoj) domeni za koju se aplikacija izrañuje, osoba zaduženih za analizu predmetne domene i dizajn te osoba zaduženih za izradu aplikacije, odnosno programiranje. Što je veće preklapanje znanja izmeñu sudionika u razvoju, to je veća vjerojatnost da će realizirana aplikacija bolje zadovoljavati korisnikove potrebe. U klasičnom pristupu, taj se problem rješava korištenjem odreñene metodologije (kaskadne, spiralne, iterativne) koje, svaka na svoj način, smanjuju rizik nerazumijevanja. U pristupu razvoja aplikacija bez kodiranja, pokušava se smanjiti ili dokinuti potreba za programerskim ili analitičarskim znanjem i na taj način eliminirati nerazumijevanje, ubrzati razvojni ciklus i olakšati naknadne dorade..

Nakon provedenog istraživanja na gotovo 30 razvojnih alata različitih proizvoñača, utvrñeno je da se alati za razvoj aplikacija bez programiranja mogu svrstati u četiri osnovne kategorije: � Alati zasnovani na principima vizualnog

programiranja � Alati zasnovani na modeliranju � Alati zasnovani na definiranju domenskih ontologija � Alati zasnovani na kreiranju novih aplikacija

metodom komponiranja elemenata postojećih aplikacija

U nastavku se detaljnije razrañuje svaka od navedenih kategorija.

3.1 Alati za vizualno programiranje

U alate za vizualno programiranje ubrajaju se oni alati koji omogućavaju kreiranje programske logike pomoću slaganja i povezivanja vizualnih elemenata i njihovog prostornog rasporeda umjesto pisanjem tekstualnih naredbi programskog jezika ( ). Pri tome se i dalje koriste semantička i sintaksna pravila kao i kod tekstualnih programskih jezika, ali su elementi jezika u ovom slučaju prikazani grafičkim simbolima i piktogramima. Iako govorimo o alatima za razvoj aplikacija bez programiranja, potrebno je naglasiti da je kod ovih alata ipak potrebno poznavati principe programiranja.

Na tržištu postoji veliki broj alata zasnovanih na 3GL-u ili 4GL-u sa vrlo razvijenim i moćnim dodacima za grafičko ureñivanje elemenata korisničkog sučelja na principima povuci-pusti (engl. drag and drop) i WYSIWYG (engl. What You See Is What You Get) ureñivača sučelja. Takve alate ne bi trebalo razmatrati u kategoriji „pravih“ alata za vizualno programiranje jer je njihova baza i dalje


klasični programski jezik nadopunjen sa elementima vizualnog programiranja samo u segmentu korisničkog sučelja dok se programska logika koja stoji iza sučelja i dalje definira korištenjem tekstualnih programskih naredbi 3GL programskog jezika. Meñutim, zbog kompletnosti prikaza i njihovom značajnom doprinosu na tom području, uvršteni su u posebnu kategoriju.

Kod „pravih“ alata za vizualno programiranje nema potrebe za utipkavanjem programskih naredbi ili drugog teksta, osim u slučajevima kada je radi preglednosti potrebno imenovati elemente programa (varijable, labele, blokove i slično). Provedeno istraživanje je pokazalo da se alati za vizualno programiranje mogu svrstati u tri glavne kategorije: 1. ureñenje ekranskih formi i izvješća što je ranije već

spomenuto, 2. korištenje dijagrama koji opisuju tijek podataka ili

odvijanja procesa, 3. grafička reprezentacija programskih logike kao što

su pridruživanje, uvjetno grananje ili ponavljanje. Ova kategorija postaje sve popularnija, a trenutačno se najviše koristi kod alata namijenjenih za učenje principa programiranja.

Slika 1 prikazuje izgled tipičnog predstavnika alata koji ima mogućnost grafičkog ureñivanja ekranskih formi.

Slika 2 prikazuje grafičku notaciju poslovnog modela alata koji koristi dijagram toka za vizualno programiranje.

Slika 3 prikazuje alat koji omogućava slaganje programske logike potpuno vizualnim postupkom.

Budući trend razvoja trebao bi ujediniti osobine sve tri kategorije na način da se u jednom alatu mogu iskoristiti osobine one kategorije koja najbolje odgovara pojedinom poslu pri razvoju nove aplikacije.. Na primjer, za dizajn ekranskih formi ili izvješća najpraktičnija je prva spomenuta kategorija koju prikazuje Slika 1. Za definiranje procesa na višoj razini idealan je dijagram toka (engl. dataflow) iz druge kategorije koju prikazuje Slika 2, a za realizaciju svakog pojedinog procesa može se koristiti pristup treće kategorije koji prikazuje Slika 3.

Na opisani način još više bi do izražaja došla osnovna prednost vizualnog programskog jezika koja zahtijeva relativno malo inicijalnog znanja kako bi ga se moglo početi efikasno koristiti. To je zbog toga što su svi elementi programskog jezika, njegove semantike i sintakse vizualno reprezentirani te se korištenjem

Slika 1: Microsoft Visual Studio - tipičan predstavnik alata koji omogućava grafičko

ureñivanje ekranskih formi

Slika 2: Tersus koji koristi dijagrame toka za vizualno programiranje


kontekstne ovisnosti dinamički sužava izbor elemenata koji se mogu upotrijebiti i na taj način korisnika se vodi kroz postupak programiranja.

Svi alati iz ove skupine su u stvari programski alati, a od klasičnih alata za programiranje razlikuju se samo po tome da se programiranje ne provodi utipkavanjem tekstualnih naredbi programskog jezika već slaganjem grafičkih elemenata. Za korištenje ovih alata potrebno je odreñeno poznavanje principa programiranja i arhitekture programske podrške.

3.2 Alati za modeliranje

Sljedeća skupina alata naglasak stavlja na fazu analize i dizajna, odnosno modeliranje programskog rješenja i pokušava u cijelosti automatizirati proces programiranja i na taj način čim više smanjiti potrebu za njegovim korištenjem u procesu razvoja aplikacija. Ovi alati sadrže više ili manje kompletnije generatore programskog koda za različite 3GL programske jezike (Java, C++). Neki od alata omogućavaju ručnu promjenu izgeneriranog koda koja se može postupkom reverznog inženjeringa vratiti u početni model.

Alati iz ove skupine se mogu dodatno podijeliti u generatore i interpretere. Generatori su oni alati čije rezultat je programski kod koji se prije korištenja mora u cijelosti prevesti (engl. compile), što rezultira vrlo dobrim performansama aplikacije prilikom izvršavanja, ali s druge strane nameću i neka ograničenja. Interpreteri najčešće produciraju programski kod na zahtjev što im omogućava izuzetnu fleksibilnost dok su im performanse nešto lošije.

Alati iz ove skupine baziraju se na nekoj od prihvaćenih notacija za analizu, modeliranje i dizajn sustava. Najpoznatiji meñu njima su UML, BPMN i OPM.

UML (Unified Modeling Language) je standardizirani univerzalni jezik za modeliranje objektno orijentiranih aplikacija (Blaha M., Premerlani W. ). Njegova bogata semantika omogućava kreiranje različitih pogleda na isti domenski problem. Meñutim, upravo zbog svoje

kompleksnosti koja se tijekom vremena sve više povećavala, postao je nepraktičan za korištenje od strane neinformatičkih korisnika. Zbog toga sve teže može ispuniti svoju osnovnu zamisao kao sredstvo nedvosmislene komunikacije izmeñu različitih sudionika u procesu razvoja aplikacije. Slika 4 prikazuje mnoštvo različitih tipova UML dijagrama koji omogućuju modeliranje iz više aspekata sustava, no znatno pridonose složenosti samog modeliranja.

BPMN (engl. Business Process Modeling Notation) predstavlja grafičku notaciju za prikaz modela poslovnih procesa. Vrlo je slična dijagramima aktivnosti UML-a, a zbog svoje jednostavnosti bolje od UML-a ispunjava zadaću da na jedinstven i intuitivan način omogući opisivanje poslovnih procesa. Ali, upravo zbog svoje jednostavnosti, alati koji osiguravaju generiranje aplikacija temeljenih na BPMN-u nemaju onu razinu detaljnosti koja se može postići UML opisom. Slika 5 prikazuje jednostavan proces opisan BPMN notacijom.

Slika 3: Scratch – potpuno grafička reprezentacija programske logike

Slika 4: Bogatsvo, ali i kompleksnost dijagrama UML-a


OPM (engl. Object-Process Methodology) je pokušaj da se ostvari metodologija koja će imati jednostavnost prikaza poput BPMN-a, ali i dovoljnu razinu detalja poput UML-a. Dok UML podržava različite poglede na isti sustav, OPM omogućava putem jedne vrste grafičke reprezentacije prikazati strukturalne, funkcionalne, procesne i arhitekturalne aspekte kroz jedinstven grafički model (Renhartz-Berger, Dori ). Na taj način omogućena je izrada refleksivnog, balansiranog, sveobuhvatnog modela iz kojega je puno jednostavnije izgenerirati, a kasnije i održavati programski kod. Zbog svoje kompaktne prirode, OPM ima jedinstveno svojstvo da se model može izražavati kako grafičkim (OPD – Object Process Diagram), tako i tekstualnim prikazom (OPL – Object Process Language). OPL je kontrolirani jezik sličan govornom jeziku te ga je vrlo lako čitati i pisati, a potpuno je svejedno da li se model unosi kroz OPD ili OPL. Slika 6 prikazuje poslovni proces u grañevinarstvu u OPG i OPL notaciji (OPL rečenica glasi: „House, which is physical, consists of many Walls, Foundations and Roof“).

3.3 Alati za definiranje ontologija

U posebnu skupinu alata za razvoj aplikacija bez programiranja spadaju alati koji se temelje na izradi ontološke definicije problemske domene. Ontologija u informatičkoj terminologiji predstavlja model znanja koje opisuje promatrano područje (domenu) kao skup koncepata i veza meñu njima. Mogu se definirati dvije temeljne grupe ontologija: područna (engl. domain-specific ontology) i temeljna (engl. foundation ili upper ontology). Područna ontologija opisuje koncepte iz različitih specifičnih domena, a temeljna ontologija opisuje zajedničke koncepte.

Alati za razvoj aplikacija temeljeni na definiranju ontologija omogućavaju brzi razvoj aplikacije koja će omogućiti definiciju entiteta i njihovih veza sa svojim deklarativnim pravilima (klase, atributi i veze) te korištenje automatski prilagoñenih ekranskih formi za unos ontologijom definiranih podataka (instanci). Meñutim, zahtjevniji procesi mogu se realizirati tek korištenjem ekstenzija napisanih u klasičnom programskom jeziku. Slika 7 prikazuje korisničko sučelje jednog od najpopularnijih alata za definiranje ontologija.

Slika 6: Prikaz OPM modela poslovnog procesa (OPCAT)

Slika 5: Prikaz jednostavnog procesa u BPMN notaciji


3.4 Alati za komponiranje

Alati za komponiranje zasnovani su na potpuno drugačijem pristupu razvoju aplikacija. Oni se baziraju na dvije ključne činjenice:

1 Svaka aplikacija namijenjena korisniku, mora sve svoje funkcionalnosti eksponirati putem ekranskog korisničkog sučelja bez obzira radi li se o grafičkom ili komandno-linijskom sučelju.

2 Postoji (ili ga profesionalci mogu izraditi) dovoljan broj elementarnih aplikacija koje rješavaju odreñeni zadatak koji je potreban korisniku.

Ukoliko su ispunjena oba gornja preduvjeta, pretpostavka je da si korisnik može složiti (komponirati) po volji kompleksnu aplikaciju koristeći gotove aplikacije kao grañevne blokove. Ovi alati rade tako da ih korisnik u postupku inicijalizacije „nauči“ kako treba izvesti odreñenu operaciju koristeći jednu ili više aplikacija. Nakon toga, alat za komponiranje ponavlja „naučeni“ postupak sa zadanim parametrima na isti način kao da je

aplikaciju korisnik upotrebljavao ručno. Neki od ovih alata imaju mogućnost primjenjivati i kompleksnu logiku koja će osigurati uvjetno grananje ili ponavljanje. Slika 8 prikazuje Geppeto Program Spreadsheet u kojem je moguće mijenjati redoslijed ili definirati paralelne aktivnosti komponirane aplikacije.

4. ANALIZA ALATA ZA IZRADU APLIKACIJA BEZ KODIRANJA KORIŠTENIH U ISTRAŽIVANJU

U ovom poglavlju dan je tablični prikaz analiziranih alata koji u manjoj ili većoj mjeri odgovaraju specifikaciji alata za razvoj aplikacija bez programiranja. Alati su svrstani u prethodno definirane i opisane kategorije i dan je njihov komercijalni naziv, proizvoñač, web adresa i originalni proizvoñački opis alata.

Slika 7: Protege Frame Editor

Slika 8: Geppeto Program Spreadsheet


4.1 Alati za vizualno programiranje

Naziv Proizvo ñač URL Proizvo ñački opis

Waw

emak

er

VM

war

e

http

://w

ww

. w

avem

aker

.com

/ WaveMaker is the only open and easy-to-use development platform for web and cloud applications. With WaveMaker's visual, drag and drop tools, any developer can start building enterprise Java applications with minimal training. WaveMaker creates standard Java applications, boosting developer productivity and quality without compromising flexibility.WaveMaker applications are cloud-ready and include built-in support for multi-tenancy and elastic scaling.

Cas

pio

Cas

pio

Inc.

http

://w

ww

. ca

spio

.com

/

The Caspio Bridge online database platform is a proven productivity tool for business and IT professionals to create web forms, database searches and web applications fast and without programming. Cloud computing has never been easier or more cost-effective.

Caspio provides everything you need to create and deploy your own web applications in a secure web-based account.

Iceb

erg

Iceb

erg

Inc.

http

://w

ww

.ge

ticeb

erg.

com

/ Iceberg is a complete workflow software platform driven by BPM on .NET. Drag and drop to create your database, forms and layout. Visually design workflow and process to drive it. Customize the layout to your exact design

For

ce.c

om

Sal

esfo

rce.

com

In

c.

http

://w

ww

. sa

lesf

orce

.com

The leading cloud platform for business apps.

Every business needs apps: HR apps, inventory apps, iPhone, iPad, Android, and BlackBerry apps. Now you can use the Force.com platform to build all of your apps—and websites—quickly and easily. 100% cloud—requires no hardware or software. Mobile—run your apps on any platform or device. Social—add collaboration features to every app.

Om

nibu

ilder

Om

niS

pher

e in

form

atio

n sy

stem

s co

rp

http

://w

ww

. om

nibu

ilder

.com

OmniBuilder is a tool which manages the full lifecycle of the application. OmniBuilder generates complete, fully functional applications in a variety of technologies. It captures the full business model, including business rules, requirements and Use Cases. Business templates can be imported to jump-start the application.Real-time prototypes are driven from the business model in an iterative approach to application building. The fully functional prototypes present and manage objects, relationships, triggers, business rules, master-detail screens, windows, menus, security, etc.

Iron

spee

d

Iron

Spe

ed, I

nc

http

://w

ww

. iro

nspe

ed.c

om Simply point to an existing database and let Iron Speed

Designer create a visually stunning, feature-rich Web 2.0 application that is easy to customize and ready to deploy. In just minutes you’ll get a complete .NET Web application without programming. Applications are a snap to customize using our simple layout editor, wizards and toolbox. No knowledge of HTML or .NET is required!

Ter

sus

Ter

sus

Sof

twar

e Lt

d.

http

://w

ww

. te

rsus

.com

/

100% Visual - No Coding, No Scripting. Tersus is a Visual Programming Platform for creating rich web and mobile applications. Simply draw flow diagrams and Tersus will bring your application to life.Tersus is open source.

Met

aCA

SE

Met

aCas

e In

c.

http

://w

ww

. m

etac

ase.

com

/

MetaEdit+ enables companies to radically improve development productivity and quality by generating full code directly from models. First you design the modeling language with MetaEdit+ Workbench and then other developers model with the language in MetaEdit+ Modeler.


App

inve

ntor

Goo

gle

http

://

appi

nven

tor.

go

ogle

labs

.com

To use App Inventor, you do not need to be a professional developer. This is because instead of writing code, you visually design the way the app looks and use blocks to specify the app's behavior. The App Inventor team has created blocks for just about everything you can do with an Android phone, as well as blocks for doing "programming-like" stuff-- blocks to store information, blocks for repeating actions, and blocks to perform actions under certain conditions. There are even blocks to talk to services like Twitter.

Lim

nor

Long

flow

http

://w

ww

. lim

nor.

com

/

Limonor Codeless Programming System is a unique solution that allows users to create their own fully functional applications without writing a single line of code! This development platform uses ready components called Performers and enables the developer to specify their properties, define reactions to system events and link them with other components. The whole process is akin to building a Lego house, but in this case, you will create applications that can actually be used in your daily work!

Scr

atch

Scr

atch

je r

azvi

jen

u Li

felo

ng

Kin

derg

arte

n gr

oupi

na

MIT

Med

ia

Labo

rato

riju,

uz

finan

cijs

ku

podr

šku

Nat

iona

l Sci

ence

F

ound

atio

na, M

icro

softa

, Int

el

Fou

ndat

iona

, Mac

Art

hur

Fou

ndat

iona

, Goo

glea

, Iom

ege

i M

IT M

edia

Lab

istr

aživ

ačko

g ko

nzor

cija

.

http

://sc

ratc

h.m

it.ed

u/

Scratch je programski jezik koji vam na jednostavan i pristupačan način omogućava stvaranje vlastititih interaktivnih priča, animacija, igara, glazbe i umjetnosti, a koje kasnije možete oglasiti i podijeliti na webu s drugima. Dok djeca stvaraju i dijele Scratch projekte, oni istodobno usvajaju i bitne matematičke i računarske koncepte, a istovremeno i uče razmišljati na kreativniji i sistematičniji način, često uz poticajan timski rad.

Alic

e

The

Alic

e P

roje

ct is

a

mul

ti-un

iver

sity

initi

ativ

e,

and

the

Alic

e T

eam

is a

co

llabo

ratio

n am

ong

facu

lty, s

taff

and

stud

ents

.

http

://w

ww

.alic

e.or

g/

Alice is designed solely to teach programming theory without the complex semantics of production languages such as C++. Users can program with arrow keys and other controls. Alice can be used for 3D user interfaces.Alice is conjoined with its IDE. There is no syntax to remember. However, it supports the full object-oriented, event driven model of programming.Alice is designed to appeal to specific subpopulations not normally exposed to computer programming, such as female students of middle school age, by encouraging storytelling, unlike most other programming languages which are designed for computation.

4.2 Alati za modeliranje


OP

CA

T s

tudi

o

Opc

at

http

://w

ww

.opc

at.c

om

OPCAT Studio incorporates the following features: Single model that enables clear and concise expression of hardware, software,humans and regulation. Complexity management by refinement/abstraction mechanisms that include in-zooming/out-zooming, unfolding/folding and suppression/expression. Animated system and product simulation for design-level conceptual debugging and effective early error avoidance or trapping, resulting in huge tangible time and money savings down the road. Automated documentation, code generation and automatic document referencing mechanism. Import and validation functions for system evolution that follows configurable organizational development policies.

Rat

iona

l R

ose

IBM

http

://w

ww

-01.

ib

m.c

om/s

oftw

are/

ratio

nal/ IBM® Rational Rose® Data Modeler offers a sophisticated

visual modeling environment for database application development. Accelerate your processes by connecting the database designers to the rest of the development team through a common tool and the Unified Modeling Language™ (UML™) v1.4


Rha

psod

y

Ilogi

x

http

://ds

p-fp

ga.c

om/

i-log

ix-r

haps

ody

Rhapsody is the industry’s leading Model-Driven Development (MDD) environment for systems, software, and test. A seamless environment for Systems and Software Development with complete design portability. Flexible design environments supporting SysML, UML 2.0, DoDAF, and Domain Specific Languages. Advance auto documentation generation. Design for Testability which includes: Model simulation Requirements Based testing Auto test generation Embedded target model level debugging. Complete application generation for C, C++, Java, Ada Rules-based code generation COM/CORBA generation Code visualization and reverse engineering

Poi

ntD

rago

n

Gra

phLo

gic

http

://w

ww

. po

intd

rago

n.co

m/ Pointdragon™ is a web-based environment for developing and

running internet applications. Pointdragon™ is designed for both the casual end-user and the professional software developer. Anyone with an idea and access to the web can build, use, share, and sell software applications.

Welcome to the power and ease of pointclick – dragdrop visual software development.

4.3 Alati za definiranje ontologija


Pro

tégé

Sta

nfor

d C

ente

r fo

r B

iom

edic

al In

form

atic

s R

esea

rch

at th

e S

tanf

ord

Uni

vers

ity S

choo

l of

Med

icin

e.

http

://pr

oteg

e.st

anfo

rd.e

du Protégé is a free, open-source platform that provides a

growing user community with a suite of tools to construct domain models and knowledge-based applications with ontologies. At its core, Protégé implements a rich set of knowledge-modeling structures and actions that support the creation, visualization, and manipulation of ontologies in various representation formats. Protégé can be customized to provide domain-friendly support for creating knowledge models and entering data. Further, Protégé can be extended by way of a plug-in architecture and a Java-based Application Programming Interface (API) for building knowledge-based tools and applications.

4.4 Alati za komponiranje

Naziv Proizvo ñač URL Opis

Gep

peto

Pro

jekt

FE

R-a

sp

onzo

riran

od

str

ane

Goo

gle-

a

http

://w

ww

. ge

ppet

o.fe

r.hr

Geppeto (Gadget Parallel Programming Tool) is a consumer-level programming environment designed for gadget composition. In this case, the building blocks used to create an application are gadgets. The Geppeto environment itself is a gadget designed to run on the iGoogle page.

Sik

uli

Ope

n-so

urce

res

earc

h pr

ojec

t dev

elop

ed a

t U

ser

Inte

rfac

e D

esig

n G

roup

,MIT

Com

pute

r S

cien

ce a

nd A

rtifi

cial

In

telli

genc

e La

bora

tory

(C

SA

IL)

and

supp

orte

d in

pa

rt b

y th

e N

atio

nal

Sci

ence

Fou

ndat

ion

http

://

siku

li.or

g/ Sikuli is a visual technology to automate and test graphical

user interfaces (GUI) using images (screenshots). Sikuli includes Sikuli Script, a visual scripting API for Jython, and Sikuli IDE, an integrated development environment for writing visual scripts with screenshots easily. Sikuli Script automates anything you see on the screen without internal API's support.

5. ZAKLJU ČAK

Uočena su tri dugoročna trenda u IT sektoru: sve veća količina računalne opreme, sve veći broj njihovih korisnika i sve veća količina generiranih podataka. Ti trendovi dovode do sve veće potrebe za raznovrsnim aplikacijama koje će moći na odgovarajući način pohraniti, obraditi i prezentirati generirane podatke širokoj bazi korisnika na različitim računalnim platformama. Klasičan način razvoja aplikacija programiranjem, teško može udovoljiti ovim potrebama zbog nedostatka stručnog programerskog kadra, dugog

razvojnog ciklusa i složenog procesa razvoja i održavanja. Kao odgovor na ove probleme, sve više se razvijaju alati za razvoj aplikacija bez programiranja koji imaju potencijal značajno pojednostavniti i skratiti razvojni proces i omogućiti izradu korisničkih aplikacija svakom zainteresiranom korisniku bez potrebe za specifičnim specijalističkim znanjima iz programiranja.

Napravljeno je istraživanje tržišta alata i metodologija za razvoj aplikacija bez programiranja i temeljem tog istraživanja kreirana je jedinstvena podjela na sljedeće kategorije: 1 Alati za vizualno ili grafičko programiranje


2 Alati za modeliranje 3 Alati za definiranje ontologija 4 Alati za komponiranje

Nakon provedene analize trendova na ovom području i tipičnih predstavnika svake pojedine kategorije, može se zaključiti kako je trend razvoja aplikacija bez potrebe za programiranjem sve izraženiji i kako se u budućnosti očekuje uzlet novih ili značajne nadogradnje postojećih alata, koji će postati općeprihvaćeni od velike baze korisnika. Takvi alati trebali bi biti zasnovani na najboljim praksama danas popularnih, zrelih razvojnih alata u području kreiranja ekranskog korisničkog sučelja i

generiranja izvješća, zatim grafičkog modeliranja i vizualnog programiranja. Veliki doprinos očekuje se od skupine alata zasnovanih na definiranju ontologija kao i na principima komponiranja. Poseban naglasak alati će morati staviti na iskorištavanje senzora ugrañenih u mobilne, komunikacijske i specijalizirane ureñaje te dodirnog ekrana i upravljanu govorom ili gestama. Osim toga, aplikacije će morati biti skalabilne, multiplatformne i podržavati tzv. multitenant rad. Oni alati koji na jednostavan i intuitivan način budu ponudili više ovdje navedenih kriterija, imaju veliku šansu da postanu standard na ovom području.

Literatura:

1 Mobile Entertainment, 157 App Stats you should know about, http://www.mobile-ent.biz/news/read/157-app-stats-you-should-know-about, pregledano 23.05.2011.

2 Žagar M. Projekt: Programsko inženjerstvo u sveprisutnom računarstvu Ministarstva znanosti, obrazovanja i športa Republike Hrvatske

3 McConnell, Steve. "7: Lifecycle Planning". Rapid Development. Redmond, Washington: Microsoft Press. pp. 140.

4 Martin J., RAD, Rapid Application Development, MacMillan Publishing Co., New York, 1990.

5 Maćešić N., Leksikon računarskih pojmova, VPA Zagreb, 1986.

6 HOPL, the History of Programming Languages, http://hopl.murdoch.edu.au/, pregledano 23.05.2011.

7 langpop.com, Programming Language Popularity, http://langpop.com/, pregledano 23.05.2011.

8 Wesley M. Johnston, J. R. Paul Hanna, and Richard J. Millar, Advances in Dataflow Programming Languages, University of Ulster

9 Blaha M., Premerlani W., Object-Oriented Modeling and Design for Database Applications, 1998 by Prentice-Hall Inc. ISBN 0-13-123829-9

10 Object Management Group/Business Process Management Initiative, dostupno na http://www.bpmn.org/, pregledano 24.05.2011.

11 Reinhartz-Berger I., Dori D., Object-Process Methodology (OPM) vs. UML: A Code Generation Perspective

Podaci o autorima:

Dražen Vukoti ć e-mail: [email protected] Dražen Vukotić diplomirao je na ETF-u Zagreb 1990. godine. U preko 20 godina profesionalnog rada u informatici, radio je na poslovima od sistem analitičara do direktora za tehnologiju i razvoj. Rukovodio je dizajnom, izradom i implementacijom složenih, integralnih informacijskih sustava iz domene proizvodnje, javnog zdravstva, osiguranja, turizma i prodaje. Profesionalna preokupacija su mu izrada univerzalnih, multiplatformskih, multidomenskih računalnih programa za razvoj aplikacija bez kodiranja. Osnivač je i suvlasnik IT tvrtke Superius. Trenutačno pohaña poslijediplomski doktorski studij na FER-u Zagreb. Dražen Vukotić graduated in 1990. at ETF Zagreb. In over 20 years of professional experience in IT, he worked on the positions from the System Analyst to the R&D director. He managed design, development and implementation of complex, integrated information systems in manufacturing, public health, insurance, tourism and commerce domain. His professional focus is creating universal, multiplatform, multidomain software for codeless developing. He is founder and co owner of Superius. Currently, he is a PhD student at the FER Zagreb.

Nikola Tankovi ć e-mail: [email protected] Nikola Tanković je stekao diplomu računarstva na Fakultetu elektrotehnike i računarstva u Zagrebu. Trenutno stječe titulu doktora znanosti na istom fakultetu radeći na području modeliranja aplikacija. Takoñer drži poziciju voditelja razvojnog tima u tvrtci Superius iz Pule. Njegova područja interesa uključuju izvodive aplikacijske modele, graf baze podataka i dizajn web aplikacija. Nikola Tanković graduated with Master's Degree in Computer Science at Faculty of Electrical Engineering and Computing in Zagreb. He is currently a PhD student at same university studying in the field of application modelling. He also holds a Development Team Leader position at Superius Ltd in Pula, Croatia. His fields of interest include executable application models, graph databases and web application design. Superius d.o.o. Ćirilometodske družbe 1 52100 Pula


AGILNO UPRAVLJANJE I OPTIMIZACIJA POSLOVNIH PROCESA

AGILE BUSINESS PROCESS MANAGEMENT AND OPTIMIZATION

mr.sc. Darije Ramljak

SAŽETAK:

Upravljanje poslovnim procesima (BPM) i servisno orijentirana arhitektura (SOA) već nekoliko godina jedan su od glavnih načina efikasnog i tješnjeg povezivanja poslovanja i IT-a. Korištenjem njihovih principa moguće je izgraditi prilagodljive informacijske sustave koji na taj način omogućuju kvalitetniju prilagodljivost poslovanja prema promjenama u njihovom okruženju.

Klasični principi BPM razvoja znali su biti karakterizirani kao previše rigidni i komplicirani te stoga primjenjivi prvenstveno pri implementaciji kompleksnih informacijskih sustava. U posljednje vrijeme, IBM-ove novine koje se uvode u sferi upravljanja i optimizacije poslovnih procesa daju za pravo govoriti o platformi za agilan razvoj BPM sustava i kontinuiranoj optimizaciji poslovnih procesa i poslovnih performansi.

U ovom radu bit će detaljno prikazane IBM-ove metode i tehnike agilnog upravljanja i optimizaciju poslovnih procesa koje počivaju na naprednim BPM i SOA principima.

ABSTRACT:

Current and standard approached to Business Process Oriented information systems development have not been able to completely bridge the Business-IT gap. This paper will present advanced concepts and mechanisms for agile Business Process Management and Optimization, which are specially focusing on the improvements of business and IT collaboration.

1. UVOD

Upravljanje poslovnim procesima (BPM) i servisno orijentirana arhitektura (SOA) već nekoliko godina jedan su od glavnih načina efikasnog i tješnjeg povezivanja poslovanja i IT-a. Korištenjem njihovih principa moguće je izgraditi prilagodljive informacijske sustave koji na taj način omogućuju kvalitetniju prilagodljivost poslovanja prema promjenama u njihovom okruženju. Klasični principi BPM razvoja znali su biti karakterizirani kao previše rigidni i komplicirani te stoga primjenjivi prvenstveno pri implementaciji kompleksnih informacijskih sustava. U posljednje vrijeme, IBM-ove novine koje se uvode u sferi upravljanja i optimizacije poslovnih procesa daju za pravo govoriti o platformi za agilan razvoj BPM sustava i kontinuiranoj optimizaciji poslovnih procesa i poslovnih performansi.

U ovom radu bit će detaljno prikazane IBM-ove metode i tehnike agilnog upravljanja i optimizaciju poslovnih procesa koje počivaju na naprednim BPM i SOA principima.

2. ZAHTJEVI PRI OPTIMIZACIJI POSLOVNIH PROCESA

Prema rezultatima studije koju je IBM-ov Institut za poslovnu vrijednost proveo 2010.g. postoji nekoliko atributa kojima izvršni direktori raznih kompanija karakteriziraju novo ekonomsko okruženje: � Veća volatilnost - sve je više rizika te ciklusi

promjene postaju sve brži i jači � Više nesigurnosti - smanjena je mogućnost

kvalitetne predikcije kretanja tržišta

� Veća kompleksnost - cijeli ekosustav postaje integriran i povezan

� Strukturalna različitost - povećana je potreba za održivim promjenama

Ono što je zajedničko svim karakteristikama novog ekonomskog okruženja je očekivanje fundamentalno transformirajućih promjena, tj. promjena koje će mijenjati samu strukturu i bit poslovanja. U takvom okruženju, pred metode i tehnike BPM razvoja postavljaju se novi zahtjevi koje na klasičan i standardan način nije moguće u potpunosti odgovoriti. Očekuju se kvantitativna i kvalitativna poboljšanja poslovnih procesa dok se u isto vrijeme njihova kompleksnost povećava.

Kada govorimo o optimizaciji poslovnih performansi i poslovnih procesa, sljedeće karakteristike postavljaju novi kontekst u kojem se napredne i agilne BPM tehnike moraju operacionalizirati: � Poslovanje kontrolira svoje procese i informacije

fokusiranjem na poslovne rezultate � Optimizacija se fokusira na viziju organizacije koja

će se promijeniti pod utjecajem sustava i kako će transformirana organizacija koristiti sustav

� Prepoznavanje dinamičke prirode poslovnog okruženja i potrebe za sklapanjem poslovnih elemenata, pravila, dogañaja, sadržaja, socijalnih interakcija i analitika

� Pretpostavljanje mogućnosti podršku procesnim predlošcima definiranim od strane poslovnih korisnika bez reinženjeringa poslovnih procesa unaprijed

� Omogućavanje prilagodbe procesnih fragmenata kako bi sustav dao fleksibilnost i mogućnost rada izvan granica preprogramiranog procesa


3. STANDARDNI NAČINI RAZVOJA BPM SUSTAVA

Pri upravljanju i optimizaciji poslovnih procesa na standardni način koristi se tehnika definiranja (modeliranja) poslovne logike kao tijeka aktivnosti (eng. activity flow) 2. Alati za modeliranje poslovnom analitičaru nude razne mogućnosti za simulacije izvoñenja procesa (Slika 1.), mjerenje očekivanih performansi te kreiranja korisničkog sučelja za polu-automatizirane korake poslovnog procesa gdje se očekuje intervencija korisnika (tzv. human tasks).

Nakon što su modelirani željeni budući procesi oni se transformiraju u tehnički izvršni oblik (npr. BPEL) i kao takve ih preuzimaju „integracijski razvojni eksperti“ koji dodaju tehničke detalje procesima, podprocesima i aktivnostima koje su potrebne da bi se ti procesi mogli pokrenuti u izvršnoj IT okolini. Kao dio tehničkih detalja dodaju se i odreñeni parametri kroz koje se kasnije mogu mjeriti performanse procesa, a koje su vezane uz ključne indikatore poslovanja koje je postavio i definirao poslovni analitičar.

Za veliku većinu poslovnih procesa, ovakav konvencionalni BPM životni ciklus je dovoljan i daje dobar rezultate. Meñutim, uzimajući u obzir sve

kompleksnije zahtjeve koji se postavljaju pred analitički/razvojni tim koji implementira BPM sustav, postaje očito da standardni način razvoja predstavlja usko grlo te da je cjelokupan ciklus od nove poslovne promjene do implementacije i testiranja postao predug 3.

4. KONCEPTI AGILNOG UPRAVLJANJA I OPTIMIZACIJE POSLOVNIH PROCESA

U konceptu agilnog upravljanja i optimizacije poslovnih procesa, prvi korak počinje kreiranjem Mapa otkrivanja procesa (eng. Process Discovery Map). Agilnost i rapidan pristup u izgradnji procesnih mapa ogleda se u činjenici da se fokusira samo na tzv. Happy path scenarij, definiranje glavnih faza procesa (eng. Milestones) i aktivnosti koje se u tim fazama odvijaju (eng. Activities). Vrlo je važno na fokusiranim radnim sastancima s ekspertima iz odreñene procesne domene i ključnim korisnicima definirati aktivnosti procesa, tj. što točno proces mora činiti kako bi se producirao poslovni rezultat - bez prevelike brige i načinu povezivanja aktivnosti i definiranju radnog tijeka procesa. Prilikom definiranja faza procesa potrebno je kreirati smislene cjeline - koje kasnije mogu postati potprocesi u procesnoj hijerarhiji. Jedna od glavnih karakteristika rapidnog i agilnog otkrivanja procesnih elemenata leži u činjenici da ključni korisnici bolje definiraju zahtjeve ukoliko se na početku definiranja procesnih elemenata fokusira na što proces radi, a kasnije na način i kako to radi. Naravno, potrebni su i kvalitetni alati koji lako mogu pogled i perspektivu mijenjati ovisno o modu analize.

Nakon definiranja glavnih elemenata procesa, BPM analitičari zajedno s ključnim korisnicima i domenskim ekspertima definiraju tijek rada procesa, fokusirajući se sada na procesnu logiku koja povezuje ranije definirane procesne elemente te dodajući nove (Slika 2). Mogućnost simulacije raznih scenarija prolaska kroz novodefinirani poslovni proces važni su za dobivanje potvrde od strane ključnih korisnika da je upravo odreñena verzija procesa ono što žele kao buduće stanje u svom poslovanju.

Nakon definicije i otkrivanja procesnih dijagrama BPM analitičar zajedno s IT razvojnim stručnjakom radi na

Slika 1 - Standardni BPM razvoj

Slika 2 - Ciklus razvoja pri agilnom BPM-u


implementaciji procesa. Za agilan razvoj važno je da procesni model ostaje isti te u istoj notaciji, Business Process Modeling Notation (BPMN). Procesni dijagram zadržava svoj oblik i radni tijek, a IT razvojni stručnjak u odreñenim procesnim elementima dodaje tehničke karakteristike koje služe u realizaciji i implementaciji procesa. Standardni način transformacije poslovnih procesa u izvršni oblik uključuje promjenu notacije, npr. BPMN u BPEL, kako bi poslovni proces dobio izvršne karakteristike. Obično se prilikom transformacije nije moguće kasnije vratiti u izvorni procesni model što nakon nekog razvojnog vremena rezultira odmakom i razlikom procesnog modela i izvršnog modela.

Agilni i rapidni BPM razvoj preskače korak transformacije iz procesnog u izvršni model i sjedinjuje optimizaciju i reinženjering procesa s implementacijom i integracijom. Vrlo često korisnik povezuje inovacije i poboljšanja korisničkog sučelja s inovacijom i poboljšanjem poslovnog procesa i teško razlučuje jedno od drugog. To je jedan od razloga zašto agilni BPM kao jednu od glavnih prednosti pristupa navodi tzv. „Playback“ mehanizam u kojem je novu verziju procesa zajedno s novim korisničkim sučeljem moguće „vidjeti“ u izvršnom modu - što je vrlo važno za korisnika kako bi se uvjerio o načinu rada s novim procesom te potvrdio da proces sadržava sve one elemente koji su mu potrebni u radu i na taj način potvrdio finalnu verziju procesa.

Sve ranije navedene prednosti agilnog BPM-a mogu se iskoristiti ukoliko BPM alat i platforma pružaju navedene mogućnosti. Nova IBM BPM platforma pruža upravo opisane mogućnosti kroz novu platformu u čijem je samom središtu koncept dijeljenog modela i repozitorija (Slika 3).

Dijeljeni model je ključan za razumijevanje poslovnog procesa od strane poslovnog analitičara, korisnika i IT razvojnog stručnjaka te za njihovu meñusobnu suradnju. Nad istim modelom se rade sve promjene i automatski postaju vidljive svim zainteresiranim stranama u razvojnom ciklusu dok poslovni proces i dalje ostaje u standardnoj BPMN notaciji.

Dijeljeni model takoñer ne uključuje samo razvojne specijaliste već u produkcijskoj okolini sprema i podatke o interakciji korisnika s poslovnim procesima, aktivnostima koje izvršavaju te takoñer bilježi i sve

dodatne ad-hoc aktivnosti koje korisnik može dodati u sam proces bez reinženjeringa i dodatnog razvoj pri samom izvršenju procesa. Sve zabilježene akcije dostupne su kasnije u obliku izvještaja za pregled upraviteljima procesa koji na osnovu tih informacija mogu zaključiti jesu li implementirane promjene procesa rezultirale poboljšanjem poslovnih performansi. Ukoliko se kroz praćenje procesnih performansi zaključi da poboljšanja poslovanja nisu zadovoljavajuća, rezultati se koriste u novom ciklusu poboljšanja procesa i zajedno s korisnikom se radi na optimizaciji procesa i vrše se dodante simulacije koje će provjeriti performanse novih elemenata.

Meñusobna suradnja je takoñer jedan od važnijih elemenata agilnog BPM razvoja te je stoga i komunikacija meñu članovima tima integrirana u samu BPM platformu omogućujući razne chat mehanizme, „wiki“ ili „blog“ stil sažetka aktivnosti nad procesima i ostali elementi koji omogućuju praćenje razvoja i implementacije procesa od samog početka do kraja. Na taj način, članovi tima koji možda i nisu sudjelovali u stvaranju odreñenog procesa mogu zaključiti i saznati kako je proces evoluirao do trenutne verzije i možda neke od elemenata iz procesnih verzija koje nisu kasnije opstale uzeti dijelove kao prihvatljive za neki drugi proces.

5. ŽIVOTNI CIKLUS POSLOVNOG ENTITETA

Pri optimizaciji poslovnih procesa i optimizaciji poslovnih performansi postoje i koraci koji se ne tiču direktno procesnih koraka i tijeka procesa, ali se dotiču okvira u kojima se procesi definiraju i stvaraju pretpostavke za kvalitetnu definiciju poslovnih procesa. Stoga je jedan od važnijih koraka u optimizaciji poslovanja i tzv. Procjena poslovne agilnosti (eng. Business Agility Assessment) u kojima se generalno procjenjuje razina zrelosti poslovnih procesa kroz nekoliko kategorija i karakteristika kako bi se bolje razumjeli okviri u kojima se poslovni mogu unaprijediti. Procjena pruža holistički pogled na cjelokupno okruženje.

Dodatan pogled i jedan od važnijih uz sam procesni tijek je i tzv. Životni ciklus poslovnog entiteta, u kojem se kao

Slika 3 - Arhitektura agilne BPM platforme


paralelan i komplementaran pogled na procesnu optimizaciju definiraju glavni poslovni (informacijski) entiteti nad kojima procesne aktivnosti rade promjene. Promjene uključuju unos ili prikaz raznih atributa, promjene stanja i statusa i sl. Poslovni entitet sa svojim promjenama živi unutar odreñenih poslovnih procesa ili faza poslovnog procesa te je analiza njegovog životnog ciklusa važna za dobru definiciju procesnih granica i njegovih faza. Nad poslovnim entitetom odreñeni sustavi i ljudski resursi rade promjene te je takoñer važan za definiranje razine odgovornosti pojedinih procesnih rola.

6. ZAKLJU ČAK

U ovom radu opisani su koncepti pristupa izgradnje sustava za agilno upravljanje i optimizaciju poslovnim procesima i njihova usporedba s klasičnim i konvencionalnim današnjim pristupom. Pokazan je način

kako pristupiti izgradnji sustava za agilno upravljanje i optimizaciju poslovnim procesima, prednosti koje on donosi te je opisana arhitektura sustava za agilno upravljanje poslovnim procesima.

Promjene u okruženju koje imaju utjecaja na poslovanje, lančano se prenose na IT, stoga je važnost fleksibilnosti u obje domene vrlo velika. Pokazano je da postojeći pristup upravljanju poslovnim procesima nije dostatan za pružanje tražene fleksibilnosti i kao rješenje se nudi sljedeći evolutivni korak, a to su agilno upravljanje i optimizacija poslovnih procesa.

Tehnike i koncepti korišteni u ovom radu nisu ovisni o tehnološkim platformama i alatima za izradu IT sustava, meñutim sami primjeri su pokazani na IBM BPM 7.5 procesnoj platformi koja je predvodnik u istraživanju na polju sustava za agilno upravljanje i optimizaciju poslovnih procesa.

Literatura:

1 IBM CEO Study 2010: Capitalizing on Complexity; IBM Institute of Business Value

2 D.Ramljak, „Dinamički prilagodljivi poslovni procesi kroz BPM i SOA koncepte“, CASE 22

3 D.Ramljak, „Dynamic adaptability of services by integrating Service Oriented Architecture and Enterprise Architecture“, Doctoral thesis, pending

Podaci o autoru:

mr.sc. Darije Ramljak Managing Consultant/ Senior IT Architect Application Innovation Consulting Leader, SEE IBM Hrvatska [email protected] Darije Ramljak je Managing Consultant i Senior IT Architect za integracijska i Service Oriented Architecture (SOA) rješenja. Njegove specijalnosti su strategija, analiza, arhitektura i dizajn integracijskih i e-business rješenja te automatizacija poslovnih procesa. U IBM Hrvatska dolazi 2003. godine. Stručno iskustvo stjecao je radeći u kompanijama Ericsson Nikola Tesla na poziciji Software Architect/Senior Software Engineer te Combisu Hrvatska kao IT specijalist. Tijekom svoje karijere radio je na mnogim projektima u javnom, financijskom i telekomunikacijskom sektoru kao konzultant, glavni arhitekt za rješenja te kao glavni softverski arhitekt. Meñu njegovim najznačajnijim projektima treba istaknuti: Integrirani informacijski sustav za razmjenu podataka o PDVu u EU (Porezna uprava), Integrirani informacijski sustav upravljanja sudskim predmetima (Ministarstvo pravosuña RH) te Bugarski integrirani carinski informacijski sustav (Bugarska carinska agencija). Diplomirao je na Fakultetu elektrotehnike i računarstva Sveučilišta u Zagrebu. Zvanje magistra znanosti na polju računarstva stekao je 2004. godine. Darije Ramljak je IBM Certificirani IT Arhitekt, Master Certificirani IT Arhitekt, IBM Certificirani konzultant, IBM Certificirani SOA Solution Designer, IBM Certificirani e-business Solution Designer te Certificirani Rational konzultant. Autor je nekoliko desetaka znanstvenih radova objavljenih na meñunarodnim konferencijama. Član je Association of Open Group Enterprise Architects, Business Process Management Institute-a (BPMI), IEEE Computer Society i IEEE Society. Darije Ramljak is Application Innovation Consulting Leader for South East Europe (SEE) service line in IBM Global Business Services. He is also working in a role of Managing Consultant/ Senior IT Architect for Enterprise and Service Oriented Architecture (SOA) Solutions in GBS Croatia. He leads a team of experienced IT Consultants and IT Architects within the GBS AIS practice in IBM SEE. He holds an M.S. degree in Computer Science. He is also an IBM Certified IT Architect, Master Certified IT Architect, IBM Certified SOA Solution Designer and IBM Certified Consultant.


TEHNIČKO VODSTVO U DJELATNOM RAZVOJU SOFTVERSKIH PROJEKAT A

TECHNICAL LEADERSHIP IN THE ACTIVE SOFTWARE DEVELOPMENT PROJECTS

Nikola Stjelja

SAŽETAK:

Svaki razvojni projekt koji na kojemu rade dva ili više inženjera ima nadreñenog zaduženog za primjenu tog projekta. U hrvatskoj takva osoba nosi nekoliko naziva: glavni programer, prvi programer, vodeći programer, planer tehničkog rješenja itd. Softverskom terminologijom takva se osoba zove Technical leader ili Tech lead , odnosno na hrvatskom jeziku tehnički voditelj projekta. Tehnički voditelj projekta preuzima potpunu odgovornost za koordinaciju i razvoj odreñenog programskog modula -

Bez tehničkog voditelja projekta razvojni inženjeri razbježali bi se svaki na svoju razvojnu stranu, nitko osim njih ne bi znao u kojoj je fazi izrade tehnički projekt niti slijedi li tehnička primjena jedinstveni princip razvoja i kvalitetu.

Uloga tehničkog voditelja projekta je složena, a u sebi objedinjuje uloge projektnog menadžera i razvojnog inženjera, ali bez moći projektnog menadžera i bez slobode razvojnog inženjera da se fokusira i brine za razvoj svojeg dijela aplikacije.

Namjera ovog članka jest definiranje i približavanje čitatelju svih aspekata i problematike tehničkog voñenja rješenja kao i čestih rješenja za česte probleme s kojima se tehnički voditelji projekata susreću.

ABSTRACT:

On every software development project on two or more engineers are working on there is a person in charge of its technical aspect of this project. In Croatia, such a person carries several titles: the main developer, the first developer, a leading developer, planner, etc. In a general software terminology such a person is called a Technical leader or Tech lead. The Tech Lead takes full responsibility for the coordination and development of specific software modules.

Without a tech lead developers would each be working on its little corner of the project and nobody would know daily how all the project is progressing and there would not be a unified vision regarding the technical project implementation.

The role of a tech lead is complex, and embodies the roles of both a project manager and a developer, but without the power of project managers and without the freedom of development engineers to focus the pure development of their respecitve development areas..

The goal of this article is to shed light on the goals, responsibilities and techniques real life technical lead practices daily in her professional career.

1. DEFINIRANJE PROBLEMA - ULOGA TEHNIČKOG VODITELJA PROJEKTA

Tehnički voditelj projekta je ona osoba koja posjeduje iskustvo, visoko znanje i specifične vještine ophoñenja i suradnje s ljudima, a zadužena je za: dizajniranje, planiranje, koordinaciju rada te izradu najsloženijeg, odnosno najvažnijeg, dijela odreñenog softverskog rješenja. Premda tehničko vodstvo može niknuti spontano u nekom razvojnom timu gdje jedan od razvojnih inženjera, zahvaljujući svojem iskustvu, znanju i komunikacijskim vještinama stekne ugled ili dominaciju nad drugim članovima tima u toj mjeri da sam donosi ključne tehničke odluke i provodi planove razvoja nekog softverskog rješenja, pod terminom tehnički voditelj projekta podrazumijevamo ulogu na konkretnom projektu koju projektni menadžer službeno dodijeli razvojnom inženjeru. Organizacijska moć koju time tehnički voditelj poprima je ključna za obavljanje onih zadataka tehničkog voditelja projekta koji zahtijevaju interakciju i odlučivanje unutar razvojnog tima. Naime, odreñeni dio uloga tehničkog voditelja projekta zadiru u područje projektnog menadžmenta (koordinacija ljudi, kontrola rada i moderatorstvo u diseminaciji informacija meñu članovima tima) dok se druge odnose na konkretno

odlučivanje o dnevnim tehničkim problemima koji nastaju u radu bilo kojeg razvojnog projekta. Softverski inženjeri bilo kojeg profila i inklinacije su, kao grupa "mačaka" koje je, ako su prepuštene sebi samima, jako teško uhvatiti za rep i kontrolirati njihov posao. Prvenstveni razlog nemogućnosti detaljne kontrole dnevnog rada razvojnog inženjera leži u kompliciranoj tehničkoj prirodi softvera koji se razvija i prirodnoj znatiželji razvojnih inženjera koji se često prepuštaju u vlastitu eksploraciju odreñenih tehničkih područja, problema ili čak razvoja, potpuno novih i neželjenih funkcionalnosti u aplikaciji.

Vrlo je teško netehničkom osoblju, koje svakodnevno ne radi na kodnoj bazi projekta, uvidjeti tehničke probleme i kretanje projekta. Tehnički voditelj projekta je prema tome ona osoba koja služi kao komunikacijski kanal i medijator volje projektnog menadžmenta tijekom kontrole rada i prevencije, odnosno uklanjanja svih dnevnih tehničkih problema, na odreñenom projektu.

2. DUŽNOSTI TEHNIČKOG VODITELJA PROJEKTA

Tijekom razvoja odreñenog softverskog projekta tehnički voditelj ima sljedeće dužnosti:


� Dizajniranje i planiranje tehničke implementacije projekta;

� Planiranje i dodjeljivanje radnih zadataka članova tima;

� Kontrola i validacija odrañenih radnih zadataka; � Izrada ključnog (tehnički najsloženijeg ili poslovno

najvažnijeg) dijela softverskog rješenja; � Komunikacija i moderacija s i izmeñu članova tima; � Komunikacija i moderacija s projektnim

menadžmentom te � Komunikacija i moderacija s dionicima projektima

(klijentima).

Dizajniranje i planiranje tehni čke implementacije projekta obuhvaća sve djelatnosti vezane za definiranje arhitekture projekta, detaljnog dizajna projekta, odnosno konfiguracijskog menadžmenta projekta unutar definiranih organizacijskih okvira (struktura projekta, sustav za kontrolu revizija, labeliranje i verzioniranje, organizacija poslužitelja, razvojna okolina, alati i tehnologije). Ovisno o projektu i organizaciji u kojoj radi, tehnički voditelj projekta će obavljati jednu ili više tih aktivnosti te sudjelovati s drugim stručnjacima unutar i izvan organizacije (poslovnim analitičarima, arhitektima, drugim tehničkim voditeljima), kao i članovima tima, na njihovom razvoju.

Planiranje i dodjeljivanje radnih zadataka članova tima obuhvaća postupak formuliranja i izrade konkretnih zadataka na temelju tehničke specifikacije projekta čije će pravilno izvršenje dovesti do pravovremenog završetka projekta. Tehnički voditelj mora dodijeliti svaki zadatak onom inženjeru koji ga može najbolje napraviti, odnosno koji je najpodesniji njegovom izvršavanju pa je nužno da poznaje snage i mane svakog člana tima.

Kontrola i validacija odra ñenih radnih zadataka je druga strana planiranja i dodjeljivanja radnih zadataka članovima tima. Zadatak koji je dodijeljen ali nije redovito kontroliran i validiran nema istu težinu, brzinu i kvalitetu izvoñenja kao onaj koji je redovito kontroliran i čiji se rješavanje provjerava prema odreñenom skupu kriterija kojima se utvrñuje uspješnost njegova rješavanja. Oni zadaci čije je rješavanje prepušteno razvojnim inženjerima, bez nadzora se ne mogu smatrati zadacima u užem smislu riječi, već naputcima i smjernicama čiji su krajnji rezultati nepoznanica.

Naravno, kontrolu i provjeru zadataka ne treba zamijeniti s mikromenadžmentom i rigoroznim kriterijima. Razvoj softvera je kreativna aktivnost u kojoj je tijekom rada na bilo kojem zadatku uvijek potreban stupanj elastičnosti i slobode. Stvoriti okolinu gdje su te dvije karakteristike sputane i ugušene prizvalo bi velike poteškoće u razvoju bilo kojeg sustava kao i velike probleme s održavanjem stalnog broja zaposlenih jer razvojni inženjeri u velikom broju imaju tendenciju napuštanja takvih okruženja.

Izradu klju čnog (tehni čki najsloženijeg ili poslovno najvažnijeg) dijela softverskog rješenja obavlja osoba odgovorna za tehničku stranu projekta, ujedno poslovno najvažniju ili tehnički najsloženiju cjelinu mora. Jer, upravo o uspješnosti realizacije te cjeline ovisi komercijalni uspjeh projekta, odnosno budući upliv kapitala u trgovačko društvo (organizaciju ili instituciju) koje razvija to rješenje. Svaki razvojni projekt ima odreñenu cjelinu koja je u njegovoj srži i oko koje se sve okreće ili koja ima najveću poslovnu važnost. U suradnji s poslovnim dionicima koji definiraju ključne zahtjeve projekta potrebno je identificirati tu cjelinu i zadužiti tehničkog voditelja projekta za njezin razvoj.

Komunikacija i moderacija sa i izme ñu članova tima obuhvaća one dužnosti tehničkog voditelja projekta koje

se oslanjaju na dvije osnovice modernog razvoja softvera: � Softverska rješenja u razvijanju ljudskoga

potencijala te � Ljudi koji razvijaju softverska rješenja imaju veliku

potrebu za informacijama.

Same po sebi ove dvije karakteristike nisu loše, dapače, bez njih bi se softverski projekti jako teško dovršavali. Još su 70-ih godina prošloga stoljeća procijenili da bi jednom čovjeku za razvoj jednog operativnog sustava trebalo više od tristotine godina . Osim toga razvoj softvera zahtjeva da svi koji rade na njemu idu više manje u istom smjeru i da se problemi koji nastaju brzo rješavaju odnosno da se znanje o rješavanju problema brzo diseminira. To znači da se očekuje da će bilo koja promjena na "ekosistemu" sustava brzo probaviti u "probavnom traktu" tima i na taj način pretvoriti u konkretne zadatke čiji je krajnji rezultat niz konstrukcija koje čine srž razvoja softvera.

Što je tu uloga tehničkog voditelja projekta? Svrha njegove uloge proizlazi iz sljedećih činjenica: � Tehnički voditelj mora znati koji su tehnički problemi

na sustavu i često znati što je ili tko je najbolje rješenje za njih.

� Tehnički voditelj je zadužen za usmjeravanje tehničkog razvoja projekta.

� Promjene koje ulaze u razvojni tim, odnosno projekta, su raznovrsne i kaotične, netko ih mora urediti i prilagoditi timu s ciljem da izazovu najviše koristi sa najmanje smetnje.

Tehnički voditelj je okosnica sve važne dnevne komunikacije unutar tima. Nedostatak uspješne komunikacije siguran je pokazatelj problematičnog tima, odnosno problematičnog tehničkog voditelja projekta.

Komunikacija i moderacija s projektnim menadžmentom zahtjeva potpuno druge vještine i znanja od onih potrebnih za komunikaciju i moderaciju sa timom. Projektni menadžeri imaju svoj jezik, svoje ciljeve i mnogi od njih nisu jako dugo programirali, ako i uopće. U najboljem slučaju programer je za njih jako dobar alat kojeg je potrebno iskoristiti ili, u najgorem, code-monkey kojeg je moguće bez problema zamijeniti sa drugim. U mnogim trgovačkim društvima projektni menadžeri su oni koji utječu na daljnju karijeru razvojnog inženjera u toj organizaciji gdje se trenutačno nalaze. Svaka komunikacija s projektnim menadžerom mora biti oprezna i pažljiva. Postoji nekoliko scenarija u kojima se tehnički voditelj može naći dok razgovara sa projektnim menadžerom: � Sve je u redu s projektom, projektni menadžer i

tehnički voditelj se slažu oko rada na projektu; � S projektom nije sve u redu, ali se obojica i dalje

slažu oko rada na projektu; � Sve je u redu s projektom, ali ne slažu se u mišljenju

što se treba napraviti; � S projektom nije sve u redu, projektni menadžer

traži zamjenu za tehničkog voditelja projekta.

Prva dva scenarija su u redu, s projektom se može ili nastaviti ili ne (što je češći slučaj, o čemu je Stephen Vincent Benet u knjizi 'John Brown's Body' napisao pjesmu koja jasno oslikava problematiku), ali sve je u redu dok Veliki Čovjek - projektni menadžer i Mali Čovjek - tehnički voditelj imaju jasnu viziju što treba napraviti da bi se projekt uspješno priveo kraju. Problem nastaje kada se tehnički voditelj i projektni menadžer ne slažu oko rada na projektu; možda projektni menadžer zahtjeva nerealne rokove ili inzistira na tehnički lošem


rješenju. Tehnički voditelj projekta treba imati jasan kompas za snalaženje u tim situacijama.

Druga strana komunikacijske problematike izmeñu projektnog menadžera i tehničkog voditelja jest kretanje informacija, naredbi i planova unutar i izvan tima. Tim se najčešće sastoji od mnogo ljudi (jedna od osobina definicije tima) od kojih nijedan nije kopija drugog, od kojih svaki ima drugo mišljenje i drugačiji pogleda na stanje sustava (pogotovo ako dva inženjera rade na drugačijim aspektima sustava ili drugim modulima), a zadatak tehničkog voditelja je sintetizirati sve te informacije u tri konkretna izvještajna aspekta: � Stvarni napredak naspram planiranoga napretka; � Problemi i planirana rješenja te � Kritične točke koje zahtijevaju pažnju projektnog

menadžera.

Drugim riječima, tehnički voditelj projekta ima zadatak rastaviti informacije, naredbe i planove koje je dobio od projektnog menadžera u zadatke, jasne i pravovremena upute koja će pomoći radu tima, pri tome ga ne zakompliciravši.

Komunikacija i moderacija s dionicima projektima (klijentima) je najrizičnija djelatnost koju tehnički voditelj projekta obavlja. Dok je za projektne menadžere moguće reći da imaju pozitivan interes za tehničkog voditelja projekta i druge inženjere koji rade za njih, klijenti i drugi poslovni dionici projekta nemaju nikakve pozitivne osjećaje prema blagodati i budućnosti tehničkog voditelja projekta. Oni su za razvoj projekta "opasni". Svaka komunikacija s njima mora biti pažljiva i odmjerena. Srećom, većinu tereta komunikacije s klijentima preuzima na sebe projektni menadžer, dok na tehničkom voditelju ostaje samo djelatnosti prikupljanja zahtjeva, pojašnjavanja otvorenih pitanja oko ugovorenih funkcionalnosti na projektu, pojašnjavanja strateških tehničkih pitanja oko stanja na projektu itd. U čemu je problem sa klijentima? Klijenti organizaciji daju odreñena financijska sredstva za odreñenu uslugu. Priroda softverskog posla podrazumijeva definiciju pružene usluge kao fleksibilnu tako da se klijenti trude svojski izvući najviše što mogu za pruženi novac. S druge strane, organizacija želi održati komercijalni odnos s klijentom i više ponoviti ga što više puta prema pravilima tržišne ekonomije. Problem za tehničkog voditelja projekta jest da što god ugrožava status quo s klijentima biva odstranjeno. Tehnički voditelji projekta su najčešće u "rovovima", što znači da svakodnevno produciraju kod ili druge produkte koji utječu na završetak projekta. Što su više u kontaktu s klijentima to su izloženiji većim pritiscima (klijent zahtjeva poslove koji su izvan ugovora, razvojni inženjeri klijenta ne poštuju dogovore i rokove itd.) bez ikakve službene ovlasti (najčešće) da poduzmu nešto glede tih pritisaka bez suradnje s projektnim menadžerom (koji ne može biti svaki trenutak uz tehničkog voñu projekta, pogotovo kada ovaj radi offsite na lokaciji klijenta).

3. VJEŠTINE TEHNIČKOG VODITELJA PROJEKTA

Tehnički voditelj projekta dolazi na svoju poziciju i ostaje na svojoj poziciji zahvaljujući svojim vještine. Naravno, njegove ljudske vještine i mreža odnosa koju je stvorio imaju ulogu u tome, ali primarno se tehnički voditelji projekta biraju zbog svojih tehničkih vještina. Razvoj modernih softverskih rješenja zahtjeva mnogo vještina, vještina koje se svakodnevno moraju prakticirati da se ne bi gubilo na kvaliteti, što u današnjem konkurentnom

svijetu može uzrokovati probleme u karijeri tehničkog voditelja projekta.

Moderne tehnologije za razvoj softvera se razvijaju i granaju takvom brzinom da je nemoguće sve pratiti, niti je moguće specijalizirati se u jednoj općoj tehnologiji jer je rizik zaostajanja preveliki s obzirom na brzinu razvoja industrije.

Tehnički voditelj projekta mora svakodnevno raditi na razvoju: � Praktičnih tehničkih vještina i � Teoretskih tehničkih vještina.

Dobar tehnički voditelj svakodnevno uči praktičnu promjenu alata, jezika i drugih sredstava svojega svakodnevnog rada. To podrazumijeva provoñenje odreñenog dijela svojeg slobodnog vremena i posla na privatnom vježbanju i istraživanju novih i usavršavanju starih tehnologija.

Teoretske vještine su jedan od često zanemarivanih faktora u usavršavanju bilo kojeg softverskog inženjera. Dok praktične vještine rješavaju dnevne i konkretne probleme, jedino teoretske vještine mogu davati tehničkom voditelju projekta dovoljnu dubinu i širinu da svoje praktičke vještine upotrijebi na kvalitetan i strateški prihvatljiv način. U razvoj softvera ulazi toliko mnogo drugih komponenti, osim kodiranja i testiranja, da je suludo ne proučavati široki teoretski spektar softverskog inženjeringa. Vlastito usavršavanje je dugoročni, cjeloživotni proces koji se mora odvijati planski ili ciljano. Starenjem spontanost i lakoća u primanju novih znanja nestaju i zamjenjuje ih inercija i lagodnost, stoga je vrlo važno da svaki softverski inženjer periodički planira i definira svoj plan usavršavanja. Pri tome treba voditi računa o sljedeće četiri kategorije: � Ključne tehnologije za trenutačni projekt; � Ključne tehnologije za trenutačnu organizaciju � Tehnologije koje će u bliskoj budućnosti postati

ključne za organizaciju te � Tehnologije koje će u bliskoj budućnosti biti od

značaja za rad i karijeru tehničkog voditelja projekta.

Ove kategorije ne samo da definiraju grube konture plana za usavršavanje, već definiraju i prioritete.

Klju čne tehnologije za trenuta čni projekt su najvažnije za tehničkog voditelja projekta jer one trenutačno utječu na njegovu karijeru i rad, pogotovo ako tehnički voditelj nema zadovoljavajući stupanj znanja. S druge strane klju čne tehnologije za organizaciju su one tehnologije koje sjede u srži razvojnih projekata trgovačkog društva i s kojima bi se tehnički voditelj mogao susresti u bliskoj budućnosti.

Budućnost je teško predvidljiva, sigurna tehnologija budućnosti nestaje bez najave zbog npr. naglog preokreta na tržištu, ali bitno je moći predvidjeti ključne tehnologije za organizaciju za koje radi te koje su mu osobno zanimljive.

Ključni faktor u samoobrazovanju i pripremanju jest podatak da većina današnjih razvojnih inženjera to ne radi . Meñutim, dovoljno je to činiti toliko da se voditelj izdigne iz mase neangažiranih inženjera; u zemlji slijepih, jednooki je kralj.

3.1 Komunikacijske vještine i poslovni odnosi

Neupućena osoba koja izvana promatra rad tehničkog voditelja projekta, rekla bi da se njegov posao sastoji od programiranja i rješavanja tuñih problema. Ta osoba ne bi bila previše u krivu.


Posao tehničkog voditelja projekta se sastoji od ljudi i odnosa sa njima s fokusom na tehničku realizaciju projekta. Razvoj modernog aplikativnog i sistemskog softvera je izrazito kompleksan i u to je uključen veliki broj brzo rastućih i mijenjajućih tehnologija. Nijedna osoba nije u stanju vladati svima niti ih sve može znati dobro primijeniti. To je uloga tima, u grupi od tri do šest osoba zasigurno postoji jedna osoba koja je primjerenija rješenju odreñenog problema od drugih, a to često i nije tehnički voditelj projekta. Komunikacija i odnosi su ono što čini uspješan tim.

Visokoproduktivni timovi imaju dobre meñusobne odnose i jako izraženu dvosmjernu komunikaciju. Tehnički voditelj tima može svojim znanjem i stavovima tu ravnotežu ili očvrsnuti ili srušiti. U svakodnevnom radu s ljudima tehnički voditelj mora težiti prema sljedećem: � Pojačavanju odnosa sa svim članovima tima; � Pojačavanju odnosa sa ključnim ljudima u njegovoj

obližnjoj blizini i � Omogućavanju komunikacije i otklanjanju

komunikacijskih blokova meñu svim članovima tima.

Pojačavanje odnosa sa svim članovima tima je kritična aktivnost svakoga tko želi biti u ulozi voditelja. U softverskoj industriji mnogo je ljudi različitih kultura i svjetonazora, ali nema glupih ljudi. Ljudi koji razmišljaju, koji se bave kreativnim i intelektualnim poslom negativno i nekreativno reagiraju prema osobama s kojima imaju narušene odnose. Jedini način da tehnički voditelj dogura do kraja projekta jest da ima dobre odnose sa svojim timom. Nijedan tim ne radi u izolaciji, već u poslovnom ekosistemu koji se sastoji od različitih ljudi i odjela. Premda oni nisu bitni u svakodnevnom radu, poja čavanje odnosa sa ljudima izvan tima može izrazito pomoći u onom trenutku kada je potrebno da tim posegne izvan svoje svakodnevne dome u druge dijelove organizacije.

Članovi tima meñusobno komuniciraju. U toj se komunikaciji pojavljuju problemi ljudske ili tehničke prirode. Uloga tehničkog voditelja tima jest da prepozna komunikacijske probleme unutar tima i da ih otkloni s ciljem da se usmjerena i slobodna komunikacija odvija u smjeru uspješnog rješavanja projekta. U tome će mu pomoći komunikacijski stil koji potencira: indirektne naredbe (kroz pitanja, zamolbe itd.), asertivnost i prilagodljivost te lukavstvo.

Tehnički voditelj projekta dužan je obratiti pažnju na komunikaciju na teme: � Proces razvoja; � Tehnički problemi i rješenja; � Arhitektura; � Ljudski problemi i resursi; � Zahtjevi projekta te � Projektni planovi i napredak.

Tehnički voditelj projekta je najniži stupanj korporativne kontrole nad razvojem i napredovanjem projekta. On se dnevno nalazi u poziciji da otkrije i ispravi probleme na razvoju projekta i da se pobrine da na dnevnoj bazi projekt napreduju u željenom i planiranom smjeru. Odnosi i komunikacija će odvesti tehničkog voditelja i njegov projekt daleko, ali samo kontrola i praćenje će dovesti projekt blizu kraja u zadanim rokovima i sa zadanim budžetom.

S obzirom na kontrolu, važno je da se tehnički voditelj projekta usredotoči na: � Usuglašavanje planiranog i napravljenoga; � Realizaciju kritičnih zadataka na projektu; � Zahtjeve i promjenu na arhitekturi projekta te

� Organizaciju i izvoñenje konfiguracijskom menadžmenta nad ključnim proizvodima projekta.

Prijedlog rješenja problema - Tehnike tehni čkog voditelja projekta

Tehničko voñenje projekta je pragmatična disciplina i, kao i sve druge, i ona ima svoja pravila. Odreñene tehnike u savladavanju svakodnevnih problema su se opetovano pokazale uspješnima prilikom mnogobrojnih ponavljanja i nepredvidivih situacija kojima obiluje tehničko voñenje softverskih projekata.

U narednom tekstu ću opisati nekoliko takvih tehnika koje sam prakticirao u svojem radu i koje su se pokazale uspješne. One nisu univerzalna rješenja i ne moraju biti uspješne u svim situacijama, ali mene dovoljno dobro služe pa sam ih odlučio posložiti i uobličiti u lako čitljivom i prepoznatljivom obliku. Opisane tehnike su: � Jutarnja tri pitanja, � Sličice i strelice, � Ti nisi menadžer i � Pčelica zujalica.

Jutarnja tri pitanja

Sažetak

Svaki dan tijekom regularnog skupljanja informacija svaki član tima ima zadatak odgovoriti na tri jasna pitanja: � što si jučer napravio?, � što ćeš danas napraviti? i � koje probleme imaš?

Čemu služi

Ljudi ne komuniciraju otvoreno i izravno i vrlo je teško dobiti jasne odgovore od suradnika o tome gdje stoje i kamo idu, a kamoli dobiti dobar uvid u tijek njihova rada tijekom vremena. Osobi koja jasno mora odgovoriti na ova tri pitanja svaki dan teško je prikriti svoj rad. U tom kontekstu pitanja su dobar alat za postizanje transparentnosti.

Koji problem rješava

Jutarnja tri pitanja rješavaju problem nejasnog izvještavanja članova tima o svom radu.

Kako se primjenjuje

Jednostavno, tehnički voditelj izravno postavi svakom članu tima navedena pitanja i ne odustaje dokle god mu se jasno ne odgovori na njih. Praktičnost ove metode jest u tome da su moguća dva ishoda: ili će tehnički voditelj dobiti jasniju sliku tijeka projekta ili će znati da ima problematičnog člana tima i proslijediti problem menadžeru da ga riješi.

Sličice i strelice

Sažetak

Prilikom pisanja tehničke dokumentacije ili skiciranja nekog sastanka ili rješenja nekoliko sličica i strelica nosi više informativne težine od velike količine teksta i priče.

Čemu služi

Ljudi su vizualna bića i dokazano je da se više pamti slikom, nego tekstom. Jednostavne geometrijske objekte i strelice jednostavno je i brzo primijeniti.


Sličice i strelice rješavaju problem brzog i jasnog prijenosa tekstualnih informacija.


Kako se primjenjuje

Sličice i strelice se primjenjuju tako da se za svaki veći skup teksta izradi jedna jednostavna sličica koristeći jednostavna geometrijska tijela i strelice koji apstrahiraju bit teksta.

Ti nisi menadžer

Sažetak

Sjeti se da ti nisi glavni, ima netko tko je iznad tebe kome se možeš obratiti i čiji posao ne moraš raditi.?!

Čemu služi

Tehnički voditelji često se suočavaju sa situacijama za koje je potreban projektni menadžer. Moraju se sjetiti da oni nisu projektni menadžeri te prepoznati kada se trebaju odmaknuti od problema i prepustiti drugima da ga riješe, pogotovo ako se radi o većem ljudskom problemu u timu.


Rješava problem zadiranja uloge tehničkog voditelja u polje gdje nema organizaciju moć da išta učini.

Kako se primjenjuje

Kada god je voditelj suočen sa problemom koji zahtjeva moć koja organizacija daje projektnom menadžeru on treba ustuknuti i prepustiti rješavanje problema onome tko je u biti zadužen za njega.

Pčelica zujalica

Sažetak

Svaki dan u odreñeno vrijeme odzuji do svakog svog inženjera da vidiš kako mu ide, pa onda odzuji do drugoga...

Čemu služi

Ljudi ne vole sastanke, ne vole dugo vremena provoditi u zatvorenim sobama i jednoj sobi odgovarati na pitanja, ne vole govoriti pred drugima itd. U nekim organizacijama jednostavno nije izvedivo imati dnevne informativne sastanke gdje bi se pratilo stanje projekta bilo iz organizacijskih ili kulturnih razloga. Iako za običnog člana tima takvi sastanci nisu uvijek najbolje utrošeno vrijeme, oni su neophodni za tehničkog voditelja projekta da bi mogao osjetiti i pratiti bìlo projekta. Pčelica zujalica se koristi kao sredstvo organizacije prividnih sastanaka izmeñu tima i tehničkog voditelja gdje voditelj prenosi od jednoga do drugoga korisne informacije i ideje.


Pčelica zujalica rješava problem nedostatka dnevnih izvještajnih sastanaka.

Kako se primjenjuje

Svakog dana u odreñeno vrijeme, najbolje sat vremena nakon početka radnog dana, tehnički voditelj fizički odlazi do jednog od svojih inženjera i započinje razgovor s ciljem da sazna kako mu ide. Kada dobije onoliko informacija koliko mu je potrebno, odlazi do drugog člana tima i ponavlja isti postupak. Putem će voditelj prenositi informacije važne drugim inženjerima i tražiti od njih pomoć za probleme koje neki od njih ima, a nikome nije dao do znanja da mu je potrebna pomoć.

4. ZAKLJU ČAK

Uloga tehničkog voditelja projekta je nužna na skoro svim softverskim projektima. Osobe koje se nalaze u toj ulozi moraju rješavati slične probleme, sa sličnim rješenjima. Potrebo je ostvariti razumijevanje i definiranje te uloge te praktično primjenjivati jedan jedinstveni set znanja i praksi kroz sve razvojne organizacije u s ciljem usavršavanja procesa razvoja modernih sustava.

Literatura:

1 My favourite leadership quote, http://www.manager-tools.com/2006/04/my-favorite-leadership-quote

2 Managing humans, Micahel Lopp, Apress publishing 2007

3 The Mythical Man-Month, Frederick P. Brooks, Addison-Wesley Professional, 1995

4 Extreme programming explained, Kent Beck, Addison-Wesley Professional, 2004

5 Rapid Development, Steve McConnell, Microsoft Press, 1996

Podaci o autoru:

Nikola Stjelja Senior Software Engineer Novatec New Technologies Labin; Buonarrotijeva 20, 51000 Pula E-mail: [email protected] Zaposlen sam kao senior softver inženjer u tvrtci Novatec New Technologies, gdje radim već tri godine. Od početaka radim kao technical lead na isključivo agilnim projektima razvijanim u PHP i .NET tehnologijama. Radio sam na malim projektima sa timovima veličine od dvije do sedam osoba, te imam podjednako iskustva sa kolociranim i distribuiranim timovima. Pišem blog http://mylifeasadeveloper.blogspot.com/ o svom profesionalnom životu, te slobodno vrijeme dijelim izmeñu učenja novih tehnologija i svoje obitelji. Veliki sam pobornik uporabe softverskog inženjerstva na razvoj programskih rješenja i sustava, od jasnog definiranja razvojnog procesa, dizajna i arhitekture do kvalitetne primjene rješenja i njegovog automatskog testiranja. Bavio sam se inženjerstvom zahtjeva, dizajnom softverske arhitekture i detaljnog dizajna na sva tri temeljna layera poslovnih aplikacija: korisničkom sučelju, poslovnoj logici i podatkovnom sloju, te voñenjem malih timova na razvoju komercijalnih i e-goverment sustava. Izdvajam nekoliko projekata iz moje karijere: 1. Registar poljoprivrednih gospodarstava Bosne i Hercegovine; 2. E-Grad – projekt informatizacije gradske Uprave grada Labina; 3. eCustomer – sustav za on-line prodaju čelika;


4. MET Reports – intranet reporting sustav; 5. Ad Sales System – sustav za prodaju oglasnog prostora; 6. Booking System – ERP sustav za praćenje i on-line prodaju turističkih smještaja na razini jadranske regije.


DA LI ODABRATI HTML5 ILI SILVERLIGHT ILI FLASH ZA W EB, MOBILE I DESKTOP?

WHICH TECHNOLOGY, HTML5 OR SILVERLIGHT OR FLASH YOU WILL CHOOSE FOR WEB, MOBILE AND DESKTOP APPLICATION DEVELOPMENT?

Dobriša Adamec, mag. ing. el.Tomislav Bronzin

SAŽETAK:

U 11. mjesecu 2010 na najvećoj Microsoft konferenciji za razvojne inženjere PDC2010 (Professional Developers Conference) Bob Muglia, President of the Server and Tools Division at Microsoft je nespretno izjavio da je tehnologija Silverlight namijenjena za klijentske aplikacija, a HTML5 za web aplikacije, što je izazvalo (i još izaziva) veliku reakciju i diskusije (http://timheuer.com/blog/archive/2010/11/01/silverlight-is-dead-long-live-silverlight.aspx).

Postavlja se pitanje: Ako danas želimo razvijati aplikacije za „tri ekrana“ (stolna računala, mobilni ureñaji, televizija) koju tehnologiju odabrati, te ovisno o tome, kakva se postiže produktivnost u izradi aplikacija?

Ovaj rad objašnjava prednosti i nedostatke svake pojedine tehnologije, te daje smjernice kada upotrijebiti koju od navedenih tehnologija.

Ključne riječi: Silverlight, HTML5, Flash, tri ekrana

ABSTRACT:

In November 2010, at the Microsoft Professional Developers Conference (PDC2010), Bob Muglia, President of the Server and Tools Division at Microsoft, has awkwardly said that Silverlight technology is only for smart client applications, while HTML5 is for browser based/web applications. This statement has induced (and still does) a lot of reactions and discussions (http://timheuer.com/blog/archive/2010/11/01/silverlight-is-dead-long-live-silverlight.aspx).

One can ask him/herself: If we want today to develop applications for "three screens" (desktops, mobile devices and TV sets) which technology we need to choose? Depending on technology, what will be productivity of application development?

This paper explains the advantages and disadvantages of each technology, and provides guidance on when to use which of these technologies.

Keywords: Silverlight, HTML5, Flash, three screens

1. UVOD

Razvoj računalnih aplikacija nikad nije bio interesantniji ali i zahtjevniji nego danas. Sve zahtjevniji korisnici traže da mogu koristiti aplikacije na različitim platformama: od stolnog računala, preko mobilnih ureñaja do televizijskih ureñaja spojenih na Internet. Uz navedeni zahtjev, traži se da korisnička sučelja budu sve bogatija, da omogućavaju komunikaciju u realnom vremenu, uključivši da podržavaju multimediju i prijenos glasa i slike u realnom vremenu.

S druge strane, postoji zahtjev sa strane naručitelja takvih rješenja da budu čim jeftinija i da se mogu izgraditi u vrlo kratkom roku i da ih se kasnije, kada budu implementirana, može lako i brzo mijenjati.

Odmah je vidljivo da su gore navedeni zahtjevi, s jedne strane bogatstvo ureñaja i funkcionalnosti, a s druge strane ograničeni budžeti i kratko vrijeme izgradnje/održavanja suprotstavljeni jedni drugima. Kako riješiti taj sukob? Jedan od načina je i odabir tehnologije koja najbolje odgovara pojedinačnom poslovnom zahtjevu, te korištenjem inženjerskog pristupa koji ne nudi najbolja ili najbrža rješenja, nego daje optimalna rješenja.

U ovom radu biti će prikazane prednosti i nedostatci svake od tehnologija: HTML5, Silverlight1 i Flash kroz razmatranje nekoliko standardnih poslovnih zahtjeva, te dati ocjena o razini produktivnosti koju je moguće postići odabirom neke od njih.

2. ODABIR JEDNOG OD „EKRANA“ ILI RAZVOJ ZA SVE NJIH (WEB, MOBILE, DESKTOP)

Iako se danas sve češće javljaju zahtjevi da aplikacije moraju raditi na sva „3 ekrana“, u nekim slučajevima ipak i dalje se traži samo mogućnost rada na jednom od njih.

Tako npr. ukoliko govorimo o aplikacijama koje bi trebale biti dostupne kroz web pretražnik (web browser), onda možemo odabrati bilo koju od navedenih tehnologija, no s različitim stupnjem zadovoljstva korisnika, brzine razvoja aplikacija i ažuriranja novih verzija, mogućnosti rada on-line i off-line, količina vremena potrebna za naučiti tehnologiju, da li su standard za korištenje, kakva je podrška od strane proizvoñača i zajednice ako doñe do nekog problema, kakva je stabilnost i kvaliteta platforme, te da li je sigurna za korištenje i na kraju, koje

1 Više o Silverlightu: http://en.wikipedia.org/wiki/Silverlight, http://www.microsoft.com/silverlight


od platformi i na kakav način podržavaju (interoperabilnost).

U nastavku rada, slijede usporedbe i opisi primjene pojedine od tehnologija prema gore navedenim kategorijama, bez ambicije da se opišu sve mogućnosti svake od pojedinih tehnologija

3. MOGUĆNOST IZRADE BOGATOG KORISNIČKOG SUČELJA

Tehnologije Flash i Silverlight su ovdje u maloj prednosti ispred HTML5, ne zato što sa HTML5 nije moguće napraviti iste ili slične stvari, nego iz razloga što za Flash i Silverlight već postoje odlični razvojni alati i veliki broj proizvoñača komponenti za izgradnju korisničkog sučelja, kako od proizvoñača tih tehnologija, tako i od drugih neovisnih („3rd party“) proizvoñača. S druge strane, sve tri tehnologije nude velike mogućnosti proširenja i stvaranja novih komponenti za izgradnju bogatog korisničkog sučelja, ali i dalje starija braća Flash i Silverlight imaju više sazrele alate za taj posao.

Podrška za multimediju postoji u sve tri tehnologije, no ono što je bitno za spomenuti, da se kod Silverlight-a osobita pažnja posvećuje tzv. upravljanju pravima korištenja digitalnih sadržaja (Digital Rights Management – DRM), što je ključno za ponuditelje multimedijalnih sadržaja. Uz DRM, vrlo je važna i podrška za hardversku akceleraciju, odnosno ubrzanje prikaza animacija i video sadržaja. Tu je već situacija više izbalansirana izmeñu sve 3 tehnologije, budući niti jedna ne nudi akceleraciju na svim platformama. Tako npr., na Windows baziranim stolnim računalima i Silverlight i HTML5 (kroz Internet Explorer 9 i Firefox 4.x) imaju podržanu hardversku akceleraciju (video, 2D/3D grafika), a postoje najave i za Flash 10.x koji je trenutno u beta fazi razvoja.

4. BRZINA RAZVOJA APLIKACIJA I AŽURIRANJE NOVIH VERZIJA

Ako poñemo od slučaja kada su svi članovi razvojnog tima već upoznati s tehnologijom i posjeduju odreñeno iskustvo u radu s istom (više o količini vremena potrebnoj da bi se naučilo novu tehnologiju u slijedećem odlomku), onda ponovo moramo staviti naglasak na dostupnim razvojnim alatima i komponentama za izgradnju aplikacija, gdje su Flash i Silverlight u značajnoj prednosti u odnosu na HTML5. Dodatno, sastavni dio svakog razvoja aplikacija je i testiranje, gdje opet Flash i Silverlight briljiraju zbog dobro razvijene prakse i alata.

S druge strane, trebamo razmotriti i brzinu implementacije novih mogućnosti samih platformi (HTML5, Silverlight i Flash) na samim klijentima: tu prednost imaju Flash i Silverlight zbog toga što su implementirani kroz plug-in-ove web pretražnika te tako ne ovise o učestalosti njihovog ažuriranja, već se na jednostavni način ažurira samo plug-in.

Brzina ažuriranja novih verzija jako ovisi o ciljanom „ekranu“: � ako se radi o aplikacijama za web pretražnike –

onda sve tri tehnologije nude brzo i centralizirano ažuriranje, uz prethodno ispunjen uvjet da ciljani klijent (pretražnik ili plug-in!) podržava sve funkcionalnosti koje se kroz ažuriranje nude

� ako se radi o aplikacijama za mobilne ureñaje – onda je situacija malo drugačija (dobro je pogledati i poglavlje o podržanim platformama): ne podržavaju sve platforme sve tehnologije (premda se najavljuje

npr. za HTML5 da će biti podržan), a Flash je „zabranjen“ na Apple proizvodima. Osim toga, čak ako je tehnologija podržana – neki puta nisu sve funkcionalnosti. Dakle, ako je tehnologija (i podržana i podržava sve potrebne funkcionalnosti) – onda se centralno ažurira aplikacija na web mjestu, a mobilni ureñaj se spaja na to web mjesto i preuzima novu verziju aplikacije

� ako se radi o aplikacijama za stolna računala – ponovo specifičnost: Flash (odnosno njegov derivat Air) i Silverlight omogućavaju funkcionalnost aplikacija „izvan“ web pretražnika, a HTML5 – zahtjeva (po svojoj prirodi) web pretražnik. Ponovo je moguće automatski s centralnog mjesta ažurirati aplikacije.

Dodatno i kod razmatranja brzine razvoja aplikacija i njihovog ažuriranja, treba uzeti jednu važnu komponentu u obzir – vizualni grafički i „dinamički“ dizajn. Pod dinamički dizajn se podrazumijeva implementacija aktivnog (dinamičkog) sadržaja poput animacija, kontrola tranzicija izmeñu ekrana/stranica i implementacija video sadržaja. Tu Flash i Silverlight još uvijek imaju prevagu, budući su razvojni alati odlično integrirani s dizajnerskim alatima, gdje (osobito Flash) ima podršku najpopularnijih dizajnerskih alata poput Adobe proizvoda.

5. KOLIKO JE KOLI ČINA VREMENA POTREBNA DA BI SE NAU ČILO TEHNOLOGIJU?

Ovdje moramo razlikovati dvije situacije: a) svi članovi razvojnog tima već upoznati s

tehnologijom i posjeduju odreñeno iskustvo, b) moramo sve ili neke članova razvojnog tima naučiti

da koriste tehnologiju

Osim gore navedenog, brzina učenja ovisi i o prethodnom iskustvu članova tima. Pa tako dodatno razlikujemo za slučaj b) podslučajeve: 1 postoji predznanje u nekoj sličnoj tehnologiji 2 ne postoji predznanje

Ako se osvrnemo na slučaj kada ne postoji predznanje i postoji potreba za učenjem članova tima, onda Flash i Silverlight imaju prednost – budući postoji velika količina dostupnih materijala (knjige, video sadržaji, treninzi, blogovi, forumi, „kuharice“ s primjerima itd.) te homogena zajednica razvojnih inženjera koja (u većini slučajeva) može dati pouzdan i brz odgovor, pa sve do podrške samih proizvoñača tehnologija Flash i Silverlight. Budući je HTML5 u javnom vlasništvu, ta podrška je trenutačno nešto manja, ali se predviña da će s vremenom rasti.

Brzinu učenja u tzv. najgorem mogućem scenariju je teško predvidjeti, sve ovisi o afinitetima članova tima, no kada govorimo o slučaju da postoji stanovito predznanje onda svakako ono utječe na brzinu učenja. Npr. ako se radi o razvojnim inženjerima koji imaju iskustva u radu s Visual Studio razvojnim alatom za npr. pametne klijente – onda je njima „logičan“ i lakši prijelaz na Silverlight – budući se koristi isti programski jezik (C#/VB) i vrlo slično .NET programsko sučelje (API). Naravno, ako se radi o razvojnim inženjerima koji su puno radili s HTML4, CSS itd., onda je logično da će učenje biti brže ako odaberu HTML5 tehnologiju.


6. PODRŠKA OD STRANE PROIZVOðAČA I ZAJEDNICE AKO DO ðE DO NEKOG PROBLEMA

Kao što je već navedeno, Flash i Silverlight imaju odličnu podršku njihovih proizvoñača, veliki skup dobro razrañenog edukacijskog materijala i, što nije zanemarivo, veliku podršku zajednice korisnika – razvojnih inženjera. Dobar dio te podrške i edukacijskog materijala je besplatan, a vrlo veliki dio jako konkurentan – budući postoji velika korisnička baza i s vremenom se oformila relativno velika grupa stručnjaka s znanjem i iskustvom koji to svoje znanje dijele s ostalima, bilo on-line, bilo kroz predavanja na konferencijama i korisničkim grupama (User Groups2). Potonje omogućava ne samo mogućnost za učenje i postavljanje pitanja, nego i aktivno sudjelovanje s vlastitim doprinosom – npr. držanjem predavanja o nekoj temi, te kasnijom mogućnosti diskusije o tzv. dobroj praksi, koja se neki puta razlikuje o same teorije.

7. MOGUĆNOSTI RADA ON-LINE I OFF-LINE

Kada gledamo sva tri načina korištenja aplikacija: web, mobile i desktop, onda samo uvjetno možemo reći da aplikacije koje se izvršavaju u web pretražnicima mogu raditi i off-line, budući obično je u njihovoj prirodi da komuniciraju s vanjskim svijetom, a kada nema veze, nema niti komunikacije.

Gledajući svaku pojedinačnu tehnologiju, možemo zaključiti da sve tehnologije u većoj ili manjoj mjeri podržavaju off-line rad i to Silverlight na najbolji mogući način – koristeći sve mogućnosti operativnog sustava, uključivši i hardversku akceleraciju i pristup lokalnim ureñajima, te spremanju podataka, Flash skoro tako dobro kao Silverlight u svim aspektima, a HTML53 - ovisno o implementaciji u web pretražniku – negdje odlično (kao na iPhone-u) a negdje slabije – primjer su neki web pretražnici na stolnim računalima.

Zajedničko svima trima tehnologijama je to da obično se instaliraju na računalo/ureñaj putem web pretraživača.

8. PITANJE STANDARDA

Ako želimo biti vrlo precizni – niti jedna tehnologija nije standard, barem ne u onom strogo gledajućem smislu. HTML5 je standard u nastajanju i u javnom je vlasništvu, no poučeni činjenicom da niti HTML4 koji je prisutan više od 10 godina nije do kraja standardiziran, teško je prognozirati kada će definiranje HTML5 kao standarda završiti.

S druge strane Flash i Silverlight su tehnologije na kojima imaju vlasništvo njihovi proizvoñači, tako da teško mogu biti standardi, osim ako se proizvoñači ne odreknu tog vlasništva. No, čak i tada, Flash je jako loši kandidat, dok Silverlight je malo bolji iz razloga što koristi već postojeće standarde kao XML – kroz XAML (eXtensible Application Markup Language), no sam XAML se

2 Što su to I kako nastale korisničke grupe: http://en.wikipedia.org/wiki/Users%27_group, primjer korisničkih grupa u Hrvatskoj: http://www.mscommunity.hr, Microsoftovo objašnjenje pojma “User Group” i primjeri grupa: http://www.microsoft.com/communities/usergroups/default.mspx 3 Primjer izrade HTML5 off-line aplikacije za iPhone: http://sixrevisions.com/web-development/html5-iphone-app/

razlikuje od SVG standarda (Scalable Vector Graphics) koji se inače koristi za sličnu svrhu.

9. STABILNOST I KVALITETA PLATFORME

Flash i Silverlight su vrlo stabilne i kvalitetne platforme dok HTML5 je tek standard u nastajanju i kvaliteta njegove implementacije prvenstveno ovisi o proizvoñaču web pretražnika.

10. PODRŽANE PLATFORME I INTEROPERABILNOST.

Ovisno o tehnologiji, podržane su slijedeće platforme:

Flash � Web – podržan je od velikog broja web pretražnika

(kako za stolna računala, tako i za mobilne ureñaje), stabilno radi s istim brojem funkcionalnosti, no neki puta s različitim performansama.

� Mobile - podržan je na velikom broju mobilnih ureñaja (većinom na Android platformi), no nažalost ne na svima – npr. na popularnim Apple proizvodima iPhone, iPod i iPad, te na Microsoft Windows Phone 7. Za potonji je Microsoft obećao podršku, dok je Apple stajališta da Flash troši previše resursa i da treba podržati HTML5 tehnologiju. U najavi za kraj 2011 godine je varijanta koja omogućava da se Flash pre-kompilira za iOS API i tako izvršava

� Desktop – u kombinaciji Adobe Flash/AIR radi i van web pretražnika kao samostojeća aplikacija. Najavljena je i podrška za Apple iOS, no kroz prevoñenje u izvorni iOS API

Silverlight � Web – podržan je u Internet Explorer i Firefox 3+, te

na Safari 3+ (Macintosh) i Chrome 4+ platformi. Na Linux platformi je podržan kroz projekt Mono/Moonlight4 i instalira se kao Firefox/Chrome plug-in (SUSE Linux ED, openSUSE, Ubuntu/Fedora)

� Mobile –ima podršku (isključivo) na Windows Phone 7 ureñajima (i zadnjoj generaciji Windows Mobile), no za sada samo u obliku samostojeće aplikacije, nije podržan u web pretražniku – za što je implementacija obećana uskoro. Silverlight je (djelomično) podržan i na najjačim modelima mobilnih ureñaja na Symbian platformi

� Desktop – ima podršku za rad i izvan web pretražnika kao samostojeća aplikacija

HTML5 � Web– podržan je od velikog broja web pretražnika5

(kako za stolna računala, tako i za mobilne ureñaje), no pati od „problema“ standarda i javnog vlasništva, što znači da nije jednako implementiran unutar svih web pretražnika6

� Mobile – uvijek se izvršava unutar web pretražnika, podržavaju ga u nekom obliku svi web pretraživači, osobito dobro podržan na Apple iPhone/iPad/iPod

4 Više o projektu Mono/Moonlight: http://www.mono-project.com/Moonlight 5 Testirati web pretražnik što od mogućnosti HTML5 podržava se može ovdje: http://html5test.com/ 6 Pomoć u snalaženju oko informacija što je i na kojoj platformi podržano može pružiti web mjesto: http://www.hagenburger.net/BLOG/4-useful-HTML5-browser-support-overviews.html


ureñajima i Android baziranim, a uskoro će biti podržan i na Windows Phone 7

� Desktop – nema podršku za rad izvan web pretražnika, čak kada i radi off-line

11. SEARCH ENGINE OPTIMIZATION (SEO)

Jedno važno pitanje kada se govori o platformama je i podrška za Search Engine Optimization (SEO). Tu definitivno prevagu odnosi HTML5, a Silverlight zauzima drugo mjesto jer koristi standardni način zapisa izgleda ekrana – XML, HTML i tekst, a jako loše stoji Flash jer se aplikacija i podaci nalaze u specifičnom, nestandardnom binarnom formatu.

12. ZAKLJU ČAK

Kao što je naš stvarni svijet lijep zbog svoje raznolikosti, tako i bogatstvo tehnologija koje su nam na raspolaganju za izgradnju računalnih aplikacija koje zadovoljavaju: s jedne strane zahtjevne korisnike i prilagoñavaju se raznim platformama, a s druge strane zahtjeve naručitelja da rješenja budu čim jeftinija i da se mogu

izgraditi u vrlo kratkom roku i da ih se kasnije, kada budu implementirana, može lako i brzo mijenjati.

Ako se baš mora na neki način napraviti diferencijacija, odnosno gdje je koja tehnologija više primjenjiva od druge, onda generalno možemo reći da: � aplikacije koje se izvršavaju u web pretražniku i

moraju podržavati različite platforme (ureñaje) najbolje rješenje je HTML5

� ako se radi o „native“ aplikacijama za mobilne ureñaje – onda Silverlight nosi pobjedu na Windows Phone 7 i Symbian platformi, a Flash (u budućnosti) na iOS platformama, dok HTML5 podrška za off-line rad puno obećaje na iOS i Android platformi

� ako se radi o samostojećim aplikacijama za stolna računala – onda (ovisno o platformi) Flash i Silverlight odnose pobjedu

Ili još kraće: za poslovne aplikacije i one koje zahtijevaju složeniji unos i rad izvan web pretražnika – izbor pada na Flash i Silverlight. Za one aplikacije koje računaju na vrlo široku publiku koji će joj pristupati s raznim ureñajima, bolje rješenje je HTML5.

Literatura: 7

1 Dobriša Adamec , Vedran Kaldi, Tomislav Bronzin: „Izrada bogatih Internet aplikacija (RIA) – MS Silverlight 4 & RIA Services.“, CASE21 & CASE22, 2009/2010

2 Više o Silverlightu: http://en.wikipedia.org/wiki/Silverlight, http://www.microsoft.com/silverlight

3 Ostatak – u podnožjima na stranicama rada

Podaci o autorima:

Tomislav Bronzin, mag. ing. el., Microsoft Regional Director & MVP Tomislav Bronzin, mag. ing. el. je osnivač tvrtke CITUS, Microsoft Gold Certified partnera, čija je glavna djelatnost proizvodnja programskih rješenja i savjetovanje za razvoj aplikacija na Microsoft platformi. Autor je dva patenta s područja ICT-a registriranih u Hrvatskoj agenciji za intelektualno vlasništvo. Bio je uključen u projektiranje i implementaciju prvih nekoliko velikih mobilnih rješenja na Microsoftovoj platformi, uključivši one za Hrvatske šume i Hrvatske željeznice. Tomislav je nositelj počasnih titula Microsoft Regional Director, Microsoft MVP, te Microsoft Certified Trainer. Redovni je predavač na velikim Microsoftovim konferencijama u široj regiji, Microsoft TechEd Europe ili domaće WinDays i Mobility Day. Sudjelovao je kao predavač na akademskim konferencijama koje organizira Ministarstvo znanosti obrazovanja i športa, predaje studentima na Visokoj školi za primijenjeno računarstvo u Zagrebu, a kao pozvani predavač predavao je na FOI-u i FER-u, bio je mentor timovima studenata na natjecanju Microsoft Imagine Cup. Uz navedeno, Tomislav je

7 Članak: HTML5, Flash & Silverlight: Differing Goals http://gophercg.wordpress.com/2010/11/26/html5-flash-silverlight-differing-goals/

Slika 1. Brzina izvršavanja aplikacija na pojedinoj tehnologiji Flash, Silverlight, HTML57


potpredsjednik Udruženja za IT pri HGK, predsjednik je Hrvatskog udruženja programera, suosnivač je http://www.mscommunity.net portala, te je član upravnog odbora INETA Europe. Tomislav Bronzin is Senior Advisor in CITUS, Microsoft Gold Certified Partner Company for Solution Development and Consulting for Application Lifecycle Management. He is owner of two ICT based patents which was used in first two large Mobile Solutions on Microsoft platform developed for Croatian Forests and Croatian Railways. Tomislav has more than 18 years of real-life experience with Microsoft technologies with current interest in development of distributed applications based on .NET Smart Client and Mobile Devices technology, resulting in having 2 patents in those areas as well in Microsoft Unified Communication Development. He is teaching students at University College for Applied Computer Engineering in Zagreb and he is often invited to speak at Faculty of Electrical Engineering and Computing (FER) and Faculty of Organization and Informatics. Tomislav has been a regular speaker at Microsoft conferences in the region, as well as at several academic conferences and he was speaker at Microsoft TechEd Europe. He is INETA Europe Vice President, Croatian Chamber of Economy - IT Association Vice President, President of the Croatian Association of Computer Programmers and co-founder of http://www.mscommunity.net. Tomislav has honorable titles: Microsoft Regional Director and Most Valuable Professional – Solution Architect.

Dobriša Adamec, ing., Microsoft Most Valuable Profess ional (MVP) Dobriša Adamec, ing. je Solution Architect u tvrtki Citus, Microsoft Gold Certified partneru, gdje radi na razvoju i uspostavi servisno orijentiranih aplikacija. Višegodišnje iskustvo razvojnog inženjera i rada na izradi web aplikacija služi mu kao temelj današnjoj specijalizaciji: .NET platforma, XML i prateći otvoreni standardi te interoperabilnost aplikacija. Uz to što nove tehnologije koristi u svakodnevnom radu znanja o njima prenosi studentima Tehničkog Veleučilišta u Zagrebu gdje radi kao asistent na kolegijima "Uvod u XML programiranje" i "XML programiranje (web servisi)". Kao jedan od najaktivnijih članova Hrvatskog udruženja programera i SQL/Developers zajednice izabran je za člana upravnog odbora INETA Europe, a supruga i dva sina mu progledaju kroz prste kada dio slobodnog vremena potroši na rad mscommunity.net web portala. Zalaganje u zajednici pridonijelo je dobivanju Microsoft MVP statusa za područje ASP.NET. Dobrisa Adamec is Solution Architect in CITUS (Croatia, Zagreb), Microsoft Gold Certified Partner Company for Solution Development and Consulting for Application Lifecycle Management. He has being working on different projects for building service oriented applications. Dobrisa has years of experience in writing code, deploying long living applications, setting and walking up projects and building a development teams. This led to his today’s specializations: .NET Framework, Web Services and interoperability. He is exploring new technologies (WCF, WWF etc.) and teaching students at Zagreb Polytechnic (Tehnicko Veleucilste Zagreb) where he lectures in courses “XML programming - introduction” and “XML programming – Web Services”. As active member of Croatian Association of Computer Programmers (HUPRO) and SQL/Developers community, Dobrisa become the INETA Europe Vice President. His wife and two sons let him spend some free time on maintaining www.mscommunity.net portal. He is proud owner of Microsoft Most Valuable Professional for ASP.NET award. CITUS d.o.o.

S oba autora se može stupiti u kontakt slanjem e-maila na: [email protected] ili telefon: +385 1 3667-120


EVALUACIJA I KOMPARATIVNA ANALIZA O/RM ALATA

COMPARATIVE ANALYSIS AND EVALUATION OF OBJECTRELATIONALMAPPING TOOLS

Ivan Renduli ć

SAŽETAK:

U zadnjih nekoliko godina proizvoñači alata programske podrške pokazuju značajan interes za područje O/R preslikavanja. Kompleksne funkcije sloja pristupa podacima mogu biti inkapsulirane u komponente, što rezultira pojednostavljenom i jeftinijom izradom aplikacija. Alati omogućavaju različite funkcije kako za aplikacije tipa produkta tako i za klasične enterprise aplikacije. S obzirom na mnoštvo alata u ponudi evaluirali smo vodeće komercijalne alate na Microsoft platformi.

ABSTRACT:

It will be shown most used commercial ORM tools, their functions and comparative analysis of the same. Brief historical overview of the origin and development of the ORM tools will bi given and also their function in different types of applications will be analyzed.

1. UVOD

Da bi objasnili koja je geneza problema O/R preslikavanja važno je pogledati u prošlost zadnjih 30 godina. Kao što je objasnio [1] početkom devedesetih, postoji podjela na dvije zajednice: razvojne inženjere i administratore baza podataka. Svaka zajednica ima svoje metodologije i filozofije rada. Dok su se razvojni inženjeri okrenuli objektno-orijentiranim metodologijama, administratori baza podataka zadržali su tradicionalniji način stvaranja modela podataka i dizajna baza podataka. Kako te dvije grupe ljudi moraju surañivati na zajedničkim projektima postavlja se pitanje: kako združiti rezultate ovih dviju metodologija, ili kako preslikati modele objektno-orijentirane analize u modele prikladne za pohranu podataka, tzv. relacijske modele.

2. KONCEPTI OBJEKTNOG MODELA

Objektni model je iz temelja drugačiji od modela tradicionalnijih metoda strukturirane analize, strukturiranog dizajna i strukturiranog programiranja [2]. To znači da objektni model napušta sve dokazane principe tih starijih metoda. Objektni model sastoji se od tri glavna koncepta: � Apstrakcija (apstrakcija podataka) � Enkapsulacija � Hijerarhija

Apstrakcija je temeljeni način kako se ljudi nose sa kompleksnošću. Shaw je definirao apstrakciju kao “pojednostavljen opis, ili specifikacija, sistema koji naglašava neke dijelove sistema potiskujući druge dijelove.

Apstrakcija i enkapsulacija su komplementarni koncepti: apstrakcija je fokusirana na vidljivo ponašanje objekta, dok je enkapsulacija usmjerena na implementaciju koja rezultira tim ponašanjem. Enkapsulacija je najčešće postignuta skrivanjem informacija, što je proces skrivanja detalja objekta koji ne doprinose osnovnim karakteristikama, tipično struktura objekta je skrivena kao i implementacija njegovih metoda.

Skup apstrakcija često formira hijerarhiju. Prepoznajući hijerarhije u procesu dizajna, pojednostavljujemo razumijevanje problema. Hijerarhiju možemo definirati kao: rangiranje ili poredak apstrakcija.

3. KONCEPTI RELACIJSKOG MODELA

Relacijski model je model baze podataka baziran na predikatnoj logici prvog reda. Prvi ga je opisao i predložio 1969. E.F.Codd [3]. Osnovna ideja je opisati bazu podataka kako skup predikata nad konačnim skupom predikatnih varijabli. Relacijski model se sastoji od niza koncepata: � Kolone ili polja � N-torke ili redci � Relacije ili tablice � Primarni ključ � Strani ključ

Kolone ili polja u tablici opisuju atribute kao što su ime, godina roñenja i dr.

N-torka ili redak sadrži sve podatke jedne instance tablice kao što je osoba Hrvoje.

Relacija je tablična struktura (skup kolona) skupa sa podacima koji se u njoj čuvaju.

U relacijskom modelu svaka n-torka mora imati jedinstvenu identifikaciju ili ključ koji je baziran na podacima, zvan primarni klju č.

Relacijski model takoñer uključuje koncept stranog klju ča, to je primarni ključ u jednoj relaciji koji prisutan u drugoj relaciji i omogućuje spajanje podataka.

4. PROCES PRESLIKAVANJA

Nastavljajući se na definicije iz prethodna dva poglavlja postavlja se pitanje: koji elementi modela


mogu biti preslikani? Apstrakcije objektnog modela su najčešće prikazane kao dijagram klasa kao što pokazuje Slika 1 :

Dijagram klasa se sastoji od klasa koje imaju svoje atribute i povezane su vezama; asocijacijama, generalizacijama. Asocijacija definira postojanje korelacije izmeñu dvije klase. Generalizacija definira da je jedna klasa naslijeñena od druge. Specijalni tip asocijacije se naziva agregacija (Račun<->Stavka računa) i definira egzistencijalnu ovisnost izmeñu objekata jedne klase nad objektima druge klase.

Pod uvjetom da su sve klase perzistentne tj. da su pohranjene u bazi podatka možemo definirati preslikavanje sljedećih elemenata: � Klase u tablice � Atribute u kolone � Asocijacije u relacije � Preslikavanje hijerarhija

4.1 Klase u tablice

Perzistentne klase se preslikavaju u tablice. Pretpostavljeno preslikavanje je 1:1 što znači da je jedna klasa preslikana u jednu tablicu. Druga preslikavanja su moguća – kada jedna klasa, zbog optimizacije, je preslikana u više tablica. Slika 2. pokazuje kako se klase iz prethodnog primjera preslikavaju u tablice:

4.2 Atribute u kolone

Atributi perzistentne klase se preslikavaju u kolone. Tijekom procesa preslikavanja mora se voditi obzira o tipovima podataka.

4.3 Asocijacije u relacije

U prikazanom dijagramu klasa, svaka asocijacija je na neki način transformirana. Kako u relacijskoj bazi postoji samo 1:N kardinalnosti veze a u dijagramu klasa su moguće 1:N,1:1 i N:N, 1:1 i N:N kardinalnosti moraju na neki način biti označene:

� 1:1 – koristeći ograničenja realizirana kao okidači ili pohranjene procedure

� N:N – koristeći meñu-tablicu

Dodatno specijalni tip asocijacije, agregacija je preslikana na isti način kao i asocijacija sa postavljenim kaskadnim operacijama na stranom ključu.

4.4 Preslikavanje hijerarhija

Koncept nasljeñivanja predstavlja zanimljiv problem kada je riječ o preslikavanju. Više je načina na koje možemo riješiti taj problem:

Prvi na čin bi bio preslikavanje kompletne hijerarhije u jednu tablicu koja bi objedinjavala sve atribute svih klasa iz hijerarhije.

Drugi i najčešći način je preslikavanje svake klase u posebnu tablicu.


Treći način je kreiranje posebnog relacijskog meta modela koji bi bio pohranjen za svaku hijerarhiju pojedinačno.

5. ORM U KONTEKSTU ARHITEKTURE APLIKACIJA

U višeslojnoj arhitekturi funkcija O/R preslikavanja na neki način mora biti implementirana. Sloj pristupa podacima (Data Access Layer) je najvažniji sloj kada govorimo o O/R preslikavanju. Glavna svrha ovog sloja je omogućavanje sloju poslovne logike (Business Layer) da pohranjuje podatke u bazu podatka kao i njihov dohvat iz baze.

Glavni servisi koje sloj pristupa podacima omogućava: � CRUD servisi – elementarne operacija umetanja,

čitanja, promjene i brisanja podataka � Query servisi – mogućnost postavljanja upita za

podacima � Upravljanje transakcijama – mogućnost

izvršavanja transakcija � Konkurentnost – konkurentnost promjene

podataka


Izrada unikatnog sloja pristupa podacima je težak posao i danas se najčešće prepušta O/RM alatima koji već imaju implementirane gore navedene servise.

Objektno orijentirani sistemi za upravljanje bazama podataka (ODBMS) nisu postigli raširenost kao relacijski (RDMS) najviše zbog nepodržavanja SQL-a kao standarda za dohvat podataka. O/RM alati postižu ODBMS funkcionalnost nad RDMS. Jedna od osnovnih karakteristika O/RM alata je njihova neovisnost o konkretnom RDMBS-u. NA taj način omogućavaju aplikacijama pisanim pomoću njih da jednostavno promjene RDBMS bez promjene u izvornom kodu aplikacije.

6. KARAKTERISTIKE O/RM ALATA

Različiti alati imaju različite karakteristike a neku su i zajedničke. Alati [6],[7],[8],[9] posjeduju sljedeće karakteristike:

Konfiguracijski alata

Sa većinom alata dolazi specijalni alata koji pomaže prilikom konfiguriranja preslikavanja. Najčešće je integriran u razvojnu okolinu.

Konfiguriranje preslikavanja korištenjem atributa ( Code First )

Za razliku od konfiguriranja preslikavanja posebnim alatom ova karakteristika omogućava definiranje preslikavanja korištenjem atributa.

Generator koda

Kao rezultat preslikavanja je generirani kod.

Entity Collection klasa

Generira se strongly-typed kolekcija. Karakteristika alata sa generatorom koda.

Self servicing Entity

Klase imaju CRUD operacije kao metode, kao što je object. Save ().

Adapter Entity

Klase nemaju CRUD operacije kao metode nego koriste posebnu (adapter) klasu npr. adapter. Save (object).

Preslikavanje naslje ñivanja

Mogućnost preslikavanja hijerarhija klasa.

POCO objects

Plain Old CLR Objects je poželjna osobina koja omogućuje klasama da ne budu naslijeñene iz neke klase koje odreñuje O/RM alata. Korištenje ovakvih klasa omogućava kreiranje bilo kakve hijerarhije neovisno o realizaciji O/RM alata.

Lazy Loading

Ova karakteristika omogućava osobinama objekata da ne budu dohvaćene iz baze podatka zajedno sa objektom nego samo onda kada su potrebne. Ovakav način dodatno optimizira dohvaćanje grafa objekata.

Fetch Plans

Data fetch plans omogućavaju fini podešavanje načina dohvata podataka iz baze podataka. Definiranje istih omogućava dodatno optimiziranje dohvata podataka.

Jezik za upite

Podrška za poseban jezik za upite koji je za razliku od SQL, baziran na objektima. Rezultat izvršavanja je graf objekata a ne skup zapisa kao kod SQL upita.

Podrška za LINQ

Mogućnost izvršavanja LINQ upita omogućavajući type-safe upite integrirane u programski jezik.

Neovisnost o bazi podataka

Omogućuju da aplikacije, kada se ukaže potreba, promjene RDBMS bez promjene u izvornom kodu aplikacije.

DevExpress XPO

Microsoft Entity Framework

Telerik Open Access

Solutions Design LLBL Pro

Konfiguracijski alat Ne Da Ne Da

Konfiguriranje preslikavanja pomoću atributa (Code First) Da Da Ne Ne

Integracija sa Visual Studio 2010 Ne Da Da Ne

Generator koda Ne Da Da Da

Entity Collection class Ne Da Da Da

Self servicing Entity Da Ne Da Da

Adapter Entity Ne Da Ne Da

Preslikavanje nasljeñivanja Da Da Da Da

POCO objects Ne Da Ne Ne

Lazy Loading Da Ne Da Da

Fetch Plans Ne Da Da Da

Jezik za upite No Da Da Ne

Podrška za LINQ Da Da Da Da

Neovisnost o bazi podataka Da Da/Ne Da Da

Cache Da Da Da Da

Model First Development Da Da Da Da

Schema evolution Da Ne Da Ne

Validatori Ne Ne Da Da

Metadata API Ne Da Da Da


Cache

Keširanje objekata dodatno optimizira njihov dohvat.

Model First Development

Omogućuje kreiranje objektnog modela iz kojega se generira relacijski model

Schema evolution

Omogućava promjene relacijskog modela u vremenu izvršavanja koda. Ovo je jako poželjna osobina koja ubrzava sinkronizaciju baze i objektnog modela.

Validatori

Podrška za validatore u sloju pristupa podacima.

Metadata API

Poseban API za pristup podacima o preslikavanju.

7. ZAKLJU ČAK

Kao što je vidljivo iz komparativne analize postoje dvije skupine alata. Prva skupina kao primarni model ima

podatkovni (relacijski) model dok druga skupina ima za primarni model objektni model. Prva skupina je namijenjena prvenstveno za izradu aplikacija nad postojećim bazama podataka, dok druga skupina predstavlja izbor za izradu aplikacija od početka bez početne baze.

Kao što je opisano u poglavlju 4. proces preslikavanja je nedvosmislen i može se automatizirati. Alati bazirani na objektnom modelu su mnogo napredniji i njihovim korištenjem se stvara dodatna ušteda prilikom kreiranja baze podataka. Neki od njih idu toliko daleko da omogućavaju izmjenu baze u vremenu izvršavanja, što omogućava izradu aplikacija koje same brinu o shemi relacijske baze. Ako je aplikacija locirana na puno lokacija i na svakoj lokaciji po jedna baza tada je to poželjna osobina jer se ne moraju izvršavati skripte za izmjenu baze na svakoj lokaciji. Za enterprise aplikacije gdje je većinom jedna baza izmjena sheme nije problem i može se ručno izmijeniti.

Literatura:

1. http://www.agiledata.org/essays/culturalImpedanceMismatch.html

2. Booch, Grady: Object-oriented analysis and design with applications, ISBN 0-08053-5340-2

3. http://en.wikipedia.org/wiki/Relational_model

4. http://www.agiledata.org/essays/mappingObjects.html

5. Esposito, Saltarello : Microsoft .NET: Architecting Applications for the Enterprise, Microsoft Press 2009

6. www.devexpress.com

7. www.telerik.com

8. msdn.microsoft.com/en-us/library/bb399572.aspx

9. www.llblgen.com

Podaci o autoru:

Ivan Renduli ć Matrica d.o.o. Senjska 125 HR-47303 Josipdol e-mail: [email protected] 1999-2004 Omega Software - ERP systems Architect 2002-2003 MSAN - Business Process Analyst 2003-Present Matrica - CEO and Lead Architect


OPENOBJECT - PLATFORMA ZA RAZVOJ POSLOVNIH APLIKACI JA

OPENOBJECT - A PLATFORM FOR DEVELOPING BUSINESS APPLICATIONS

Goran Cvijanovi ć

SAŽETAK:

OpenObject je modularna, skalabilna, intuitivna platforma za razvoj poslovnih aplikacija na kojoj je izgrañen jedan od vodećih open source ERP sustava - OpenERP. Kompletna paleta alata za brz razvoj modula, obuhvaća podršku za integrirano objektno relacijsko mapiranje, izgradnju prezentacijskog sloja zasnovanog na predlošcima prema MVC standadu, generator izvještaja, podršku za lokalizaciju, upravljanje pravima pristupa, strukture za nadzor nad koracima poslovnih procesa, itd.

Kroz predavanje biti će prikazana organizacija OpenObject platforme i primjena razvojnih mogućnosti kroz arhitekturu modula OpenERP sustava.

ABSTRACT:

OpenObject is a modular, scalable, intuitive framework for developing business applications which is used as platform for one of the leading open source ERP system - OpenERP. A complete range of tools for rapid development of modules, including support for integrated object-relational mapping, building a presentation layer based on the MVC template standards, report generator, support for localization, control access rights, the structure for the control of business process steps, etc.

This presentation will show organization of OpenObject platform and application development possibilities through architecture of the modules of OpenERP system.

1. UVOD

Živimo i radimo u vremenu koje je dinamičnije nego ikada prije, a za očekivati je da će se aktivnosti koje čovjek provodi tijekom jednog dana i dalje ubrzavati. U poslovnom smislu to nam donosi i povećanu dinamiku u meñusobnim komunikacijama, potrebu za što efikasnijim korištenjem resursa u svakom smislu, vremena, ljudskih resursa, tehnologije, a u konačnici i kapitala.

Kako bi to bilo moguće, potrebna su nam sve veća tehnološka unapreñenja. Ureñaji koje koristimo sve su više prožeti softverskim rješenjima koja objedinjuju različite funkcionalnosti, a sve je povezano putem interneta i dostupno u svakom trenutku.

Kakve to izazove stavlja pred tvrtke i stručnjake koji se bave razvojem informacijskih sustava? Razvijati softverske produkte koji bi pokrili realne potrebe modernog poslovanja, zahtijeva poznavanje široke palete platformi i tehnologija. Klasična rješenja koja omogućuju praćenje poslovnih dogañaja i evidenciju podataka unosom istih putem ekranskih formi, više nije dostatno. Danas tvrtka koja nije prisutna na internetu, ne komunicira mnoštvom dostupnih kanala, društvenih mreža, elektroničke pošte, mobilne telefonije, zapravo niti ne postoji ili svakako nije mjerodavna u poslovnom svijetu.

Moderna softverska rješenja moraju moći pratiti poslovnu dinamiku svakodnevnih aktivnosti i prilagoñavati se promjenama smjera kojim upravljaju brze poslovne odluke, nužne da bi se posao prilagodio turbulencijama tržišta.

2. RAZVOJ POSLOVNIH SUSTAVA

Što kao dizajneri i developeri aplikacijskih sustava trebamo od alata da bi mogli razvijati rješenja koja će zadovoljiti današnje standarde. Jasno je da početi razvoj od nule, iz početka, od praznog papira, rijetko će nas dovesti do kompletnog rješenja u dovoljno kratkom vremenu. Iz tog razloga skoro je nezamislivo da se razvoj radi bez podrške tzv. framework platformi, koje nude organizaciju, primitive, funkcije i ostale gradbene elemente, kako bi olakšali i ubrzali razvoj aplikacija. Za korištenje pojedinih frameworka potrebno je poznavati i različite programske jezike, pa tako mogućnost razvoja u heterogenim okolinama, programskim jezicima i aplikacijskim servisima, te povezivanje tako razvijenih komponenti u cjelinu putem servisne sabirnice i drugih oblika sinkronih i asinkronih servisa, omogućuje nam da budemo produktivniji, brže implementiramo odreñene funkcionalnosti i možda najznačajnije modularno razvijamo sustav i po dijelovima stavljamo u produkcijski rad.

Ono što smo napravili da radi na desktop računalima u nekoj od modernih arhitektura, raspodijeljeno prema standardima za višeslojnu arhitekturu, klijent-server, aplikacijski server, baze podataka i ostale operativne cjeline meñusobno povezane protokolima i porukama. No što je s mobilnim pristupom, naravno da hoćemo pristupati svojim podacima od svugdje i s našeg supermultifunkcionalnog mobitela, tableta ili nečeg trećeg. To nam unosi i novi element u razvoj, novu disciplinu i kategoriju razvojnih platformi i novi odjel u tvrtki, sa stručnjacima iz područja razvoja mobilnih aplikacija. Mogu nam tu pomoći novi


framework sustavi koji znaju web aplikacije koje smo razvili za radne stanice, prilagoditi mobilnim ureñajima i omogućiti nam da već napisani kod i funkcionalnosti iskoristimo i na novim platformama.

3. ALATI ZA RAZVOJ SOFTVERA

Koje alate koristiti za razvoj? Poželjno bi bilo one koje već poznajemo. No što ukoliko naši principali o kojima ovisimo nisu pratili tehnološki razvoj i nisu unaprijedili svoje razvojne platforme na nama potrebnu razinu, gdje smo mi i na koji način pristupiti razvoju softvera.

Zašto danas postoji toliko mnoštvo programskih jezika i frameworka? Do skora nam je bilo dovoljno poznavati jedan programski jezik, odabrati dovoljno dobar i razvikan framework i mogli smo razvijati moderne aplikacijske sustave. Kamo taj programerski svijet ide i što je tu dobro a što loše za odabrati i koristiti. Svi se zaklinju da je njihov pristup najbolji, najfleksibilniji, nudi mogućnosti rada na raznim ili samo Microsoft platformi, jer niti jednu drugu niti ne trebate.

Koja od platformi koju novu odaberemo, uložimo novce u nabavku, edukaciju, literaturu, razvojnu okolinu, koja od njih će nam osigurati da nećemo završiti u slijepoj ulici. Možda bi mogli igrati na sigurno i odabrati neku Java platformu, ta Java se već dugo razvija i postala je najznačajnija alternativna platforma za razvoj aplikacijskih sustava, znanja ima dovoljno na tržištu, možda je jedini problem naše ljude naučiti novom programskom jeziku i raznim frameworkovima da bi postali dovoljno efikasni u radu i postigli potrebnu brzinu u razvoju novih sustava.

Možda bih ovdje mogao dati mali savjet, isprobajte otvorene platforme iz Open Source svijeta, to bi mogao biti dobar smjer, a odabir otvorenog frameworka može pomoći u bržem i kvalitetnijem razvoju aplikacija.

3.1 Što se nudi od otvorenih platformi?

Nudi se mnoštvo rješenja, neka od njih su generička i prilagodljiva raznim namjenama, a druga su specijalizirana za odreñene platforme i namjenu. No navesti ćemo ono što ja koristim u svom radu.

Tu je prvenstveno skup alata pod okriljem Eclipse Fondation i zajednice, gdje osnovu čini Eclipse IDE produkt, koji svojom plugin arhitekturom omogućuje dodavanje

komponenti potrebnih za odreñenu funkcionalnost i razvojnu platformu. Kako je OpenObject platforma napisana u Python programskom jeziku, poželjno je imati dobru podršku za pisanje Python koda. Tu je korisno imati editor koji je prilagoñen sintaksi jezika, zna napraviti inspekciju koda, formatirati, prepraviti dio koda s meñusobnim zavisnostima, debagirati i slično. Za tu namjenu koristi se dodatak za Eclipse pod nazivom PyDev, koji je ove godine proglašen najboljim razvojnim alatom u svojoj kategoriji. Za razvoj aplikacija koje koriste bazu podataka, potrebno je imati i alat s kojim možemo pristupati objektima i podacima u bazi, a za Eclipse IDE postoji više dodataka za tu namjenu, od kojih koristim QuantumDB.

S obzirom na otvorenost i dostupnost mnoštva dodataka za Eclipse IDE, osim mogućnosti da sami složite potreban skup alata, postoje i prilagoñena i preinstalirana grupa alata. Dobar primjer i odabir je rješenje tvrtke Appcelerator pod nazivom Aptana Studio, koji sadrži sve potrebno za razvoj web aplikacija i programiranje u Python programskom jeziku.

Kada smo pokriveni osnovnim skupom alata vezano za rad u programskom jeziku i korištenje framework biblioteka, za timski rad nam je potrebno i upravljanje verzijama programa, te upravljanje projektima. Za tu namjenu možemo koristiti neki od poznatih VCS sustava kao što su Subversion, Git i Bazaar, u kombinaciji s javno dostupnim sustavima GitHub i Launchpad.

Za potrebu modeliranja korištenjem UMLa i izrade prototipova možemo koristiti Dia alat s dodacima za generiranje koda za OpenObject platformu.

4. OPENOBJECT PLATFORMA

OpenObject je intuitivna, modularna i skalabilna platforma velikih mogućnosti za brzi razvoj poslovnih aplikacijskih sustava, napisana u Python programskom jeziku. Paleta alata podržana kroz platformu pokriva objektno-relacijsko mapiranje, izradu korisničkog sučelja prema MVC standardu putem XML predložaka, generator izvještaja, automatsku podršku za višejezičnost i mnoštvo


drugih naprednih mogućnosti. Python je dinamički programski jezik pogodan za RAD, vrlo čiste sintakse i velikog raspoloživog broja biblioteka za različite namjene, a svojim dizajnom struktura jezika omogućuje vrlo visoku efikasnost prilikom pisanja programskog koda.

Platforma je iskorištena za razvoj OpenERP poslovnog sustava i čiji moduli su sastavni dio platforme. Kako se radi o objektnoj arhitekturi, moguće je na vrlo prirodan način iskoristiti postojeće module sustava i prilagoditi ih svojim, odnosno potrebama projekta i implementacije.

OpenERP dostupan je na svim platformama na kojima postoji podrška za dvije ključne komponente sustava, a to su Python programski jezik i PostgreSQL bazu podataka, a testiran je na Windows, Linux i Mac platformama.

Arhitektura sustava sastoji se od komponenti koje čine višeslojnu arhitekturu, a sastoji se od PostgreSQL baze podataka, Aplikacijskog servera, Web servera, Desktop klijenta. Postoje i klijenti za rad iz komandnog retka, te mobilni klijent, razvijeni od strane nezavisnih tvrtki. Pojedine komponente sustava su servisno orijentirane arhitekture i meñusobno komuniciraju putem standardnog XML-RPC protokola. Kao posljedica takve arhitekture centralna serverska komponenta na kojoj se instaliraju pojedini aplikacijski moduli, automatski eksponira funkcije modula kao web servise, čime se omogućuje vrlo lagana integracija s ostalim vanjskim sustavima.

Platforma je razvojno smještena u Launchpad repozitoriju (https://launchpad.net/openobject) odijeljena u četiri glavne cjeline, openobject-server, openobject-client, openobject-client-web i openobject-addons. Prve tri komponente su osnovni elementi platforme, dok addons sadrži funkcionalne module aplikacijskog sustava. Arhitektura pojedinog modula sadrži strukturirane elemente koji se smještaju u vlastiti poddirektorij (u standardnoj instalaciji je to server/bin/addons direktorij). Moduli mogu sadržavati neke od slijedećih elemenata: Poslovni objekt koji se definira kao python klasa koja nasljeñuje osv.osv objektnu klasu čija

perzistencija je kompletno upravljana OpenObject strukturama, uključujući i potpuno upravljanje objektno-relacijskim mapiranje, nadogradnjom, migracijom, bez potrebe korištenja SQL naredbi za tu namjenu. Podatke koji su definirani u XML ili CSV datotekama, a koje sadrže opise izgleda ekranskih prikaza, tijeka poslovnih procesa, konfiguracijskih podataka, demo podataka i slično. Wizardi koji predstavljaju funkcionalni programski kod koji služi za provedbu odreñene poslovne funkcije i omogućavaju akcije nad pojedinim skupovima podatkovnih zapisa. Izvještaji su podržani kroz više formata i načina definiranja i izvršavanja, ovisno o potrebi i namjeni, tako su podržani RML, MAKO, OpenOffice kao vrste predložaka, te HTML, ODT i PDF izlazni formati izvještaja.

Struktura modula definirana je u skladu s python standardima, te se tako koristi __init__.py kao python modul deskriptor, u kojem je opisan sadržaj modula, te __openerp__.py kao OpenERP deskriptor, koji sadrži opis strukture modula.

Ključna komponenta OpenObject platforme je Object Service (OSV) koji implementira kompletno objektno-relacijsko mapiranje s vrlo bogatom paletom tipova podataka i metoda koje se mogu koristiti za izgradnju modula aplikacije i poslovnih pravila, kao i funkcionalnosti prilikom interakcije. Definicija strukture modula je deklarativna i visoko efikasna, tako da se definicijom python dictionary strukture, opisuje vrlo kompleksna struktura pojedinih elemenata aplikacijskog modula, te se s vrlo malo kodiranja može izgraditi visoko funkcionalan i dorañen modul aplikacije.

Primjer izgleda takvog modula prikazan je kroz hipotetski modul koji omogućuje da se zapisuju ideje vezane na neku temu oko koje se namjerava raspravljati i ocjenjivati kvalitetu prijedloga.

__init__.py: 20 # Import all files & directories containing pyth on code 21 import idea, wizard, report __openerp__.py: 22 { 23 'name' : 'Idea', 24 'version' : '1.0', 25 'author' : 'OpenERP', 26 'description' : 'Ideas management module', 27 'category': 'Enterprise Innovation', 28 'website': 'http://www.openerp.com', 29 'depends' : ['base'], # list of dependencies , conditioning startup order 30 'data' : [ # data files to load at module init 31 'security/groups.xml', # always load groups first! 32 'security/ir.model.access.csv', # load ac cess rights after groups 33 'idea_workflow/workflow.xml', 34 'idea_view/views.xml', 35 'wizard/wizard.xml', 36 'report/report.xml', 37 ], 38 'demo': ['idea_demo/demo.xml'], # demo d ata 39 'test': ['test/test.xml'], # unit test d ata 40 'external_dependencies': {'python':['mako',' simplejson'], 41 'bin':['which']} # external dependencies 42 'active': False, # whether to install au tomatically at new DB creation 43 'certificate': 0123456789012, # certificate number 44 'installable': True, 45 }


Objekti mogu sadržavati tri tipa polja, jednostavni tip, relacijski i funkcijski. Svi tipovi i strukture opisani su u tehničkoj dokumentaciji, tako da će ovdje biti samo navedeni bez detaljnijih opisa svojstava. Jednostavni tipovi podataka su standardni tipovi, kao što su integer, char, float, date, boolean. U istu grupu spadaju i nešto složeniji tipovi binary, selection i reference. Relacijski tipovi opisuju relacije izmeñu objekata, a na raspolaganju su many2one, one2many i many2many polja.

Funkcijski tipovi koriste se za izvedene tipove podataka, a podržani su function koja omogućuje deklaraciju polja koje će se izračunavati kao vrijednost funkcije, zatim related koji omogućava da se polje iz drugog objekta koristi u objektu u

kojem se deklarira, te property polje koje predstavlja dinamičko polje s mogućnosti kontrole prava pristupa.

Kako se radi o objektnom modelu, moguće je koristiti objektne mehanizme, kao što je nasljeñivanje, koje je iskorišteno za vrlo fleksibilnu mogućnost dodavanja novih funkcionalnosti na postojeće objekte, dok se mogućnost zamjene funkcija može iskoristiti za nadogradnju poslovne logike i dodavanje novih svojstava pojedinim objektima.

Podržani tipovi nasljeñivanja prikazani su u nastavku.

Nakon izgradnje modela i poslovne logike, značajno

idea.py: 46 from osv import osv, fields 47 class idea(osv.osv): idea 48 _name = 'idea.idea' 49 _columns = { 50 'name': fields.char('Title', size=64, re quired=True, translate=True), 51 'state': fields.selection([('draft','Dra ft'), 52 ('confirmed','Confirmed')],'Sta te',required=True,readonly=True), 53 # Description is read-only when not draf t! 54 'description': fields.text('Description' , readonly=True, 55 states={'draft': [('readonly', Fals e)]} ), 56 'active': fields.boolean('Active'), 57 'invent_date': fields.date('Invent date' ), 58 # by convention, many2one fields end wit h '_id' 59 'inventor_id': fields.many2one('res.part ner','Inventor'), 60 'inventor_country_id': fields.related('i nventor_id','country', 61 readonly=True, type='many2one' , 62 relation='res.country', string ='Country'), 63 # by convention, *2many fields end with '_ids' 64 'vote_ids': fields.one2many('idea.vote', 'idea_id','Votes'), 65 'sponsor_ids': fields.many2many('res.par tner','idea_sponsor_rel', 66 'idea_i d','sponsor_id','Sponsors'), 67 'score': fields.float('Score',digits=(2, 1)), 68 'category_id' = many2one('idea.category' , 'Category'), 69 } 70 _defaults = { 71 'active': 1, # ideas are active by default 72 'state': 'draft', # ideas are in draf t state by default 73 } 74 def _check_name(self,cr,uid,ids): 75 for idea in self.browse(cr, uid, ids): 76 if 'spam' in idea.name: return False # Can't create ideas with spam! 77 return True 78 _sql_constraints = [('name_uniq','unique(na me)', 'Idea must be unique!')] 79 _constraints = [(_check_name,'Please avoid spam in ideas !', ['name'])] 80 idea() # Instantiate the class

class idea2(osv.osv): idea2 82 _name = 'idea.idea' 83 _inherit = 'idea.idea' 84 def _score_calc(self,cr,uid,ids,field,arg, context=None): 85 res = {} 86 # This loop generates only 2 queries th anks to browse()! 87 for idea in self.browse(cr,uid,ids,cont ext=context): 88 sum_vote = sum([v.vote for v in id ea.vote_ids]) 89 avg_vote = sum_vote/len(idea.vote_ ids) 90 res[idea.id] = avg_vote 91 return res 92 _columns = { 93 # Replace static score with average of votes 94 'score':fields.function(_score_calc,typ e='float',method=True) 95 } 96 idea2()


je na koji način možemo prezentirati podatke, te izraditi forme za unos podataka. Za izgradnju korisničkog sučelja na raspolaganju su nam uobičajene strukture, kao što su meniji, ekranski prikazi, akcije, prava pristupa. Svaki od navedenih zapisa opisuje se putem XML datoteke, a podržava za svaku od struktura specifične atribute. Generički izgled strukture je sljedeći.

Strukture koje služe za ekranske prikaze omogućavaju načine prikaza koji nisu uobičajeno podržani u drugim aplikacijskim sustavima i alatima za razvoj. Osim standardnih prikaza u obliku liste i forme, podaci se mogu prikazati u obliku kalendara, grafa i gantograma, te se na taj način prezentiraju na prirodan način u odnosu na stvarnu namjenu pojedine evidencije.

Pojedini načini prikaza definiraju se deklarativno za svaki od objekata, te ih se može koristiti istovremeno, te prebacivati način prikaza ovisno o potrebi. Pregledom liste može se uključiti filter nad podacima, a nakon toga se može način pogleda prebaciti u kalendarski način i tako odabrane podatke prikazati u kalendarskom prikazu.

U samu platformu ugrañeni su i sistemski moduli koji služe za modeliranje i prilagodbu sustava. Korištenjem direktno iz klijenta, pa i putem web klijenta, omogućene su promjene nad strukturama polja, prikaza pojedinih polja na ekranu, izmjena prava pristupa, dodavanje novih korisnika i

definiranje prava, promjene tijeka odvijanja poslovnih procesa, te mnoštva drugih aktivnosti potrebnih za prilagodbu i lokalizaciju izgrañenog programskog rješenja. Nekoliko svojstava koje razlikuje opisani sustav od konkurentskih je i mogućnost korištenja modula za snimanje izmjena na strukturama modula i podacima koji se unose u sustav, a nakon spremanja snimljenih promjena, moguće ih je prenijeti na drugi sustav i pokrenuti njihovu primjenu. Na taj način možemo snimiti prilagodbe napravljene na sustavu i upisane podatke u šifarnike, te ih u jednom potezu primijeniti na novoinstaliranom sustavu, čime možemo značajno ubrzati implementaciju rješenja.

5. ZAKLJU ČAK

Kako se radi o Open Source platformi i programskom rješenju koje se koristi u više desetaka zemalja u svijetu i s raširenom zajednicom tvrtki i pojedinaca koji rade na implementaciji i dalje razvijaju funkcionalnosti koje već sada postoje u vidu preko 500 funkcionalnih modula za podršku različitim poslovnim procesima, sigurno je da OpenObject platforma ima sigurnu i svijetlu budućnost u razvoju aplikacija za poslovnu primjenu.

97 <?xml version="1.0" encoding="utf-8"?> 98 <openerp> 99 <data> 100 <record model="object_model_name" id="objec t_xml_id"> 101 <field name="field1">value1</field> 102 <field name="field2">value2</field> 103 </record> 104 <record model="object_model_name2" id="obje ct_xml_id2"> 105 <field name="field1" ref="module.object_x ml_id"/> 106 <field name="field2" eval="ref('module.ob ject_xml_id')"/> 107 </record> 108 </data> 109 </openerp>


Poslovna biografija

Goran Cvijanovi ć Vinteh d.o.o. Vinež 332a 52220 Labin Tel +38552856673 Fax +38552856673 e-mail: [email protected] Direktor tvrtke Vinteh d.o.o. specijalizirane za implementaciju rješenja zasnovanih na platformama otvorenog koda. Posebno se bavi integracijom i optimiranjem sustava s velikom količinom podataka koristeći Pentaho DI, PostgreSQL i MySQL s kolumnarnom arhitekturom, izgradnjom sustava za izvještavanje i podršku poslovnom odlučivanju s Pentaho i Palo BI, te savjetovanjem u primjeni rješenja zasnovanih na OpenObject platformi. CEO of Vinteh d.o.o. company, specialized in the implementation of solutions based on open source platforms. Specifically addresses the integration and optimization of the systems with a large amount of data using Pentaho DI, PostgreSQL and MySQL with column oriented architecture, building reporting and decision support solutions using Pentaho and Palo, and consulting in implementation of solutions based on OpenObject platform.


JASPER REPORTS I OPEN REPORTS - ALAT I PLATFORMA ZA IZVJEŠTAJNE SUSTAVE

JASPER REPORTS AND OPEN REPORTS - REPORTING SYSTEMS TOOLS AND PLATFORM

Ksenija Bastijani ć Cvijanovi ć

SAŽETAK:

Tijekom definicije i razvoja informacijskih sustava glavni i osnovni cilj nam je "pohvatati" poslovne procese i pretočiti ih u forme, strukture podataka ili servise. I koliko god to dobro napravili, na kraju korisnik uvijek nešto želi imati na papiru. Rješenje smo našli u Open Source tehnologiji i to upravo kombinacijom dva proizvoda Jasper reports i Open Reports. Lakoća korištenja, minimalni zahtijevani resursi i skalabilnost sustava te neovisnost o bazama podataka i operacijskim sustavima bili su razlog odabira koji je potvrñen paletom funkcionalnosti koji ova kombinacija alata pruža. Osim standardnih poslovnih izvještaja Jasper Reports koristimo i kod praćenja izvršavanja poslovnih procesa i upravljanja dokumentima, za nadzor rada pozivnog centra ili statistiku poziva na VoIP centrali (Asterisk). Ukratko, ukoliko imamo potrebu da različite izvore podataka objedinimo i napravimo nekoliko konsolidiranih izvještaja, a nismo spremni za implementaciju enterprise BI sustava Jasper Reports i Open Reports predstavljaju pravo rješenje.

ABSTRACT:

During the definition and development of information systems our major goal is to capture business processes and translate them into forms, data structures or services. No matter how good we do this job, the end user will always want to have something printed on paper. The solution we offer in Open Source technology is the combination of two products – Jasper Reports and Open Reports. Ease of use, minimal resources required scalability of the system and database and operating systems independence are the reasons we use those products. The selection is confirmed by a range of functionality provided by this combination. In addition to standard business reports we use Jasper Reports for monitoring the execution of business processes and document management, call center statistics or VoIP (Asterisk) appliance statistics. Whenever we need to access a database or various data sources and make few reports, and enterprise BI system seems to be an overhead at the moment, Jasper Reports and Open Reports are quite the right solution.

1. UVOD

Koliko god sofisticiran i dobro dizajniran informacijski sustav izgradili, krajnji korisnik uvijek nešto želi dobiti na papiru. Tijekom specifikacije funkcionalnosti informacijskog sustava definicija izvještaja najčešće nam nije prioritet pogotovo ako informacijski sustav koji gradimo nije klasični ERP sustav, nego se radi o nekim specijaliziranim sustavima ili razvoju za specifične potrebe korisnika. Često taj dio posla stavljamo na stranu dok prioritetno definiramo i implementiramo forme, use-case-ove i poslovne procese. I sama često korisnicima objašnjavam kako je bitno da posložimo strukture podataka i krenemo s unosom podataka, lako ćemo sa izvještajima. Svaki put kad to izgovorim na projektu uhvatim sebe kako još mjesecima nakon

službenog zaključenja projekta „štrikam“ izvještaje i „izvlačim“ statistike. Srećom, pomaže mi dobar alat.

2. OPEN REPORTS

Open Reports je poslužitelj za izvještaje i alat za jednostavne izvještaje kojeg sam upoznala prije nekih 3-4 godine na projektu skeniranja i arhiviranja velike količine dokumentacije. Većina capture i document management sustava s kojima sam imala prilike susretati se nema integriran izvještajni sustav koji omogućuje prilagodbu specifičnim potrebama korisnika. Zahtjevi korisnika nalagali su nadzor rada sustava i statistike nad nizom kriterija koje capture sustav nije mogao isporučiti, a budžet za reporting sustav se nije planirao. Ono što se u tom trenutku pokazalo kao


vatrogasno rješenje, postalo je pravi izbor. Open Reports sam odabrala prvenstveno zato što je jednostavan i zahtjeva minimalne resurse. Za instalaciju je dovoljan Apache Tomcat server, Java i nešto sitno megabajta na disku. Vrijeme potrebno da se napravi osnovni izvještaj i omogući pokretanje krajnjim korisnici mjeri se u minutama. Open Reports omogućuje izradu jednostavnih statističkih izvještaja u PDF ili Excel formatu, dovoljno je da mu zadate izvor podataka (JDBC), upit na bazu i grupu korisnika koji mogu izvještaj pokrenuti i izvještaj je omogućen korisnicima putem web preglednika. Takvi tipovi izvještaja nazivaju se Query Reports.

Upravo je ta jednostavnost koju nudi Query Reports razlog što tako često koristim Open Reports. Uz izradu izvještaja OpenReports nudi web sučelje dostupno sa samom instalacijom izvještajnog servera. Nije potrebno poznavanje alata, dovoljno je samo znanje sql-a. Definicija i konfiguracija izvještaja je smještena u bazi podataka, to može biti HSQLDB koja dolazi sa instalacijom Open Reportsa ili nekom drugom bazom Oracle, MySQL, MS SQL Server, PostgreSQL.

Uzmimo primjer tablice sa imenom i prezimenom klijenta i mjestom.

ime_prezime mjesto Ksenija Bastijanić New York Goran Cvijanović London Pero Perić Zagreb

Dovoljno je definirati sql upit i po potrebi navesti potrebne parametre i izvještaj je gotov.

Izlazni rezultat Query Reports izvještaja nije reprezentativan, to je jednostavna lista podataka i koristim ga onda kad mi treba brzo kreiranje izvještaja, nadzor nekog dijela procesa ili kontrola stanja odreñenih podataka u bazi.

Zahtjevni korisnik će tražiti nešto više, malo dizajna, koju sliku. Za takve potrebe možemo dizajn izvještaja definirati u .xls formatu, dodati vlastite izračune i grafove.

Sljedeća funkcionalnost koja me je oduševila jednostavnošću je automatsko slanje izvještaja. Opskrbljen Quartz Schedule-rom, Open Reports server omogućuje automatsko slanje izvještaja na više mail adresa po svim onim kriterijima slanja koje nam quartz

omogućuje: dnevno, tjedno, prvi ponedjeljak u mjesecu ili možda svakih 5 minuta, ako za to postoji potreba. Tu funkcionalnost najčešće korisnim kod nadzora poslovnih procesa.


3. IZVJEŠTAJI U SLUŽBI BPMA

Većina sustava za provoñenje i upravljanje poslovnim procesima i document management sustava podatke o statusu zadataka, fazi izvršenja procesa, korisnicima i zadacima čuva u nekoj bazi podataka. Svaka ona baza koja omogućuje JDBC pristup čini izvor podataka. Na taj način možemo formirati sustav za nadzor procesa bez obzira da li se radi o informacijskom sustavu koji čini podršku upravljanju procesima ili se proces sastoji od više radnji i sustava koje na taj način možemo ujediniti. Uzmimo za primjer likvidiranje ulaznih računa od 3 osnovna koraka – Urudžbiranje, odobrenje, obrada u računovodstvu. Često ćemo za taj proces imati više baza podataka u kojima se vodi evidencija, urudžbirat će se u urudžbenom zapisniku, odobravati u DMSu a knjižiti u sustavu knjigovodstva. Idealna je situacija kada su ti sustavi integrirani, ali često nisu. Postavljanjem izvještajnog sustava nad ta tri sustava možemo pratiti tijek procesa bez obzira u kojem dijelu procesa se nalazimo i u kojem se sustavu proces obrañuje. Za integraciju na razini baza podataka tu se koristimo takoñer Open Source alatom Pentaho

Nad tako objedinjenim sustavom Open Reports

omogućuje nam praćenje tijeka procesa kroz same izvještaje te obavještavanje korisnika o nepravilnostima u izvoñenju procesa izravno ili slanjem u elektroničku poštu. Statistike, uska grla procesa, kašnjenja sada postaju vidljivi čak i kada cijeli proces nije obuhvaćen nekim BPM-om. Sustav periodički provjerava status procesa i ukoliko su se dogodile bilo kakve nepravilnosti u izvoñenju procesa, sustav obavještava nadležne korisnike. Isto vrijedi i za kašnjenja izvršavanja zadataka u sustavu od strane krajnjih korisnika. „Tužibaba“ izvještaj dnevno ili tjedno mailom obavještava nadležne korisnike o broju neriješenih zadataka i kašnjenjima u rješavanju i završavanju zadataka.

Kako BPM aplikacije generiraju velike količine podataka, BI i izvještajni sustavi postaju ekstenzija koja omogućava poslovnim korisnicima nadzor nad svakom fazom poslovnog procesa. Te su statistike ujedno i input za redizajn i unaprjeñenje procesa.

Open Reports server moguće je izravno povezati sa bilo kojim aplikacijskim sustavom koji može pozvati http link u kojem će definirati naziv izvještaja, parametre te format izlazne datoteke (pdf, xls , html i drugi).

Open Reports kao server alat za izradu izvještaja je


stabilan, zahtjeva minimalne serverske resurse jednostavan je za instalaciju, konfiguraciju i korištenje. U prilog tome govori činjenica da se tijekom našeg iskustva s tim serverom niti jednom nije srušio. Meñutim kao alat za izradu izvještaja nije funkcionalno dovoljno obuhvatan za sve poslovne potrebe koje smo trebali izvještavanjem pokriti. Zato smo kao alat za izradu i dizajn izvještaja uzeli Jasper Reports. Jasper je jedno od najpoznatijih imena meñu open source reporting i BI alatima. Jasperov iReports, Java Visual Report Designer omogućuje izradu standardnih poslovnih izvještaja sa profinjenim dizajnom i mogućnošću kombiniranja grafikona, slika, podizvještaja, matričnih izvještaja. Dodatna serverska komponenta nije potrebna za samo izvoñenje izvještaja možemo koristiti Open Reports server.

4. JASPER REPORTS

Jasper Reports omogućuju višestruke grupe podataka na više razina hijerarhije (master/detail) sa mogućnošću sumiranja po različitim razinama. Grupama podataka možemo dodavati slike, linije, okvire te statička i dinamična tekstualna polja, kao i podatke iz drugih izvora te rezultate izračuna na osnovi polaznih podataka. Svaki element izvještaja može biti precizno pozicioniran i upravo one veličine koja je potrebna za savršen dizajn.

Izlazne formate bira sam korisnik prilikom izvršavanja izvještaja - PDF, HTML, XLS, CSV, RTF (Word), TXT or XML datoteke.

iReports dolazi sa ugrañenim skupom funkcija i varijabli koje omogućuju generiranje vlastitih izračuna, formula, dinamičnog teksta na izvještajima ili prilagodbu izgleda objekata koristeći izvještajne parametre, polja ili druge varijable u izvještaju. I najzahtjevniji izvještaji mogu se


ostvariti putem podizvještaja. Pozivanje podizvještaja omogućuje drill down funkcionalnosti, korištenje više izvora podataka u istom izvještaju te višestruko korištenje istih izvještaja.

Jedna od pomalo neuobičajenih primjena koju sam imala priliku implementirati koristeći Open Reports i Jasper Reports je sustav izvještavanja i statistika sa Asterisk VoIP centrale. Centrala je implementirana za potrebe pozivnog centra (call centar) i potreba naručitelja je bila da se prikupljaju statistike ulaznih i izlaznih poziva te prati rad operatera telefonista. Koristeći Pentaho Data Integration alate logovi sa centrale prenose se u bazu

podataka (PostgreSQL) te se nad podacima generiraju izvješća kao npr.

OpenReports i Jasper Reports dostupni su kao open source produkti pod GNU Public License (GPL) licencom. Te produkte moguće je preuzeti sa web stranica sourceforge.net/projects/oreports i jaspersoft.com/download te koristiti ih za vlastite potrebe ili modificirati ukoliko za to postoji potreba. Kao i kod ostalih open source produkata niste vezani uz jednog dobavljača, ne morate plaćati licenčno održavanje osim ako se ne odlučite za Professional opciju softvera i tehničku podršku od strane JasperSoft stručnjaka.

Podaci o autoru: Ksenija Bastijani ć Cvijanovi ć Vinteh d.o.o. Vinež 332a 52220 Labin Tel 052/856-673 Fax 052/856-673 e-mail: [email protected] Ksenija Bastijanić Cvijanović je svoje iskustvo stekla tijekom posljednjih desetak godina radeći na projektima za državnu upravu i veće hrvatske trgovačke kuće u informatičkim tvrtkama In2, Omega softvare i King ICT. Upoznala je enterprise platforme Oracle-a, Microsofta i EMC-a za razvoj aplikacija i upravljanje dokumentima. Posljednjih godinu dana okrenula se Open Source filozofiji koju implementira kod svojih korisnika radeći u vlastitoj tvrtki Vinteh. Ksenija Bastijanić Cvijanović has developed experience during last decade on projects in public sector and retail industry as employee of Croatian IT companies In2, Omega Software and King ICT. She used Enterprise Platforms Oracle, Microsoft and EMC to develop application systems and document management systems. Lately, she embraced the philosophy of OpenSource code and implements OpenSource solutions at her customers on behalf of her own company Vinteh.


ONTOLOGIJA I RAZVOJ INFORMACIJSKOG SUSTAVA U JAVNOJ UPRAVI

ONTOLOGY AND INFORMATION SYSTEM DEVELOPMENT FOR GOVERNMENT

Karmen Klarin

SAŽETAK:

Unatrag petnaestak godina razvoj informacijskih sustava informatičari nastoje obogatiti korištenjem ontologija. Ontologije mogu poboljšati dva aspekta računalnih aplikacija. Prvi se odnosi na analizu i oblikovanje sustava u kome se ontologija može koristiti kao podrška upravljanju zahtjevima, te tako pomoći u optimizaciji strukture modela sustava. Drugi je mogućnost implementacije ontologije kao dijela informacijskog sustava na način da struktura ontologije pruža mehanizme pohrane znanja koje je moguće primijeniti i ponovno iskoristiti za razne namjene, prvenstveno web aplikacije.

U ovom radu razmatra se mogućnost primjene ontologije u javnoj upravi. Poslovanje javne uprave je zakonom propisano što predstavlja dobro polazište za konceptualizaciju zadanog područja. Prikazan je model primjene ontologije na poslove javne uprave ovisno o razini i području konceptualizacije, s naglaskom na elektroničku upravu. Uz to, primjenjivost razvoja i implementacije ontologije u elektroničkoj upravi ima uporište u strategiji razvoja elektroničke uprave u RH.

Ključne riječi: ontologija, informacijski sustavi, razvoj informacijskih sustava, javna uprava, elektronička uprava

ABSTRACT:

In past fifteen years information technology professionals attempt to enrich information system development process by using ontology. Ontology may improve two software applications aspects. First include system analyze and design where ontology supports requirements management resulting in optimizing system model structure. Second advance include ontology implementation feature as part of information system where ontology structure provides knowledge store methods for implementation and reuse of knowledge, especially for web application.

This paper described ontology implementation possibility in government information system. Government business activity is described by legislations making it good starting point for domain conceptualization. Ontology model is implementing on government business depending on level conceptualization and domain conceptualization, with a focus on e-government. Furthermore, document named ‘Strategy Development of e-government in Croatia’ represents solid base for ontology development and implementation applicability.

Key words: ontology, information system, information system development, government, e-government

1. UVOD

1.1 Uloga ontologije u informatici

Već neko vrijeme razvoj informacijskih sustava (IS) informatičari nastoje obogatiti korištenjem ontologija. U terminima IS-a ontologija je detaljan i iscrpan opis nekog područja znanja, sa formalnim definicijama meñusobnog odnosa elemenata ontologije i veza meñu različitim elementima ontologije. Jedna od često korištenih definicija kaže da je ontologija eksplicitna specifikacija zajedničke konceptualizacije [1]. Konceptualizacija je u osnovi predodžba o svijetu kakvu pojedinac ili grupa mogu imati. Eksplicitno znači da su koncepti i ograničenja korištenja koncepata izričito definirani. Formalno znači da je strojno čitljivo. Zajedničko (dijeljeno) znači da postoji suglasnost i prihvaćanje cijele interesne grupe.

Životni ciklus razvoja ontologije podržan je metodologijama koje u sebi imaju ugrañene korake specifične obzirom na elemente ontologije, vrste ontologije, te primjenu u raznim jezicima za prikaz ontologije [3]. Općenito, većina poznatih metodologija razvoja ontologije zasnovana je na IEEE standardu za procese razvoja životnog ciklusa softvera [2]. Uklapanje životnog ciklusa razvoja ontologije u životni ciklus razvoja IS-a može predstavljati poboljšanje razvoja, izvedbe i implementacije sustava. Ukoliko je riječ o

sustavima koji u sebi imaju i web aplikacije, onda razvoj odgovarajuće ontologije postaje i nužnost. Osim prednosti ontološki pristup može imati i nedostataka, prvenstveno u resursima: informatičari koji moraju poznavati razvoj ontologija, te vrijeme i novac koji zahtijeva ontološki pristup kao dodatni napor u rješavanju nekog problema.

Ipak, kako područje interneta postaje sve više standardna okolina u kojoj 'žive' računalne aplikacije, dobro je sagledati mogućnosti koje pruža ontologija kao sastavni dio IS-a. Koje od tih mogućnosti i u kolikom opsegu iskoristiti ovisi o konkretnom problemu koji se rješava i balansu izmeñu onoga što pruža tehnologija i ograničenja na koje se nailazi u rješavanju problema.

1.2 Aktivnosti razvoja ontologije

Ontologija može pokriti bilo koji dio poslovanja koji je računalno podržan i promjenjiva je kroz vrijeme. Kakve promjene će ontologija doživjeti ovisi o krugu ljudi i računala kojima ona služi, te o području poslovanja koje je njome opisano.

Struktura ontologije može biti jednostavna tj. siromašna, pa se takve ontologije nazivaju lagane (eng. lightweight) [3]. Nasuprot njima složena struktura bogata vezama i logikom naziva se teška ontologija (eng. heavyweight). Unutar ove podjele postoje podpodjele koje se mogu


povezati sa aktivnostima razvoja ontologije, o čemu će biti riječi u nastavku. Aktivnosti razvoja ontologije su slika strukturnog pristupa izgradnji i korištenju ontologije preko modeliranja, zatim formalne logički bogate definicije do implementacije u računalno čitljivom i razumljivom obliku. U aktivnosti razvoja ontologije spadaju planiranje, specifikacija, konceptualizacija, ponovno korištenje, procjena i održavanje [4] [5] (slijed nabrajanja ne mora značiti i vremenski slijed odvijanja aktivnosti). Navedene aktivnosti su detaljnije opisane u nastavku.

U početku izgradnje ontologije treba planirati što će ontologija prikazivati; treba odrediti cilj i namjenu ontologije. Treba specificirati tzv. pitanja o sposobnosti koja će odgovoriti je li ontologija dobro strukturirana i hoće li ljudi i aplikacije kojima služi dobiti ispravne (odgovarajuće) informacije. Ova pitanja su sastavni dio dokumenta koji se naziva dokument specifikacije zahtjeva nad ontologijom. Specifikacija može biti neformalna ili formalna, što odgovara laganom odnosno teškom prikazu strukture ontologije.

Konceptualizacija je aktivnost u kojoj se prikupljeno znanje formira u strukturu koncepata. Konceptualni model opisuje problem i njegova rješenja. Sada ontologija teži da postane formalna, zapisana u nekom formalnom jeziku koji osim što opisuje strukturu koncepata ontologije, opisuje i veze, funkcije i tzv. aksiome kojima se opisuju pravila poslovanja. Za opis funkcija i aksioma koristi se tzv. logika prvog reda, okviri i opisna logika, koji su sastavni dio jezika za prikaz ontologije.

Aktivnost ponovnog korištenja znanja (eng. reuse) je princip koji općenito informatičari smatraju obaveznim primijeniti u mnogim granama informatike. Ponovno korištenje mora biti odlika i dobre ontologije. Treba nastojati ponovno iskoristiti postojeće ontologije i integrirati što je moguće više od njih u vlastitu ontologiju.

Ontologija bi trebala proći procjenu odnosno aktivnost evaluacije, tako da se ne dogodi da se ponovno koristi ili implementira kriva ontologija. Pod tim se misli na njenu ispravnost, ali i neodgovarajuću strukturu ontologije i područje koje ona prikazuje.

Prije ili kasnije će se dogoditi da treba dodati ili izmijeniti nešto u definiciji ontologije, te je održavanje bitna aktivnost. Održavanje bi trebalo biti podržano odgovarajućim uputama, te je dokumentacija sastavni dio odnosno rezultat provoñenja spomenutih aktivnosti.

2. DOPRINOS ONTOLOGIJE U ANALIZI I OBLIKOVANJU INFORMACIJSKOG SUSTAVA JAVNE UPRAVE

Oblik koji ontologija poprima u odreñenom trenutku razvoja može ovisiti o razini formalnosti (princip odozgo prema dolje tj. od jednostavnih ka složenim spoznajama). Opis razina formalnosti ontologije javne uprave prati prikaz razina spoznaje o poslovanju javne uprave i podržan je odgovarajućim aktivnostima razvoja ontologije za svaku pojedinu razinu.

2.1 Poslovanje javne uprave – promatrane razine

Poslovi javne uprave koji se promatraju u ovom radu odnose se na planiranje i praćenje izvršenja proračuna. Kako su to neprofitne organizacije njihov 'zdravi' opstanak ovisi o ispravnom planiranju prihoda i rashoda koji onda prate poslovanje tijekom zadanog perioda (godina dana). Praćenje izvršenja plana uključuje razne

korisnike proračuna: vlastite organizacije, grañane i pravne subjekte.

Poslovanje javne uprave obzirom na strukturu informacija koje se obrañuju može biti podijeljeno u četiri razine: � Osnovne klasifikacije i ostali zajednički šifrarnici.

Klasifikacije su podijeljene po različitim kategorijama poslovanja (programska, ekonomska, lokacijska, itd. klasifikacija). Osim toga, prati se popis partnera, popisi artikala, opreme i sl.

� Osnova poslovanja je planiranje i praćenje, često se naziva izvršenje, proračuna. To je jezgra sustava javne uprave.

� Izvršenje proračuna je kontinuirani proces prikupljanja informacija iz tzv. pomoćnih knjiga (to su detalji o funkcionalnim podsustavima poslovanja) i obrade prikupljenih informacija.

� Način prikupljanja i obrade informacija koji ovisi o tehnološkoj podršci samom poslovanju.

Zadnja točka je operacionalizacija poslova prvih triju točaka, ona u sebi nosi način obrade podataka i prilagodbu organizacijske strukture zaposlenika.

2.2 Primjena aktivnosti razvoja ontologije u analizi i oblikovanju

Ontologija, ukoliko se primjenjuje, predstavlja sastavni dio modeliranja procesa i podataka nekog područja na razini meta-informacija. Stoga ontološke aktivnosti specifikacije i konceptualizacije mogu pomoći u analizi poslovanja (faza razvoja IS-a) i definiranja zahtjeva nad IS-om.

Leksikon osnovnih pojmova i neformalna struktura ontologije osnovnih šifrarnika (slika 1.) koristit će svim dijelovima poslovanja te je dobar izvor znanja za formiranje osnovnih zahtjeva. Što će tu biti uključeno ovisi o opsegu projekta, ali i o cilju i namjeni ontologije. Tako opseg projekta odreñuje opseg ontologije (ne mora biti jednako), a specifikacija ontologije doprinosi specifikaciji zahtjeva nad IS-om.

Znanje o osnovnim šifrarnicima je samo dio specifikacije zahtjeva. Na osnovu njega i na osnovu poslovnih pravila planiranja i izvršenja, mogu se izraditi zahtjevi osnovnog poslovanja. Ontologija se proširuje sa konceptima (ako je potrebno), te vezama meñu konceptima i pravilima poslovanja planiranja i izvršenja. Na slici 1. je prikazano kako ovo proširenje do ontologije planiranje/izvršenje može biti neformalne strukture odnosno modela. U momentu kada se ontološki model formalizira zalazi se u područje oblikovanja novog IS-a.

Oblikovanje novog sustava je otkrivanje detalja o poslovanju i slaganje nove poslovne logike. Stoga model ontologije planiranje/izvršenje sada može biti proširen detaljima o pravilima i logici zadataka pojedinih pomoćnih knjiga (slika 1.). Kroz zapisana pravila ponašanja, funkcije i aksiome ontologije, moguće je odgovoriti i na pitanja o sposobnosti ontologije te tako provjeriti njenu strukturu. Osim toga, u definiranoj logici ontologije kriju se i odgovori na specifikaciju korisničkih zahtjeva nad IS-om. Traženjem rješenja kroz logiku ontologije zadataka može se potvrditi ispravnost i opseg zadanih funkcionalnosti.

Kada se ontologija zadataka pomoćnih knjiga proširi sa ontologijom aplikacija (slika 1.) gdje se još dodatno detaljiziraju koraci načina rada računalnih aplikacija, može se tragati za postojećim rješenjima i ponovno iskoristiti ona koja odgovaraju traženoj implementaciji. Sada je to već domena fizičkog oblikovanja elemenata


novog IS-a gdje formalna specifikacija ontološkog modela može biti preduvjet za primjenu modelom podržanog (eng. model-driven) pristupa u fazi oblikovanja i izvedbe [6]. Tako formalna ontologija zadataka i aplikacija potvrñuje i daje podršku budućoj izvedbi IS-a.

3. DOPRINOS ONTOLOGIJE U POHRANI I KORIŠTENJU ZNANJA

Ontologija je meta-struktura zapisa o znanju nekog područja s kojom se onda poklapaju/preklapaju strukture ugrañene ili izvedene iz raznih aplikacija. Bez ontologije, znanja odreñene domene prikazana su na općenito nekompatibilne načine, iako se koristi istovjetan model znanja [7]. Dobra strana korištenja meta-modela je što se ne dovodi u pitanje korisnost pojedinog specifičnog modela. Ontologija pruža 'kostur' (shemu) za komuniciranje modela odreñene domene. Funkcija meta-modela ontologije je stvaranje inteligentnih aplikacija.

Konceptualno gledano, može se reći da je ontologija javne uprave jedna a aplikacija na raznim razinama ima više. Te aplikacije svojim sučeljem omogućavaju korisnicima rad sa konkretnim bazama podataka koje predstavljaju instance zadane ontologije. Odnosno, pretpostavka je da predstavljaju instance, ali ukoliko nije moguće iz pojedine aplikacije generirati strukturu kakva je definirana u ontologiji, onda ontologija ne ispunjava svoju svrhu. Naime, u tom slučaju ontologija ne služi kao komunikator izmeñu agenata (ljudi i/ili računala) jer generirana struktura iz spomenute aplikacije ne prepoznaje zadani 'jezik' ontologije. Ipak, treba naglasiti da je ontologija po definiciji specifikacija konceptualizacije, pa je kao specifikacija samo instanca meta-ontologije odnosno konceptualizacije javne uprave. Tako tri različite instance iste konceptualizacije mogu biti ontologija državne uprave, ontologija regionalne uprave i ontologija lokalne uprave. Nadalje, u praksi bi se sigurno dogodilo da postoji više ontologija javne uprave na bilo kojoj razini. Informatičari bi trebali osigurati komunikaciju

meñu ontologijama i komunikaciju ontologija i odgovarajućih aplikacija.

3.1 Podru čja konceptualizacije ontologije javne uprave

Prije analize uloge ontologije javne uprave u korištenju IS-a javne uprave potrebno je općenito sagledati mogućnosti ontologije obzirom na područje konceptualizacije. Nakon toga će doći do izražaja naglasak na odreñene uloge ontologije jer se one odnose na specifična područja. Podjela ontologije na područja konceptualizacije i odgovarajući dijelovi ontologije javne uprave prikazani su na slici 2. U nastavku će kroz nekoliko primjera biti objašnjeni pojedini dijelovi ontologije javne uprave u kontekstu područja konceptualizacije.

Ontologija je specifični model znanja koji ne mora predstavljati znanje o cijelom području. Npr. u domeni grañana kao korisnika/obveznika usluga javne uprave, inženjer ontologije će odabrati jedan skup atributa grañana kada razvija ontologiju socijalnih i drugih pomoći grañanima, a skroz drugi skup atributa grañana za ontologiju porezne uprave. Ove dvije ontologije sigurno imaju i zajedničkih elemenata, koji uz to mogu biti zajednički i mnogom drugim područjima koji imaju i koriste informacije o grañanima. Zajedničke informacije se mogu nalaziti u tzv. općoj ontologiji domene (slika 2.) koja definira konceptualizaciju zajedničku za više domena. Specifičnosti domene socijalnih i drugih pomoći, odnosno domene porezne uprave pohranjuju se u dvije tzv. ontologije domene. Te dvije ontologije domene sadrže specijalizaciju koncepata koji postoje u općoj ontologiji domene.

Ontologija domene je nepotpuna ukoliko nema pridruženu i ontologiju zadataka koja proširuje osnovnu ontologiju koncepata. Tako se cjelovita ontologija nekog područja sastoji od ontologije zadataka koju karakterizira računalna arhitektura sustava znanja koje izvršava zadatke i ontologije domene koju karakterizira znanje o domeni na kojoj se zadaci izvode [12]. Pod zadacima koji tvore ontologiju zadataka misli se na postupke

Slika 1. Razina formalnosti ontološkog prikaza i pripadajući dijelovi ontologije javne uprave


rješavanja nekog problema kao što je dijagnosticiranje, kontroliranje, planiranje, oblikovanje i sl. Cilj izgradnje ontologije zadataka je da pruži predloške potrebne za izgradnju modela procesa kojima se rješava problem zadane domene.

U primjeru na slici 2. je zadatak 'plan' koji kada se promatra u kontekstu novčanih pomoći ili porezne uprave doprinosi rješavanju problema različitih domena. Općenito se plan sastoji od zadataka, faza i trajanja tih zadataka, te mjesta, vremena i posla koji se radi po planu. U sprezi sa ontologijom domene može se napraviti plan isplate, i to za ontologiju socijalnih pomoći može se napraviti plan isplate socijalnih pomoći grañanima, a za ontologiju porezne uprave plan isplate povrata poreza grañanima. U oba slučaja ontologija domene i zadataka koristi postojeće predloške tj. gradbene blokove (eng. building block) iz ontologije zadataka i/ili iz ontologije domene. U ontologiji domene i zadataka spomenuti gradbeni blokovi 'ožive' kada im se pridruže specifični parametri koji opisuju svaki od zadataka.

Ontologije aplikacija opisuju koncepte koji istovremeno pripadaju domeni i zadatku kao specijalizacija koncepata ontologije domene i koncepata ontologije zadataka [10]. Oni općenito odgovaraju ulogama koje imaju entiteti domene kod pokretanja neke akcije. Na slici 2. pod primjer primjene 'algoritam izračuna' misli se na pravila i ograničenja unutar neke zadane procedure. Primjeri isplate novčane pomoći ili povrata poreza odvijaju se po pravilima domene platnog prometa koja ima cijeli niz procedura sa pravilima i ograničenima nad konceptima domene. Jedno od pravila je npr. algoritam izračuna kontrolnog broja za niz znamenaka po meñunarodnoj normi ISO 7064 'modul 10,11' (i nije isključivo vlasništvo domene platnog prometa). Ovaj algoritam se može promatrati kao sastavni dio ontologije aplikacija koja onda u sprezi sa ontologijom domene i zadataka daje specijalizaciju koncepata, veza, pravila i ograničenja u ontologiji domene, zadataka i aplikacija. Tako se u njoj, primjerice, nalaze obrasci ponašanja procedure izrade naloga za plaćanje za primjer socijalne pomoći ili povrata poreza.

3.2 Uloga ontologije u aktivnostima korištenja informacijskog sustava (op ćenito)

Sada se ontologija smješta u internet okruženje gdje bi meñudjelovanje korisnika usluga web-a i pružatelja usluga preko web-a trebalo dostići razinu na kojoj bi informacijski prostor web-a bio dovoljno računalno čitljiv da pruži korisniku precizan prikaz onoga što korisnik traži. Semantic Web [13] je proširenje web-a u kojem su informacije zadane na dobro definiran način (ontologije) koji onda omogućava ljudima i računalima bolju uzajamnu suradnju. Semantic Web je zasnovan na ideji da su podaci definirani i povezani na način koji omogućava učinkovito pretraživanje, automatizam, integraciju i ponovno korištenje meñu različitim aplikacijama.

Na slici 3 [3] prikazane su neke specifične uloge eksplicitne ontologije i Semantic Weba u korištenju IS-a [8] [9]: � Pretraživanje informacija putem interneta olakšano

je korištenjem ontologije koja je izvor informacija strukturiranih u rječnik i potrebno znanje o tom rječniku. Idealizirano, web postaje veliki rječnik koji pruža brži i cjelovitiji pristup izvoru traženih informacija,

� Pristupanje informacijama od strane korisnika ili sustava može biti izraženo na nepoznatom jeziku ili u nedostižnom formatu. Ontologija pomaže u prikazu informacija na razumljiv način jer je u stanju pružiti zajedničko razumijevanje pojmova ili pridruživanje meñu skupovima pojmova. Korisnost zajedničkog pristupa informacijama je efikasnije korištenje i ponovno korištenje izvora znanja, te interoperabilnost odnosno sposobnost razmjene informacija i znanja,

� Osiguranje komunikacije meñu ljudima i/ili sustavima kojem doprinosi ontologija jer smanjuje konceptualne i terminološke nejasnoće. Ontologija osigurava povećanu konzistenciju informacija, eliminira višeznačnosti i objedinjuje različita gledišta korisnika,

� Interoperabilnost kao uzajamno djelovanje meñu različitim korisnicama ili softverskim alatima prilikom razmjene podataka. U tom slučaju ontologija ima ulogu meñujezika koji će podržati prijevod iz jednog u drugi jezik ili prikaz. U praksi, da bi prevoñenje bilo učinkovito trebalo bi imati 'prevoditelja' sa svake

Slika 2. Područje konceptualizacije ontologije i pripadajući dijelovi ontologije javne uprave


strane tj. ontologiju razmjene (eng. exchange ontology).

S ciljem cjelovitijeg prikaza utjecaja ontologija na IS (slika 3.) treba se osvrnuti i na specifičan način kojim ontologija utječe na glavne komponente IS-a [10]: � Baza podataka - smatra se da ontologija ima

presudnu ulogu u fazi analize i konceptualnog modeliranja podataka budućeg IS-a. U tom slučaju konceptualni model se može prikazati u formatu razumljivom računalu i tako prenijeti na neku odreñenu platformu. Za vrijeme izvoñenja aplikacija postoje različiti oblici zajedničkog rada baze podataka i ontologije, npr. uporabljivost ontologije kao izvora informacija je u posredovanju prilikom integracije informacija,

� Aplikacije - uglavnom se u aplikacijama nalazi poprilično implicitnog znanja o domeni sustava, npr. poslovna pravila. Još za vrijeme razvoja IS-a u ontologiju je moguće ugraditi statički dio funkcionalnosti (pravila poslovanja) po principu modularnosti. Aplikacije za vrijeme izvoñenja prevode i uklapaju eksplicitno znanje iz ontologije u implicitno znanje pohranjenu u samoj aplikaciji i tako se ontološko znanje prevodi u znanje zasnovano na konkretnom IS-u i njegovoj funkcionalnosti.

3.3 Korisnosti ontologije javne uprave u korištenju informacijskog sustava javne uprave

Pretraživanje i pristupanje informacijama:

Na razini informacija o domeni koje bi koristili grañani i pravne osobe mogu se pretraživati različiti oblici dokumenata, web stranica, stručnih područja, i to u okvirima ontologije planiranje/izvršenje zajedno sa ontologijom osnovnih šifrarnika. 'Informacije dostupne kroz sustav elektroničke uprave moraju biti strukturirane na način koji u potpunosti osigurava jednostavan, razumljiv i slobodan pristup za sve korisnike' [11]. Na razini pretraživanja i pristupanja informacijama od strane računalnih agenata aplikacija mogu se koristiti ontologije zadataka i aplikacija. Agenti bi pronalazili, prepoznavali i

zaprimali/prosljeñivali podatke i znanje o rješavanju odgovarajućih zadataka poslovnog područja.

Komunikacija i interoperabilnost:

Dogovorena i implementirana struktura koncepata ontologije osnovnih šifrarnika pruža sigurnost agentima u njihovoj komunikaciji u smislu dobivanja/pružanja informacija bez obzira na njihovu lokalnu strukturu. Modeli baza podataka ne moraju imati kompatibilne strukture a da ipak uz pridruženu ontologiju mogu pružiti maksimum potrebnih informacija. Ontologija planiranje/izvršenje i ontologija aplikacija omogućavaju razumijevanje meñu različitim korisničkim aplikacijama, bez obzira na jezik kojim su pisani i na hijerarhiju u samom komuniciranju. Naime, razvojnici korisničkih aplikacija bi i prije zgotovljenih proizvoda svoja rješenja mogli prilagoditi zadanim ontologijama. To mogu biti različite aplikacije za praćenje planiranja i izvršenja javne uprave ili aplikacije za rad pomoćnih knjiga i naravno, aplikacije integracije meñu ovim dijelovima poslovanja elektroničke uprave. Za informatička rješenja koja su već u uporabi komuniciranje elektroničkim dokumentima bi se prvo prilagodilo zadanoj ontologiji. Tako bi svaka korisnička aplikacija izrañivala svoj obrazac komunikacije. S druge strane, subjekti koji potražuju informacije od krajnjih korisnika kao što su banke, porezna uprava i sl. stvaraju ili već imaju svoje zadane obrasce koji su u skladu sa strukturom zadane ontologije, te je time olakšan prihvat/davanje informacija. U praksi se može očekivati više vlasnika različitih ontologija koje, poslovno gledano, moraju meñusobno komunicirati. Za očekivati je da će subjekti kao što su banke, porezna uprava i druge koje predstavljaju zakonski centralizirana mjesta objedinjavanja podataka zbog vlastitih i javno korisnih registara, imati svoje ontologije. Stoga najveći izazov za informatičare predstavlja omogućavanje interoperabilnosti tj. razumijevanje izmeñu dvije ontologije ili, ukoliko to nije direktno moguće, meñu zadanim ontologijama i ontologijom razmjene/prijevoda informacija.

Slika 3. Uloga ontologije i Semantic Weba


4. ZAKLJU ČAK

Sigurno se dovoljan broj i korisnost ontologija ne može očekivati preko noći, ali nastojanje da se u području elektroničke uprave stvori odgovarajuća ontologija domene i pridruženih zadataka koji pokrivaju poslovanje javne uprave bi mogao biti jedan od sastavnih dijelova strategije razvoja elektroničke uprave. Time bi se poboljšale pretpostavke za kvalitetu razvoja IS-a javne uprave i njen konačni rezultat. Osim toga, pomoću

ontologije javne uprave poboljšale bi se mogućnosti komunikacije meñu različitim izvedbama tog velikog projekta, te izmeñu korisnika javne uprave i aplikacija koje nude usluge na web-u. Informatičari bi, s vremenom, imali sigurno uporište u bazi znanja koja se može ponovno koristiti i uklopiti u analizu i razvoj novih aplikativnih rješenja ili za izmjenu i poboljšanje postojećih rješenja, kako na web-u tako i u drugim arhitekturnim rješenjima.

Literatura:

1 Borst W.N., Construction of Engineering Ontologies for Knowledge Sharing and Reuse, Centre for Telematica and Information Technology, University of Tweenty, Enschede, The Netherlands, 1997.

2 IEEE Standard for Developing Software Life Cycle Processes, IEEE Std 1074-1997, (Revision of IEEE Std 1074-1995; Replaces IEEE Std 1074.1-1995)

3 Asuncion Gomez-Perez, Mariano Fernandez-Lopez, Oscar Corcho, Ontological Engineering, Springer-Verlag Berlin Heidelberg, 2004.

4 Mariano Fernandez M., Asuncion Gomez-Perez A., Natalia Juristo N., METHONTOLOGY: From Ontological Art Towards Ontological Engineering, AAAI Technical Report SS-97-06, 1997.

5 Catherine Roussey, Guidelines to build ontologies: A bibliographic study; Urban ontologies for an improved communication in urban civil engineering projects - TOWNTOLOGY Project, COST Technical Committee "Transport and Urban Development", Lyon, 2005.

6 Happel H., Seedorf S., Applications of Ontologies in Software Engineering, Workshop on Sematic Web Enabled Software Engineering (SWESE) on the 5th International Semantic Web Conference (ISWC 2006), Athens, Greece, November 5-9, 2006.

7 Devedžić Vladan, Understanding ontological engineering, Communications of the ACM, 2002.

8 Uschold, M., Gruninger, M.: Ontologies: Principles, Methods and Applications. Knowledge Engineering Review, 1996.

9 Uschold, M., Jasper, R.: A Framework for Understanding and Classifying Ontology Applications. In Proceedings of IJCAI Workshop on Ontologies and Problem-Solving Methods, August 1999.

10 Guarino, N.: Formal Ontology in Information Systems. In Proceedings of FOIS’98, Trento, Italy. IOS Press, Amsterdam (1998)

11 Vlada Republike Hrvatske, Strategija razvoja elektroničke uprave u Republici Hrvatskoj za razdoblje od 2009. do 2012. godine, 2009.

12 Mizoguchi R., Tutorial on Ontological Engineering, New Generation Computing, 21(2003), Ohmsha Ltd. And Springer-Verlag, 2003.

13 Hendler J., Berners-Lee T., Miller E., Integrating Applications on the Semantic Web, Journal of the Institute of Electrical Engineers of Japan, Vol 122(10), str. 676-680, 2002.

Informacije o autoru:

Karmen Klarin, dipl. inž. matematike Sveučilišni studijski centar za stručne studije Kopilica 5, 21000 Split; e-mail: [email protected]. Karmen Klarin, dipl. inž. matematike, zaposlena je na Sveučilišnom studijskom centru za stručne studije Sveučilišta u Splitu na mjestu predavača u Odsjeku za informacijske tehnologije. Ima iskustvo u unapreñenju i preoblikovanju poslovnih sustava; analizi, projektiranju i održavanju informacijskih sustava; metodama razvoja i tehnikama razvoja informacijskih sustava; te modeliranju, razvoju i održavanju relacijskih baza podataka. Osposobljena je za formiranje i izvoñenje nastavnih programa na stručnom studiju iz područja informacijskih sustava i baza podataka. Radila je 15 godina u informatičkom poduzeću Enel-Split d.o.o. na brojnim projektima razvoja informacijskih sustava, te ERP rješenjima za sustave javne uprave i privatna poduzeća. U tom periodu radila je na analizi, projektiranju i razvoju informacijskih sustava za javnu upravu i to: 'Financijsko-računovodstveni informacijski sustav za Ministarstvo rada i socijalne skrbi', 'Uspostava sustava područnih riznica putem Interneta', 'Povezivanje Središnje riznice RH i Područne riznice Ministarstva zdravstva i socijalne skrbi', 'Implementacija i prilagodba ERP sustava Grad Velika Gorica', 'Integrirani informacijski sustav riznice preko interneta za tijela lokalne uprave i samouprave (BICRO, program IRCRO)'; te za privredu: 'Aplikacija za izdavanje računa ino-tvrtkama za usluge u pomorstvu' i 'Aplikacija robnog poslovanja informacijskog sustava Slobodne Dalmacije'. Karmen Klarin employed at the University Centre for Professional Studies as a lecturer in the Department of Information Technology. She has experience in the improvement and reengineering of business systems; analysis, designing and maintaining information systems, development methods and techniques; and modeling, developing and maintaining relational databases. She is also qualified for the formation and execution of educational programs in professional studies in the field of information systems and databases. She worked 15 years in IT company Enel-Split d.o.o. on numerous projects to develop information systems and ERP solutions for public administration and private enterprise.


OBRASCI MODELIRANJA PODATAKA – TAKSONOMIJA

DATA MODELING PATTERNS –TAXONOMY

Vladan Jovanovi ć, dr.sc. Mile Pavli ć, Martina Ašenbrener

SAŽETAK:

Rad prikazuje razvoj i značenje obrazaca za modeliranje podataka. Obrasci se koriste u procesu učenja oblikovanja i u oblikovanju modela podataka. Cilj ovog rada je predstaviti dvoaspektnu taksonomiju. Ostali specifični prilozi su: operativna definicija obrasca modela podataka, definirana praksa za minimalnu specifikaciju obrasca modela podataka na M2 MOF razini apstrakcije i definicije mjera veličine i McCabe-ovog tipa složenosti obrasca modela podataka.

Klju čni pojmovi : Model podataka, Obrasci, Taksonomija, Mjere

ABSTRACT:

The paper presents the development and meaning of patterns for data modeling. Patterns are also used in the process of learning to design and in data modeling design itself. The purpose of this paper is to present the two faceted taxonomy; other specific contributions are: a)Operational definition of a data model pattern b)Defined practice for minimal data model pattern specification at the M2 MOF abstraction level c)Definitions of data model pattern measures of size and McCabe like complexity.

1. UVOD

Lekcije naučene u modeliranju podataka čine iskustvo, a kodificirani primjeri iskustava u modeliranju, koja se ponovno mogu iskoristiti, materijaliziraju se u obliku obrazaca (engl. Patterns). Obrasci modela podataka (OMP, engl. Data model patterns, skraćeno DMP) predstavljaju konfiguraciju modela sa potencijalno širokom primjenjivošću. OMP su u isto vrijeme elementi dizajnerskog jezika (razvojnog jezika, jezika za oblikovanje) visoke razine gdje naziv obrasca priziva iskustva bez prisjećanja same konfiguracije. Nije sporno da je prava vrijednost apstrakcije mjera njene učinkovitosti u upotrebi obrazaca. Izum OMP-a se pomalo gubi. Redovito se koristio od 1983. godine u procesu učenja i ostalim projektima. Počevši sa (Gamma 1995) količina informacija, koje se proizvedu unutar zajednice programskog oblikovanja obrazaca (engl. Software design patterns), je znatno veća. Neki od razloga su veličina publike i više informacija potrebnih za pojedini obrazac. Programski obrasci su prvenstveno usmjereni na ponašanje i funkcionalnost. Samo dio programskih obrazaca (engl. Software patterns) može se klasificirati kao strukturalni. Statični strukturalni modeli (poput modela klase) se naočigled koriste za opis svih programskih obrazaca. Naša je pretpostavka da možemo prilagoditi neke ideje iz domene programskog oblikovanja, imajući u vidu da su takvi obrasci predstavljeni klasnim dijagramima, što je, iz perspektive baze podataka, isto model podataka.

2. PREGLED PRIMARNIH IZVORA

Neformalno, OMP su ponovno otkriveni i popularizirani od kada ih spominje Barker (1990) koji kroz cijelo jedno poglavlje objašnjava klasične strukture i generičke obrasce. On u biti koristi evoluciju generaliziranog modeliranja za Organizacijske strukture i ostale 'arhetipe'

(prototip, uzor, model) poput Proizvoda, itd. kako bi napravio slučaj za obrasce, te koristi termin Model i Pravila (meta model) za entitete na dvije razine apstrakcije unutar istoga modela.

Unutar klasičnih OMP referenci, a) Hay (1996) je svrstao obrasce u nekoliko kategorija, b) Starr (1996) se pozabavio samo apstraktnim strukturalnim obrascima – idiomima, c) Fowler (1997) je prezentirao analizu obrazaca, uglavnom generalizacije modela vezanih uz domenu; sve je to proizašlo nakon knjige o klasičnom programskom oblikovanju obrazaca Gamma (1995). Carlis (2001) razlikuje idiome, male fragmente zvane „oblici“, i recepte, malo veće OMP-e. Arlow (2004) uvodi arhetipe kao obrasce (namijenjene za programsko oblikovanje, ali primjenjive i za modeliranje podataka). Nedavno (2009) je Hay objavio poprilično apstraktan tekst koji se bavi 'univerzalnim' obrascima, dok je Blaha (2010) bio jako pragmatičan i usmjerio se na modele/obrasce manjeg opsega u obliku idioma, arhetipa, kao i ponekih apstraktnih, ali upotrebljivih obrazaca vezanih za domenu. Raniji pokušaj katalogiziranja obrazaca modeliranja podataka po strukturi je (Chmura 2005). Silverstin (2009) je odmah postao utjecajan u industriji zbog tri razloga: a) obrasci su povezani sa univerzalnim modelima podataka (Silverstin 2001), b) klasificirani su prema funkcionalnoj kategoriji i c) prikazani su u evoluciji pri povećanju razina generalizacije. U OO zajednici, koristan katalog, temeljen na meta-ulogama za specifikaciju obrazaca, takoñer je predložio mjeru gustoće obrazaca. Najnoviji radovi, (Silverstin 2009) i (Blaha 2010), predstavljaju iscrpni empirijski materijal. Jasno je da, u usporedbi sa količinom radova u programskom oblikovanju obrazaca, obrasci modela podataka trebaju daljnju sistematizaciju. Upravo ovaj jaz je motivirao naš rad.


3. OKVIRI ZA APSTRAKCIJU MODELA

Započnimo pitanjem, koja razina apstrakcije se očekuje za OMP specifikaciju? Odluka se može bazirati na analizi uspostavljenih referentnih okvira, MOF (od MetaObject Facility) i IRDS (Information Resource Dictionary System). 1997. godine MOF 1.1. je izrañen kao četvero-slojna arhitektura, a najnovija verzija je 2.0 (OMG 2006). Ona pruža metamodel na vršnom sloju, a zove se M3 sloj. Ovaj M3 model je jezik koji koristi MOF kako bi izgradio metamodele, koji se zovu M2 modeli. Najistaknutiji primjer modela sloja 2 MOF je UML (Unified Modeling Language) metamodel, model koji opisuje sam UML. Ovi M2 modeli opisuju elemente M1 sloja, a time i M1 modele. Ovo bi, na primjer, bili modeli napisani u UML-u. Posljednji sloj je M0 sloj ili podatkovni sloj. Koristi se kako bi se opisali stvarni (real-world) objekti. Ova okvirna struktura direktno slijedi ISO IRDS (ISO/IEC 10027:1990 Information technology - Information Resource Dictionary System (IRDS) framework), ali je popularnija danas nego IRDS, pa ćemo je koristiti kao referentnu arhitekturu za apstrakcijske slojeve (M-0 do M-3) kako bi uspostavili temelj za opću definiciju OMP-a. Definiranje metamodeliranja i metamodela u kontekstu modeliranja podataka pomaže u uspostavljanju apstrakcijskih slojeva za modele. Ovdje koristimo pojam metamodel koji se odnosi na meta-podatkovni model, a metamodeliranje je definirano kao proces modeliranja koji se odvija na jednoj razini apstrakcije više nego što se obično koristi pri modeliranju procesa u razvoju aplikacije.

4. SPECIFIKACIJA OBRASCA MODELA PODATAKA

Zajednica programskih obrazaca danas prepoznaje potrebu za rigoroznom, strogom specifikacijom obrazaca koja omogućuje automatizaciju praćenja i refaktoriranja obrazaca, te znanstvene koristi u istraživanju koje uključuje korištenje obrazaca. Najvažnija za našu namjenu (specifikacija obrazaca modela podataka) je vizualna (apstraktna UML statična temeljena na modelu) rigorozna specifikacija koja se postiže korištenjem RBML ((meta) Role-Based Modeling Language), pristup M2 MOF apstrakcijskih razina, sa eksplicitnim konceptima pravila i točkama proširenja. Razina apstrakcije prikladna za rigoroznu specifikaciju obrazaca modela podataka mora biti veća od razine realizacije modela podataka koji koristi takav obrazac. Te realizacije su vjerojatno pravi modeli za implementaciju kao baze podataka za neku primjenu, ili bi mogli biti repozitorij za Case alate. U principu, mogu biti i samo konceptualni modeli za

raspravu. Za sada, ovo se podudara sa praksom rigoroznih specifikacija obrazaca programskog oblikovanja u prezentiranju obrazaca koristeći meta-uloge (ne tip, i sigurno ne klasu – implementaciju tipa); tipovi modela podataka za prikaz obrazaca će onda biti meta uloge (predlošci) za tipove u realizaciji. Sada se postavlja pitanje odabira vizualnog formalizma za prikaz modela podataka na razini meta-uloge (tj. obrasce modela podataka). U slučaju obrazaca programskog oblikovanja, rješenje je koristiti specijalizacije UML metamodela (poput RBML) i ograničenja koja strogo odreñuju ponašanje. Za situaciju modela podataka, izvršna specifikacija bi mogla biti u bilo kojoj notaciji modela podataka koja se može formalno (automatski) prevesti u jedinstveni prikaz za relacijski model (relacijsku bazu podataka u većini situacija u oblikovanju baze podataka/skladišta podataka). U praksi modeliranja podataka, koristile su se Chenove varijacije, Bakerova, UML, IE i Idef1X notacije. Za rigoroznu specifikaciju, najbolje bi bilo odabrati minimalnu notaciju, tj. model koji vizualno predstavlja ciljni relacijski model (odnosno, koristeći Idef1X standard s ograničenjem da se isključi M:M veza tako da se može generirati SQL DDL pomoću alata za podršku, poput Erwin-a, u stvari za bilo koji SUBP (sustav za upravljanje bazom podataka, engl. DBMS) temeljen na SQL-u. Čini se da je poželjni prikaz za rigoroznu specifikaciju obrasca baze podataka puno jednostavniji nego u slučaju njenog programskog ekvivalenta, jedino uz novi sporazum da se entiteti obrasca promatraju kao meta-uloge za realizaciju modelovih tipova entiteta (koji će se implementirati pomoću RDBMS tabele instanci klasa), pa gdje onda leži moguć razlog za negodovanje? Ekspresivnost modela nije baš prednost, kada je cilj ponovno ga upotrijebiti kada je to jednostavnije i bolje, a običaj (navika) blijedi u usporedbi sa jedinstvenim prijevodom u izvršni oblik za relacijski model.

Slika 1. Prikaz obrasca i modela

Slika 2. Primjeri brojanja veličine i složenosTi obrazaca


DIO ovdje definira ulogu sastavnog dijela uloge CJELINA, što je prikazano tipovima entiteta SOBA i HOTEL (skraćeno entiteti). Uzorak instanci realizacije mogu biti dva reda u tablici HOTEL, jedan za „Imperial“, a drugi za „Adriatic“, te njihovi odgovarajući redovi za sobe u tablici SOBA, npr. „101“ do „120“ za „Imperial“ i „1200“ do „1295“ za „Adriatic“. Svaki obrazac modela podataka može se jednostavno obilježiti brojem koncepata (uloga i veza) koji se koriste; najjednostavnija mjera Veličina (engl. Size) apsolutne vrste bio bi broj uloga entiteta plus broj veza, a u gornjem primjeru Veličina je 3. Veza generalizacije broji se jednom za svaku ulogu-podtip unutar svakog kriterija specijalizacije, plus jednom za svaki pojedini tip specijalizacije. Pored pojma veličine postoji i pojam složenosti. Pojam složenosti je teži i ovdje ćemo koristiti pojam složenosT (engl. ComplexitY ) za svojstvo komplementarno veličini, analogiju McCabe-ove složenosti. SloženosT se jednostavno može prikazati preko broja (rekurzivne veze (formiranje petlje) + broja specijalizacija) +1. Dodaje se jedan kako bi se izbjegla nulta složenosT za modele bez rekurzivnih veza ili specijalizacija. Prethodni primjer CJELINA-DIO je veličine 3 i složenosT 1. Intuitivno stanovište složenosti je uzeti u obzir „petlje“ i „izbore“, ali umjesto ciklomatskog broja (kojeg koristi McCabe), naša 'složenosT' je lakša za brojanje. Obrasci A i B prikazani su na slici 2.

5. TAKSONOMIJA I UZORAK IZ KATALOGA OBRAZACA

Očito je da OMP, kao i drugi modeli, može imati različite veličine. Ono što je manje očito je kako prepoznati kriterije za grupiranje. Naša iskustva sa industrijski snažnim modeliranjem podataka od rane 1984. godine u proizvodnji generaliziranih rješenja modela podataka, prirodno vode prema razmatranju apstrakcija (i onih širokog opsega) koje se ponovno mogu koristiti kao obrasci, a ponovno korištenje obrazaca pomoću generalizacije već raspodijeljenih obrazaca, javilo se samo po sebi. Simptomatsko je da su agregacije usmjerene na proces bile namjerno oblikovane apstrakcije, kako bi se integrirali podaci tijekom planiranja IS po principu od gore prema dolje, za vrlo složen industrijski sustav, npr. u brodogradilištu „3. Maj“ (desetljeće prije dimenzionalnog modeliranja). Ovaj pristup „generalizacije“ pomogao je usavršiti ideje u dvoaspektni organizacijski okvir, tj. taksonomiju.

Ova taksonomija se može nazvati i SL, a cilj joj je sistematizirati (apstraktne) obrasce iz različitih izvora,

pošto se lako mogu mapirati, po veličini, i još važnije kada se usporede, prema razini. Glavna dodatna snaga SL taksonomije je da se može koristiti u obrazovanju i treningu za ubrzanje krivulje učenja za modelatore podataka. U biti, težak je (kreativan) problem odabrati primjenjive obrasce u bilo kojoj situaciji. Zajednica obrazaca bila je uspješna u imenovanju i prikazu obrazaca kao rješenja za ponavljajuće probleme (u kontekstu). Ovo je uspješno proširilo rječnik oblikovanja i modeliranja, ali ovaj pristup pomalo proturječi intuiciji. U zajednici baza podataka/skladišta podataka gdje se obrasci jednom (razumiju i) zapamte kao konfiguracije, može se koristiti slobodno u bilo kojem kontekstu. To nije slučaj sa programskim obrascima gdje je bihevioralni aspekt najbitniji.

Iz iskustva voñenog iscrpnim proučavanjem literature, samo je nekoliko kategorija prepoznato i odabrano ovdje, sa već utvrñenim nazivljem, za kategorizaciju obrazaca prema veličini:

a) Idiomatski predlošci, tj. Mini predlošci (sastoje se od nekoliko entiteta i veza), i Arhetipi, generalizacije skromne veličine, korisnih kategorija ili dimenzija poput: organizacije, stranke, proizvoda, uloge, pozicije, vremena, lokacije, adrese, klasifikacije, tezaurusa, dokumenta, pravila, itd. u veličinama <= 12.

b) Obrasci srednje veličine (neki od njih su usavršeni u tzv. 'Seed' modele (sjemeni modeli)) su modeli „funkcionalnih jedinica“ interesa za zajedničke procese, a razvijeni su putem generalizacije ili kao metamodeli (primarno razvijeni za automatizaciju) iz zajedničke aplikacijske domene, ali s namjenom za šire korištenje prema analogiji – primjeri uključuju praćenje resursa, testiranje, planiranje, odreñivanje budžeta, promjene u inženjeringu, itd). Veličina <=24.

c) Referentni modeli (standardizirani) većeg opsega (dovoljno je osvrnuti se na Silverstone-ov Svezak 1 (zajednički modeli) i Svezak 2 (univerzalni industrijski modeli) i standardizirane (referentne) industrijske modele poput Retail, Telecom, Petroleum, BBC media, i slične) ili univerzalni modeli podataka za prilagodbu putem razrañivanja, specijalizacije ili često pojednostavljenja putem eliminacije neprimjenjivih elemenata. Ovi veliki modeli se općenito ne promatraju kao obrasci te posebno zbog njihove veličine i ponekad vlasničke prirode, odlučili smo za sada ne uvrstiti njihov prikaz (Silvestin-ov Svezak 1 i 2) vidi i reference od

Tablica 1. Uzorak idiomatskih predložaka nevezanih uz domenu

P# Ime Veličina SloženosT Primjer Proširenje 1 Relation 1 1 Directory *key, *atttr 2 Full Ring 2 2 *key, *atttr 3 Recursion 2 2 *key, *atttr 4 Whole-part 3 1 Hotel-room *key, *atttr 5 Membership 3 1 Convoy * subtypes 6 DLL 3 3 Token ring 7 BOM 4 1 Assembly *key, *atttr 8 ISO 4 2 Subset * subtype 9 MM 5 1 Allocation *key, *atttr

10 Composite 5 3 *subtypes 11 MMR 6 3 *key, *atttr 12 Power Type 7 2 Classification *subtypes 13 TMR 8 2 *key, *atttr 14 Star 9 1 4 dimensions *entities 15 DRL2 9 2 Dec Role L. 2


(Jovanovic 200x). Veliki OMP dolaze u veličini 25 i preko. U ovom trenutku to je samo nagañanje, ali mislimo da su jako velike veličine obrazaca, preko 100 i više, moguće.

Sada je pitanje kako sistematično katalogizirati OMP; odlučili smo se za minimalan skup potrebnih karakteristika, a to su: a) Ime, Veličina i Složenost b) Strukturalna vizualizacija u IDEF1X sa naznačenim

točkama proširenja/smanjenja c) Verzije, sa generalizacijskom razinom/opsegom

upotrebljivosti obrasca – kada je to moguće d) Primjeri – često i povremeno e) Uzorci sadržaja baze podataka – kada je naznačeno

da je potrebno detaljnije shvaćanje

U tablici 1. prikazani su neki opći obrasci s vrijednostima navedenih karakteristika.

6. ZAKLJU ČAK

Obrasci modela podataka obećaju poboljšano (brže i kvalitetnije) modeliranje, ali postoje objektivne prepreke za prodiranje velikih razmjera. OMP treba slične alate podrške i razvoja kako bi se ostvario pomak naprijed prema najboljim programskim obrascima; zajednica koja dijeli OMP rječnik treba se proširiti, a najvažnije, treba poboljšati obrazovanje i trening.

Naš rad se trenutno fokusira na empirijsko proučavanje korištenja obrazaca i rudarenja podataka. Unutar ovog smjera potvrñujemo metriku modela podataka. Jedna prednost pri mjerenju veličine, kakvo je prikazano u ovom radu, je da kada se primjeni na bilo koju realizaciju, tj. model podataka, može dovesti do jednostavnije mjere gustoće obrazaca, u usporedbi sa drugim mjerama (Riehle 2009).

Literatura:

1 J. Arlow, I. Neustadt, “Enterprise Patterns and MDA- Building better software with archetype patterns and UML”, Addison Welsey, 2004.

2 R. Baker, “CASE*Method Entity Relationship Modeling”, Addison Wesley, 1990.

3 M. Blaha, “Patterns of Data Modeling”, CRC Pres, 2010.

4 T. Bruce, ”Defining Quality Data Models with IDEF1X Information Models”, Dorset House, 1992.

5 J. Carlis, J. Maguire, “Mastering Data Modeling” Addison Wesley, 2001.

6 A. Chmura, J. Heuman, “Logical Data Modeling”, Springer, 2005.

7 P. Coad, “Java Modeling in Color”, Prentice Hall, Yourdon Press, 1999.

8 B. Douglass, “Real-Time Design Patterns”, Addison Wesley, 2003.

9 E. Evans “Domain-Driven Design, Addison Wesley, 2004.

10 H. Ferreira, F. Correia, L. Welicki, “Patterns for Data and Metadata Evolution in Adaptive Object-methods”, PLoP, 2008.

11 M. Fowler, “Analysis Patterns - Reusable Object Models”, Addison Wesley, 1997.

12 R. France et all, “Metarole-Based Modeling Language (RBML)”, Specification 1.0, Colorado State University, 2003.

13 H. Gamma, et all “Design Patterns - Elements of Reusable Object Oriented Software”, Addison Wesley, 1995.

14 Y. Gueheneauc, “DeMIMA: A Multi Layered Approach to Design Pattern Identification”, IEEE TSE, 2008.

15 D. Hay, “Advanced Data Modeling Patterns”, 1997, online article

16 D. Hay, “Data Model Patterns - Metadata Map”, MK, 2009.

17 D. Hay, “Data Model Patterns”, Dorset House, 1996.

18 V. Jovanovic, “Taxonomy of Data Modeling Techniques”, SEIS, 2007.

19 V. Jovanovic, “Teaching Agile Data Model Validation”, SIGITE, 2009.

20 V. Jovanovic, et all, Artist CASE tool documentation and technical papers (most not available in English) 1985-1991.

21 D. Kim, “A Role-Based Metamodeling Approach to Specifying Design Patterns”, IEEE COMPSAC, 2003.

22 Kotteman, Kosynski “Dynamic meta-systems for information systems development”, Proc. 5th Intl. Conference on IS, 1984.

23 A. Lauder, S. Kent, “Precise Visual Specification of Design Patterns”, ECOOP’98, LNCS 1445 Springer, Verlag, 1998.

24 J. Nilsson, “Applying Domain-Driven Design and Patterns”, Addison Wesley, 2006.

25 NIST 500-201, “Reference model for frameworks of Software Engineering Environments”, draft Technical Report of ECMA TR/55 1990.

26 J. Odell, “Advanced Object-Oriented Analysis & Design Uisng UML”, SIGS, 1998.

27 OMG MOF 2006, online

28 D. Riehle, “A Role-based Design Pattern catalog of Atomic and Composite Patterns Structured by Pattern Purpose”, Ubilab Technical Report 97-1-1, Zürich, Union Bank of Switzerland, 1997.

29 D. Riehle, “Design Pattern Density Defined”, ACM SIGPLAN Notices, 2009.

30 T. Schanz, C. Izurieta, “Object-Oriented Pattern Decay: A Taxonomy”, ESEM’10, Bolzano-Bozen, 2010.

31 L. Silverstin, “The Data Model Resource Book Volumes I & II”, 1999. and the revised edition John Wiley, 2001.

32 L. Silverstin, P. Agnew “The Data Model Resource Book- Volume 3, Universal Patterns for Data Modeling”, John Wiley, 2009.


33 L. Starr, “How to Build Class Models”, Prentice Hall, 2002.

34 L. Starr, “How to Build Shlear - Mellor Object Models”, Prentice Hall, 1996.

35 R. Welke, “The CASE Repository: More than another database application”, Proceedings of 1988 INTEC Symposium Systems Analysis and Design: A Research Strategy, Atlanta, Georgia, Cotterman, W.W. and J.A. Senn (eds.), Georgia State University

36 P. Wisse, “Metapattern - Context and Time in Information Models”, Addison Wesley, 2001.

37 S. Yacoub, H. Ammar, “Pattern-Oriented Analysis and Design” Addison Wesley, 2004.

Podaci o autorima:

dr. Vladan Jovanovi ć Georgia Southern University, Statesboro GA, SAD E-mail: [email protected]

Vladan Jovanovic received all degrees from the University of Belgrade (Serbia and Montenegro): BE in 1975, MS in 1979, and PhD in Software Engineering in 1982. He is a tenured Professor of Computer Sciences at the Georgia Southern University, USA. Dr. Jovanovic is a member of the IEEE, ACM, AIS, and NY Academy of Sciences. He coauthored six books, 30 journal articles and 65 publications in refereed proceedings. Research interests: systems design methods, standards, and curriculum development in all areas of IT.

dr.sc. Mile Pavli ć Odjel za informatiku, Sveučilište u Rijeci Omladinska 14, Rijeka, Hrvatska E-mail: [email protected] Mile Pavlić je redovni profesor na Odjelu za Informatiku Sveučilišta u Rijeci. Autor je šest knjiga i više od 40 članaka. Primio je priznanje i zlatnu značku za postignute zapažene rezultate u primjeni, širenju i unapreñenju informatičke djelatnosti u Hrvatskoj 1987. godine. Hrvatska informatička zajednica dodijelila mu je «Plaketu informatike '93» za širenje i unapreñenje informatičke struke. U području projektiranja informacijskih sustava i metoda informatičkog inženjeringa održava od 1986. do danas seminare za potrebe gospodarstva kao dopunsko obrazovanje odraslih. Područja interesa su mu analiza poslovnih sustava, modeliranje poslovnih procesa, modeliranje podataka i programsko inženjerstvo.

Martina Ašenbrener Odjel za informatiku, Sveučilište u Rijeci Omladinska 14, Rijeka, Hrvatska E-mail: [email protected]

CASEmobile - MOBILNE RAZVOJNE TEHNOLOGIJE I RJEŠENJA 93

USPOREDBA RAZVOJA MOBILNE APLIKACIJE NA NOKIA QT I MICROSOFT WP7 PLATFORMAMA

COMPARING THE DEVELOPMENT OF MOBILE APPLICATION ON NOKIA QT AND MICROSOFT WP7 PLATFORMS

mag.inf. Zlatko Stapi ć, Josip Vincek, Zoran Šaško, Miroslav Zver

SAŽETAK:

Globalna popularnost nekoliko različitih platformi za razvoj aplikacija za mobilne ureñaje rezultirala je činjenicom da razvojni timovi sve češće razvijaju sustave koji na istoj servisno orijentiranoj infrastrukturi poslužuju više mobilnih aplikacija razvijenih za ureñaje pogonjene različitim operacijskim sustavima. Iako je u osnovi nemoguće „pomiriti“ razvoj za Nokia Qt podržane ureñaje i Microsoft Windows Phone 7 podržane ureñaje, ovaj rad prikazuje sličnosti i razlike spomenutih platformi na primjeru razvoja sustava za geo-lokacijski podržano kupovanje. Rad predstavlja i opisuje spomenute platforme, te ističe ključne elemente razvoja aplikacije u jednom i drugom razvojnom okruženju.

ABSTRACT:

The overall popularity of a several different platforms for the mobile phones application development has resulted in the fact that developers are increasingly developing systems with a single service oriented infrastructure serving multiple applications developed for a mobile devices powered by a various operating systems. Although it is basically impossible to "reconcile" the development for the Nokia Qt supporting devices with the development for the Microsoft Windows Phone 7 supporting devices, this paper shows similarities and differences between these platforms and is based on the example of development of geo-location supported purchase enhancement software. The paper will describe these platforms, and point out key elements of developing applications in both development environments.

1. UVOD

Projekt SmartBuy nastao je iz ideje da se kupcima olakša potraga za proizvodima koji su trenutno na akciji, a nalaze se u korisnikovoj blizini. Prije pojave Internet trgovina (engl. web shop) traženje jeftinog proizvoda svodilo se na hodanje od dućana do dućana i često na vožnju po cijelom gradu. Nakon što su se pojavile Internet trgovine, taj proces se olakšao jer se ponuda i cijene proizvoda mogu provjeriti preko Interneta. Ipak, još uvijek veliki broj trgovina nema vlastitu Internet stranicu, a osim toga jako je teško pratiti i biti informiran o svim akcijama. Upravo zbog toga, ideja vodilja projekta SmartBuy je omogućiti potragu za jeftinim proizvodima u blizini na temelju naše trenutne geolokacije.

Arhitektura SmartBuy sustava je prikazana na slici 1. Sustav se sastoji od web servera (na kojem se nalaze web servisi), servera sa bazom podataka MSSQL 2008 R2, web i mobilne aplikacije te od pružatelja usluga za mape. Kod izbora baze jedan od važnih kriterija je bila i podršku za spremanje i pretraživanje geolokacijskih podataka. Kako MySQL trenutno ima nerazvijenu podršku za pohranu geolokacije, odabrali smo MSSQL 2008 R2. Web aplikacija nam služi za administriranje baze podataka, te je isto tako isporučujemo zainteresiranim prodavaonicama kako bi mogle u bazu upisivati proizvode koji su trenutno na akciji. Naravno, tim prodavaonicama prethodno kreiramo korisnički račun pomoću kojeg se netko od zaposlenika može ulogirati u aplikaciju i ažurirati popis proizvoda na akciji i potrebne detalje o proizvodu i samom iznosu popusta.

U ovom radu pokazat ćemo usporedbu razvoja spomenute mobilne aplikacije na dvije bitno različite platforme. Upoznajući čitatelja sa Nokia QT razvojnim

okruženjem i sa Microsoft Windows Phone 7 razvojnim okruženjem, ovaj rad ima za cilj prikazati prednosti i nedostatke spomenutih platformi, ali i u kratkim crtama prikazati sve bitne elemente razvoja aplikacije koja se oslanja na prikazanu servisno orijentiranu infrastrukturu.

2. NOKIA QT

Sve bržim razvojem tržišta pred programere se postavljaju i sve značajniji zahtjevi za razvoj programskog proizvoda koji će moći raditi na više platformi. Kako bi ispunili ovaj zahtjev, programeri moraju pronaći jedinstveni okvir (engl. framework) koji će sadržavati biblioteke klasa za omogućavanje rada programa na različitim platformama. QT aplikacijski okvir, koji sadržava razvojne alate i C++ biblioteke klasa, pruža stabilno okruženje u kojem razvojni programeri mogu kreirati bogata, vizualno atraktivna korisnička sučelja koja se prilagoñavaju najnovijim platformama i internetskim tehnologijama.

Pristupom „napiši jednom, izvršavaj bilo gdje“ QT C++ okvir na temelju jednostavnog prevoñenja programskog koda (engl. recompilation), stvara aplikacije koje mogu raditi na Windows, Mac OS X, Linux, Solaris, HP-UX te na mnogim verzijama Linux operacijskog sustava. QT aplikacije se isto tako mogu izvršavati na različitim verzijama ugrañenog (engl. embedded) Linux-a, Symbian-a ili na Windows CE platformama.

Prva verzija QT je izdana 1994. godine, kao skup C++ razvojnih alata i C++ biblioteka klasa te je od tada evoluirao u potpuno novi oblik sa vlastitom integriranom razvojnom okolinom i SDK-om. QT aplikacije se razvijaju u QT Designer alatu koji zapravo predstavlja prilagodljiv alat za razvoj korisničkog sučelja. Snaga QT okvira se

94 CASEmobile - MOBILNE RAZVOJNE TEHNOLOGIJE I RJEŠENJA

nalazi u bogatom skupu biblioteka koje pružaju razvojnim programerima mogućnost razvoja grafičkog sučelja (engl. graphical user interface - GUI), dohvaćanje i spremanje podataka u različite baze podataka (Oracle, Microsoft SQL Server, IBM DB2, PostgreSQL, MySQL, Borland Interbase, SQLite, Adaptive Server te ostale baze podataka prilagoñene prema ODBC), komunikaciju preko mreže (pokretanje web stranica, pozivanje web servisa i sl.), multimedijske mogućnosti, razvoj 2D i 3D grafičkih elemenata, ECMAScript, web programiranje te složene XML operacije (SAX i DOM klase za učitavanje i manipuliranje podacima spremljenim u XML formatu) [7].

QT takoñer uključuje bogati skup „kontrola“ (engl. widgeta) u razvojnim okruženjima za Windows, koji pružaju standardnu funkcionalnost grafičkog sučelja. U QT je uključen inovativni koncept za komunikaciju izmeñu objekata, pod nazivom „signals and slots“, odnosno signali i slotovi, kojima se zamjenjuje zastarjeli i nesiguran način povratnih poziva koji je prisutan kod nekih starijih (engl. legacy) okvira. QT isto tako pruža konvencionalni model za upravljanje korisničkim ili automatski pokrenutim dogañajem.

QT aplikacije mogu proširiti svoju funkcionalnost uključivanjem različitih plugin komponenata (npr. upravljački program za bazu podataka, stilovi, različite kontrole i sl.) ili dinamičkih biblioteka. Za razvoj aplikacija koje trebaju podržavati višejezičnost, postoji i alat QT Linguist.

Prednosti ovog razvojnog okruženja su [3]: � Jedinstveni programski kôd koji se izvršava na

različitim platformama – QT aplikacija i UI okvir pružaju mogućnost implementacije programskog koda sa jedne ciljane razvojne platforme (poput platforme za stolna računala), na drugu (poput ugrañenog OS-a) bez potrebe za ponovnim prilagoñavanjem programskog koda za ciljanu platformu.

� Kraće vrijeme potrebno za lansiranje proizvoda na tržište – Prilikom razvoja aplikacije za instalaciju na različita okruženja, jedinstveni programski kôd ubrzava završavanje projekta u odnosu na ciljne platforme.

� Manji troškovi održavanja – Zbog jedinstvenog programskog koda za sve ciljne platforme, programer ne treba održavati sve programske proizvode za različite platforme već samo jedan programski proizvod, čiji programski kôd će se nakon odgovarajućeg prevoñenja moći izvršavati u ciljanoj platformi.

� Postizanje više sa manje – Velik broj klasa koje razvojnim programerima olakšavaju razvoj bogatih aplikacija.

Korištenjem QT okvira za razvoj mobilnih aplikacija postižu se značajne uštede u vremenu i resursima s ciljem olakšavanja odvijanja poslovnih procesa preko mobilne aplikacije.

3. WP7 PLATFORMA

Microsoft se bavi razvojem mobilnih platformi već petnaestak godina, počevši sa ureñajima baziranim na Windowsima CE, koji su svjetlo dana ugledali 1996. godine. Tijekom nekoliko godina, nastali sustavi počeli su konvergirati u Windows Mobile, vodeći se principom „dostavljanja“ osobnog računala u vaš džep. Nove funkcionalnosti koje su dodavane većinom su bile voñene potrebama samih ureñaja ili tehnologije, kao što je upravljanje samim ureñajem ili sigurnost. S vremenom takav je pristup počeo gubiti na popularnosti, a Windows Mobile počeo je gubiti teško stečeni tržišni udio. Sami ureñaji i korisničko sučelje bili su usmjereni na robusnost, umjesto da pružaju korisniku prilagoñen doživljaj [4].

U veljači 2010. godine Microsoft je na Mobile World Congressu otkrio potpuno novi sustav, sa promijenjenim imenom i novim pristupom mobilnoj tehnologiji.

Spomenuti operacijski sustav je nazvan Windows Phone 7, koji sa sobom donosi sasvim izmijenjenu filozofiju razvoja. To se odnosi kako na softverski tako i na hardverski dio platforme.

Microsoft je od same najave platforme odlučio uzeti konce čvrsto u svoje ruke i postaviti jasna ograničenja i pravila. Programeri i dizajneri aplikacija dobili su jasne

Slika 1. Arhitektura sustava


upute kako bi trebalo izgledati sučelje jedne Windows Phone 7 aplikacije. Glede toga, korisničko sučelje je temeljeno na dizajnerskom principu kojeg su u Microsoftu nazvali Metro. Cilj tog principa je kreirati doživljaj koji je prilagoñen svakom korisniku personaliziranim sadržajem (slika 2). Fokus je usmjeren na čistoću prikaza, brzinu i glatke animacije, integraciju hardvera i softvera te prezentiranje najvažnijeg sadržaja korisniku na njemu najprihvatljiviji i najlakši način. Microsoft je u svrhu postizanja tog cilja čak objavio i vodič [11] u kojem upisuje sve relevantne koncepte, pravila i „trikove“ koji mogu pomoći programerima i dizajnerima u razvoju takvih aplikacija.

S druge strane, i sami proizvoñači ureñaja koji će implementirati Windows Phone 7 operacijski sustav su dobili vrlo jasne upute u vezi minimalnih specifikacija koje moraju zadovoljavati. Kod ranijih izdanja (Windows Mobile) Microsoftovih mobilnih platformi minimalni hardverski zahtjevi su često bili preniski, kao i ograničenja prema ostalim zainteresiranim stranama (telekomunikacijskim tvrtkama, programerima i sl.), pa je kod spajanja svega toga u cjelinu krajnji proizvod često bio spor i nepouzdan, što se uglavnom pripisivalo samom operacijskom sustavu [5]. Microsoft je iskoristio priliku pri razvoju sasvim nove platforme i pažljivo isplanirao svaki aspekt koji može utjecati na zadovoljstvo krajnjeg korisnika. Neki od minimalnih hardverskih zahtjeva postavljenih pred proizvoñače ureñaja su sljedeći [4]: � Procesor od minimalno 1GHz � WVGA (480 x 800 px) prikaz � MultiTouch sposobnost ekrana (min 4 točke) � DirectX 9 � GPS, akcelerometar, kompas � Hardverske kontrole: Back, Start i Search � Mogućnost bežičnog povezivanja � 256 MB RAM i 8 GB memorije

U budućnosti se predviña i podrška za ekrane dimenzija razlučivosti 320 x 480 točkica [1], no u vrijeme objavljivanja platforme bila je moguća samo jedna rezolucija, što je uvelike olakšalo posao dizajnerima aplikacija.

Kao što je već nekoliko puta napomenuto, korisnički doživljaj je bio glavna nit vodilja kod razvoja Metro korisničkog sučelja. Dio te filozofije možemo vidjeti i na samom početnom ekranu ureñaja. Umjesto klasičnog

Start izbornika, korisnik vidi „pločice“ (engl. tiles) preko kojih pokreće aplikacije. No to nisu samo statične slike koje vas vode do aplikacija. One se cijelo vrijeme ažuriraju prikazujući korisniku informacije koje su njemu zanimljive i korisne. Osim toga, klikom na neku od pločica pokreće se animacija u kojoj se ona neznatno poveća, dok u isto vrijeme ostale pločice nestaju, a navigacija vas vodi na ciljanu aplikaciju. Konzistentnost prikaza je takoñer vrlo važna, tako da je kroz cijeli ureñaj voñen taj isti dizajnerski princip. Takvi detalji su ono što se u Microsoftu konstantno ističe kao sjajan korisnički doživljaj.

4. ELEMENTI RAZVOJA APLIKACIJE

4.1 Nokia QT elementi aplikacije

Prilikom razvoja QT SmartBuy aplikacije bilo je potrebno napraviti nekoliko formi aplikacije sa pripadajućim kontrolama za pokretanje aplikacijske logike. Prva forma koja se prikazuje ima za zadatak pružanje osnovnog sučelja sa glavnim funkcijama programa te služi za pokretanje funkcije startGPS() koja dohvaća GPS podatke (geografsku širinu i dužinu) trenutne lokacije mobilnog telefona. Za implementaciju dohvaćanja GPS podataka korišten je QtMobility API.

Tijekom procesa dohvaćanja GPS podataka, na glavnom prozoru aplikacije bit će omogućeno korištenje samo jedne kontrole, gumba za izlaz iz programa, sve do trenutka kada se dohvate GPS podaci te se tada omogućava korištenje svih ostalih kontrola. Na taj način se sprječava korištenje aplikacije, odnosno pokretanje njenih funkcionalnosti koje se temelje izmeñu ostalog na podacima o geografskoj širini i dužini, ukoliko ti podaci nisu prisutni u memoriji aplikacije.

U isječku programskog koda (1) prikazana je funkcija koja se poziva u trenutku dobivanja GPS signala.

Kontrole šalju signale prilikom okidanja odreñenog dogañaja. Tako na primjer, gumb će poslati signal clicked u trenutku kada je kliknut. Kako bi iskoristili signal koji označava da su GPS podaci dostupni, korišteno je povezivanje tog signala na funkciju positionUpdated, kao što je prikazano u programskom kodu (2).

Osnovno pretraživanje odvija se pozivanjem forme pod nazivom poslovnice kojem se prosljeñuju parametri: kriterij pretraživanja, geografska širina i dužina trenutne lokacije te maksimalni broj zapisa koje je potrebno pronaći. Ova forma koristi QtWebKit modul, odnosno kontrolu QWebView u kojoj se prikazuju poslovnice koje sadrže proizvod za kojim je pokrenuto pretraživanje (kriterij pretraživanja) pozivanjem PHP skripte koja sadrži markere na Google Mapi kao pozicije poslovnica. Udaljenoj PHP skripti se kroz parametre šalju nazivi poslovnice, geografska širina i dužina.

Kako bi implementirali funkcionalnost dohvaćanja podataka o poslovnicama koje sadrže traženi proizvod koristili smo ASP.NET web servis. U formi za prikaz poslovnica je isto tako korištena funkcija za dohvaćanje GPS lokacije te je definirano kako će se prikaz poslovnica u GoogleMapi osvježiti ukoliko se pozicija korisnika aplikacije promijeni za više od 100 metara. Na ovaj način smo postigli ažuriranje podataka ukoliko korisnik aplikacije mijenja svoju poziciju (na primjer ukoliko korisnik hoda ili se vozi u automobilu).

Slika 2. Osnovni WP7 izgled


Kako bi se uspješno moglo implementirati brisanje markera na PHP skripti koja prikazuje poslovnice preko GoogleMap tehnologije, za ponovno dodavanje ažuriranih lokacija poslovnica, potrebno je u konstruktoru forme omogućiti pozivanje JavaScript funkcija kako je prikazano u programskom kodu (3).

Kao što je već spomenuto, korišteni su ASP.NET web servisi za dohvaćanje podataka o poslovnicama, proizvodima poslovnica te o detaljima proizvoda. Funkcija PokreniPretrazivanje poziva odgovarajući web servis sa pripadajućim parametrima kao što je prikazano u kodu (4).

Nakon što se preko web servisa dohvate podaci, poziva se funkcija getResponse, koja je registrirana uz signal responseReady, a koja omogućava prikaz dohvaćenih podataka u odgovarajućoj kontroli. Taj element funkcionalnosti je prikazan u programskom kodu (5).

Na sličan se način pokreću web servisi koji vraćaju popis akcija u blizini korisnika ove aplikacije, napredno pretraživanje, dohvaćanje podataka o proizvodima odabrane poslovnice te dohvaćanje podataka o odabranom proizvodu.

Kako bi se dohvaćeni podaci o poslovnicama ispravno prikazali u tablici (odnosno u kontroli za prikaz podataka u tablici, QTableView), korištena je klasa QStandardItemModel kojoj se podaci dodaju kao u tablicu. Na ovaj način, podaci se vrlo lako mogu prikazati u kontroli QTableView te se može pristupati poziciji odabranog podatka, što je važno za pokretanje forme za prikaz detalja proizvoda koji izmeñu ostalih parametara konstruktora zahtijeva i redni broj poslovnice u kojoj se traži proizvod. Prilikom dohvaćanja podataka sa web servisa i prikaza na formi, postojao je problem oko prikazivanja hrvatskih znakova što je riješeno korištenjem funkcije Qstring::fromUTF8, kao što je

void Poslovnice::PokreniPretrazivanje() { QtSoapMessage request; QtSoapHttpTransport http; connect(&http, SIGNAL(responseReady()), this, SLOT(getResponse())); request.setMethod("VratiPopisPoslovnica","http://tempuri.org/"); request.addMethodArgument("latitude", "", GeoLatitude); request.addMethodArgument("longitude", "", GeoLongitude); request.addMethodArgument("kriterijPretrazivanja", "", kriterij); request.addMethodArgument("brojZapisa", "", broj); http.setHost("smartbuy-project.com"); http.setAction("http://tempuri.org/VratiPopisPoslovnica"); http.submitRequest(request, "/servisi/PoslovniceWebServis.asmx"); }

Kôd 4. Poziv web servisa

ui->webView->settings()->setAttribute(QWebSettings::JavascriptEnabled,true); ui->webView->settings()->setAttribute(QWebSettings::LocalContentCanAccessRemoteUrls,

true);

Kôd 3. Omogućavanje JavaScript funkcionalnosti

QObject::connect(locationDataSource, SIGNAL(positionUpdated(QGeoPositionInfo)), this, SLOT(positionUpdatedHandler(QGeoPositionInfo)));

Kôd 2. Povezivanje signala i slotova

void MainWindow::positionUpdated(QGeoPositionInfo geoPositionInfo) { //provjera ispravnosti dohvaćene pozicije if (geoPositionInfo.isValid()) { //dohvaćanje trenutne pozicije QGeoCoordinate geoCoordinate = geoPositionInfo.coordinate(); qreal latitude = geoCoordinate.latitude(); qreal longitude = geoCoordinate.longitude(); //pretvaranje u tekstualni oblik QString GeoLatitude = (QString::number(latitude)); QString GeoLongitude = (QString::number(longitude)); } }

Kôd 1. Dohvaćanje GPS lokacije


prikazano u isječku programskog koda (6).

Razvoj QT SmartBuy aplikacije se temeljio na razvoju za mobilni ureñaj Nokia N97 mini, koji nam je služio i kao platforma za testiranje i daljnji razvoj, ali se mobilna aplikacija može izvršavati na drugim mobilnim telefonima koji sadrže Symbian operacijski sustav.

4.2 WP7 elementi aplikacije

Microsoft je 2006. godine, sa izlaskom .NET Frameworka 3.0 predstavio novi koncept u razvoju aplikacija. Izdan je Windows Presentation Foundation (WPF), novi grafički podsustav za prikaz korisničkih sučelja u aplikacijama. Jedna od ideja bila je jasno razdvojiti razvoj poslovne logike od razvoja korisničkog sučelja. Programeri poslovnu logiku najčešće razvijaju u programskom jeziku C#, dok je za korisničko sučelje Microsoft razvio novi deklarativni jezik – XAML (engl. Extensible Application Markup Language, čita se „zammel“). XAML se zasniva na XML (engl. Extensible Markup Language) jeziku i hijerarhijski prikazuje strukturu korisničkog sučelja. XAML je moćan jezik koji uz primarnu zadaću definiranja prezentacijskog sloja aplikacije ima i druge važne uloge i podržava nove koncepte. Pomoću XAML-a mogu se jednostavno definirati stilovi i predlošci kontrola korisničkog sučelja, omogućuje povezivanje podataka (engl. data binding), animacije, a aplikacije se na kraju izvršavaju kao upravljani kôd (engl. managed code), preko Common Language Runtime (CLR) sloja, što omogućuje laku integraciju i povezivanje sa ostatkom platforme. U 2007. godini izdana je prva verzija Silverlight projekta, koji je podskup WPF-a dizajniran za izvoñenje u web okruženju.

Voñen tim konceptima, Microsoft zapravo nije „izmislio“ nove tehnologije specijalno za Windows Phone 7

platformu. Jednostavno su primijenili postojeće razvojne okvire (engl. framework) [4]. Uključene su tehnologije .NET, Silverlight i XNA (korišten kod razvoja igara za Xbox platformu), a to u prijevodu znači da se u najviše scenarija kod razvoja Phone 7 aplikacija XAML-om definira korisničko sučelje, a poslovna logika se razvija pomoću C# programskog jezika. Loša strana upravljanog koda je što je on sporiji u odnosu na uroñeni (engl. native) kôd, no to je jedan od razloga zašto je Microsoft postavio relativno visoke hardverske zahtjeve pred Windows Phone 7 mobilne ureñaje.

Dvije najčešće spominjane značajke XAML-a u kontekstu razvoja za Phone 7 ureñaje su predlošci (engl. templates) i povezivanje s podacima. Primjer toga možemo vidjeti u XAML kodu (7).

Ovo je vrlo jednostavan primjer predloška, koji omogućuje dizajneru/programeru aplikacije da potpuno promijeni izgled neke komponente korisničkog sučelja bez da mijenja njeno ponašanje. U ovom primjeru umjesto standardnog izgleda kontrole Pushpin, koja se koristi kod označavanja lokacija kod prikaza na geolokacijskim mapama, koristimo vlastiti izgled koji uključuje jednostavnu crnu granicu sa zaobljenim rubovima (CornerRadius), unutar koje se prikazuje tekst (pomoću kontrole TextBlock). Vidimo i jednostavan primjer povezivanja podataka, koji je pridružen atributu Text kontrole TextBlock. Povezivanje nam omogućuje da deklarativno uspostavimo vezu izmeñu elementa korisničkog sučelja i nekog izvora podataka. Ovaj je koncept uistinu koristan i pruža nov način pristupu razvoja aplikacija sa gledišta povezivanja sučelja i pozadinskih podataka. Izvor podataka može se eksplicitno specificirati, a ako to nije slučaj, izvor se traži tako da se kreće prema hijerarhijski višim razinama sučelja (izvor se nasljeñuje od roditelja) sve dok se ne pronañe [2]. U primjeru iznad, povezivanje

<ControlTemplate x:Key="myPushPin" TargetType="my:Pushpin"> <Border BorderBrush="Black" BorderThickness="2" Width="40" Height="40" CornerRadius="5"> <TextBlock Text="{TemplateBinding Content}"></TextBlock> </Border> </ControlTemplate>

Kôd 7. Korištenje predložaka pri povezivanju s podacima

void Poslovnice::getResponse() { const QtSoapMessage &message = http.getResponse(); if (message.isFault()) { qDebug("Error: %s",

message.faultString().value().toString().toLatin1().constData()); } else { const QtSoapType &response = message.returnValue(); // postavljanje dohvacenih podataka u odgovarajucu kontrolu } }

Kôd 5. Dohvaćanje podataka sa web servisa

QString naziv = QString::fromUtf8(naziv_proizvoda);

Kôd 6. Korištenje hrvatskih dijakritičkih znakova u Qt-u


kao izvor podataka ima atribut Content, koji se može pronaći u pripadajućoj instanci izvornog tipa predloška (kontrola Pushpin). Nakon uspostavljanja te veze, svaki put kada se promijeni vrijednost Content atributa, promijenit će se i tekst pripadne instance kontrole. Sjajno svojstvo XAML-a je što je sve promjene moguće vršiti i u „pozadinskom“ C# kodu, tako da je izmeñu ostalog moguće izgled, sadržaj i svojstva kontrola mijenjati i tijekom rada same aplikacije.

Primjer možemo pokazati na upotrebi gornje personalizirane kontrole PushPin. Instancirat ćemo ga u samom XAML-u, a lokaciju na mapi i sadržaj teksta promijenit ćemo u pozadinskom C# kodu (8).

Predložak za ovaj primjer je nadograñen upotrebom plave boje za granicu kontrole, kao i gradijenta za pozadinu same kontrole. XAML kôd je u ovom slučaju dosta dulji pa nije stavljen radi preglednosti, no funkcionalnost i logika ostaje ista. Tu takoñer možemo vidjeti koliko je jednostavno mijenjati dizajn kontrola i aplikacije bez da to utječe na ostatak aplikacije (npr. poslovnu logiku). U C# kodu je lokacija kontrole na mapi postavljena na područje Zagreba (pomoću geografske širine i dužine), a sadržaj (Content) kontrole na slovo X. Pošto je u predlošku definirano da je tekst kontrole povezan sa tim sadržajem, on se takoñer automatski

mijenja. Predložak se u aplikaciji definira kao resurs, pa je on kontroli pridružen ključnom riječi StaticResource.

Vidjeli smo najvažnije elemente razvoja za Windows Phone 7 platformu, koja je uistinu široko područje. Kao primjer možemo spomenuti XNA koji se koristi za izradu igara na Phone 7 mobilnim ureñajima, a koji je još jedno široko područje za istraživanje. Tržište ureñaja kao i aplikacija za Phone 7 je još uvijek vrlo mlado ali je itekako pokazalo potencijala, tako da se može smatrati novim „velikim igračem“ na području mobilnih tehnologija, uz već dokazane Android i iOS sustave. Tome u prilog ide i objavljena suradnja Microsofta s još uvijek najvećim proizvoñačem mobilnih ureñaja, Nokiom,

čiji se dosadašnji operacijski sustav, Symbian, zadnjih godina pokazao inferiornim u odnosu na konkurenciju, i zbog čega Nokia već duže vrijeme ubrzano gubi tržišni udio na području tzv. pametnih mobilnih ureñaja (engl. Smartphone) [6].

1.3 Usporedba QT i WP7 razvoja

Qt skup alata za razvoj programa (engl. Qt Software Development Kit) programerima olakšava razvoj aplikacija na način da im omogućava da jednom napisanu aplikaciju isporuče (engl. Deploy) na više platformi. Ovaj skup alata namijenjen je pisanju desktop aplikacija za Windows, Linux i Mac OS X, te za pisanje mobilnih aplikacija namijenjenih Symbian i Maemo platformi [10]. Qt takoñer omogućuje programerima da im aplikacije budu spremne za nadolazeću MeeGo platformu [9].

Da bi se razvila aplikacija u Qt-u, potrebno je poznavati C programski jezik, dok za razvijanje aplikacije za Windows Phone 7 treba znati programirati u C#. Da bi bilo što lakše razvijati aplikacije, ureñivač koda u Qt SDK-u (Carbide) podržava izradu grafičkog sučelja po principu „drag & drop“. To znači da raspolaže sa već gotovim kontrolama koje jednostavo možemo odabrati u panelu sa kontrolama i „odvući“ na formu naše aplikacije. Baš u tom dijelu su Qt i WP7 slični zbog toga što Visual Studio (razvojno okruženje za WP7 aplikacije) takoñer ima panele sa ponuñenim gotovim kontrolama za izradu grafičkog sučelja aplikacije.

Osim navedenog, Qt i Windows Phone 7 su slični po tome što imaju odvojene datoteke za dizajn grafičkog sučelja od ostalog dijela aplikacije. U oba slučaja radi se o XML formatu. No, s druge strane tu postoji i velika razlika, a to je što Qt ne omogućava ureñivanje grafičkog sučelja direktnim ureñivanjem XML-a, dok je to kod Windows Phonea moguće. Kao što smo već spomenuli, za Windows Phone koristi se posebna verzija XML jezika, a to je XAML.

Izgled sučelja u Qt-u se može dodatno prilagoditi koristeći CSS stilove (engl. Cascading Style Sheets). Microsoft ovdje ima puno bolju podršku za prilagoñavanje sučelja, te je ono puno jednostavnije zbog toga što su XAML datoteke, u kojima se definira sučelje, jednostavne za ureñivati, pogotovo uz pomoć dodatka IntelliSense koji je ugrañen u Visual Studio. Microsoft takoñer nudi poseban alat za ureñivanje grafičkog sučelja aplikacija. Radi se o Expression Blendu. U njemu je moguće jednostavno otvoriti već prije kreiran Visual Studio projekt, urediti grafičko sučelje po svojoj želji, spremiti promjene i tada u Visual Studiu nastaviti sa programiranjem funkcionalnosti aplikacije.

Snaga Qt-a leži u njegovim aplikacijskim programskim sučeljima (engl. Application Program Interface – API), što nam omogućava da pišemo složenije aplikacije sa manje koda, a to dovodi i do veće brzine razvoja aplikacije. Najkorisniji paket API-a za razvoj mobilnih aplikacija su Qt Mobility API-ji. Tu spadaju programska sučelja za dohvaćanje podataka sa GPS-a, slanje SMS poruka i slično. Microsoft je ovdje za WP7 odlučio razviti tzv. servise za slične namjene, pa je tako moguće koristiti servise za akcelerometar i lokaciju (geolokacija) [1; 80]. Vrijedi spomenuti da se npr. poziv API-a za lokaciju kod Qt-a i poziv servisa za lokaciju kod Windows

Slika 3. Prikaz korisnički definirane kontrole

<my:Pushpin x:Name="myPin" Content="X" Template="{StaticResource myPushPin}" /> myPin.Location = new GeoCoordinate(45.8, 15.9); myPin.Content = "X";

Kôd 8. Izmjena sadržaja i svojstava kontrole


Phone 7 zapravo svodi na isto: pokreće se dretva koja konstantno provjerava trenutnu geolokaciju mobitela.

Vidjeli smo da postoji mnogo sličnosti i razlika izmeñu Qt-a i WP7, no važno je uočiti da su glavne sličnosti u tome što je grafičko sučelje odvojeno od programskog koda, te da obje platforme (Qt i Windows Phone 7) koriste dodatke (API-e ili servise) koji omogućuju jednostavnije korištenje raznih funkcionalnosti na mobilnim ureñajima, kao što je dohvaćanje geolokacije ureñaja.

5. ZAKLJU ČAK

Razvojem ovih aplikacija mnogo smo naučili o Qt-u i Windows Phone 7. Qt ima dobru podršku za mobilne platforme u obliku raznih API-a. Konstantnom nadogradnjom, svakom novom verzijom dostupno je nekoliko novih API-a, pa je tako od nedavno moguće koristiti API pod nazivom „maps and navigation“ (hrv. mape i navigacija). On se zasniva na dodacima (engl. plugins) pomoću kojih se komunicira sa raznim pružateljima usluga za mape, geokodiranje i odreñivanje puta [8]. Prije nekoliko mjeseci tog API-a nije bilo, pa su se mape morale koristiti na druge načine. Danas se,

zahvaljujući ovoj nadogradnji, lakše mogu razvijati aplikacije koje koriste mape i geolociranje. Isti je slučaj i sa drugim API-ima, te se daje naslutiti da će ovdje biti još puno novosti.

Windows Phone 7 je relativno nova platforma, pogotovo ako je usporeñujemo sa Qt-om, odnosno Symbianom. No, bez obzira na to, već sad se vidi da je ona na dobrom putu da postane jedna od omiljenih platforma developera, a najviše zbog načina na koji je odvojeno grafičko sučelje od programskog koda aplikacije. Takoñer jedan od razloga je i taj što se za razvoj aplikacija koristi programski jezik C# koji je već vrlo dobro poznat meñu programerima.

Na kraju, želimo se osvrnuti i na sâm trend porasta broja mobilnih aplikacija na tržištu. Smatramo da je ovo područje vrlo perspektivno i da pruža prilično velike mogućnosti. Najvažnije od svega je to što sada svi programeri koji razvijaju mobilne aplikacije i objavljuju ih na nekoj od trgovina (Ovi Store, App Store, Android Market, Windows Marketplace...) imaju jednake šanse za uspjeh. Sve što je potrebno jest znati dobro programirati i uz malo volje i inovativnosti može se napraviti kvalitetna aplikacija koju će koristiti velik broj korisnika.

Literatura:

1 Charles Petzold: Programming Windows Phone 7, Microsoft Press, Washington, 2010.

2 Christopher Bennage, Rob Eisenberg: Getting Started with Windows Presentation Foundation, Dzone, 2009.

3 Faster, More Cost-Effective Development Using the Qt Cross-Platform Application & UI Framework, Qt – Cross-platform applicaton and UI framework, 2009. Izvor: http://qt.nokia.com/files/pdf/faster-more-cost-effective-development-using-the-qt-cross-platform-application-ui-framework (učitano, 14.4.2011.)

4 Henry Lee, Eugene Chuvyrov: Beginning Windows Phone 7 Development, Apress, 2010.

5 Nick Randolph, Christopher Fairbairn: Professional Windows Phone 7 Application Development, Wiley Publishing, 2011.

6 Nokia and Microsoft Announce Plans for a Broad Strategic Partnership to Build a New Global Mobile Ecosystem, Microsoft Corporation, 2011. Izvor: http://www.microsoft.com/presspass/press/2011/feb11/02-11partnership.mspx (učitano, 5.5.2011.)

7 Nokia QT Whitepaper, Nokia Corporation, 2009. Izvor: http://qt.nokia.com/files/pdf/qt-4.6-whitepaper (učitano, 13.4.2011.)

8 Qt Mobility Project Reference Documentation, Qt – Cross-platform applicaton and UI framework, 2010. Izvor: http://doc.qt.nokia.com/qtmobility-1.1.3/location-overview.html (učitano, 06.05.2011.)

9 Qt Overview, Forum Nokia, 2011. Izvor: http://www.forum.nokia.com/Develop/Qt/ (učitano, 06.05.2011.)

10 Qt Reference Documentation: Qt SDK 1.1, Qt Online Reference Documentation, 2011. Izvor: http://doc.qt.nokia.com/sdk-1.1/index.html (učitano, 06.05.2011.)

11 UI Design and Interaction Guide for Windows Phone 7, Microsoft Corporation, 2010. Izvor: http://go.microsoft.com/fwlink/?LinkID=183218 (učitano, 14.4.2011.)

Podaci o autorima:

Zlatko Stapi ć, mag. inf. tel: +385 42 390 853 fax: +385 42 213 413 e-mail: [email protected] Zlatko Stapić, mag. inf. je od 2006. godine asistent na Katedri za razvoj informacijskih sustava na Fakultetu organizacije i informatike u Varaždinu, te polaznik poslijediplomskog doktorskog studija Informacijske znanosti na istom fakultetu. Njegova nastavna aktivnost je prvenstveno usmjerena na kolegije koji se odnose na programsko inženjerstvo, analizu i razvoj programa, modeliranje poslovnih procesa i razvoj informacijskih sustava, te značajne napore ulaže u radu sa studentima za što je dobio i posebna priznanja. Iz znanstvenog i stručnog rada treba izdvojiti višegodišnje voditeljstvo stručnih projekata razvoja programskih proizvoda i sudjelovanje na različitim stručnim i znanstvenim projektima iz područja razvoja, unapreñenja poslovnih procesa, projektnog menadžmenta i slično. U posljednje vrijeme se intenzivno bavi razvojem aplikacija za mobilne ureñaje, što je i predmet njegovog istraživanja u okviru doktorske disertacije, a osobito je vrijedno istaknuti da razvija za skoro sve platforme, uključujući izmeñu ostalog Android, Symbian te Windows Phone 7. Zlatkov detaljniji životopis, s popisom svih radova, projekata i nagrada, te drugih važnih podataka može se pronaći na njegovoj osobnoj web stranici, na http://www.foi.hr/djelatnici/zlatko.stapic.


Zlatko Stapić is a young researcher and teaching assistant at the Faculty of Organization and Informatics working at the Information systems development department. His main areas of interests include classic and agile software engineering methodologies, software and information systems development, business processes modeling and others.

Josip Vincek, univ. bacc. inf. e-mail: [email protected] Josip Vincek završio je Elektrostrojarsku školu u Varaždinu 2007. godine, smjer tehničar za računalstvo. Iste godine upisao je prvu godinu preddiplomskog studija na Fakultetu organizacije i informatike u Varaždinu kojeg je završio 2010. godine stekavši tako titulu prvostupnika informatike. Iste godine na matičnom fakultetu upisao je i diplomski studij, smjer Informacijsko i programsko inženjerstvo. Za rad na projektu „Odreñivanje karakterističnih otisaka slike dlana“ dobio je dekanovu nagradu. Područja interesa su mu razvoj aplikacija za stolne, web i mobilne platforme kao i praćenje modernih tehnoloških trendova u razvoju takvih sustava.

Zoran Šaško, univ. bacc. inf. e-mail: [email protected] Zoran Šaško je 2010. godine završio sveučilišni preddiplomski studij na Fakultetu organizacije i informatike u Varaždinu, smjer Informacijski sustavi. Iste je godine upisao diplomski studij smjer Informacijsko i programsko inženjerstvo. Kroz duži broj godina se bavi programiranjem web i desktop aplikacija, pa je iz afiniteta prema razvoju programskih rješenja započela i suradnja s kolegama na razvoju SmartBuy mobilne aplikacije. Osim programiranja za web i mobilne telefone, područje interesa mu je i internet marketing, odnosno promocija proizvoda i usluga preko interneta.

Miroslav Zver, univ. bacc. inf. e-mail: [email protected] Miroslav Zver je 2010. godine na Fakultetu organizacije i informatike u Varaždinu završio sveučilišni preddiplomski studij smjer Informacijski sustavi i stekao titulu prvostupnika informatike. Iste godine na FOI-u je upisao diplomski studij smjer Informacijsko i programsko inženjerstvo. Sa kolegama Šaškom i Vincekom sudjelovao je na natječaju Nokia Symbian Challenge, a iz te suradnje nastala je ideja za aplikaciju predstavljenu u ovom radu. U posljednje vrijeme bavi se izradom mobilnih aplikacija, ali zanima ga i web programiranje. Osim aktivnosti vezanih uz fakultet, unutar udruge LepoMAN (engl. Lepoglava Metropolitan Area Network) bavi se mrežnim tehnologijama. Fakultet organizacije i informatike

Pavlinska 2

42000 Varaždin


KAKO POVEZATI MOBILNE UREðAJE SA CLOUD-OM?

HOW TO CONNECT MOBILE APPLICATIONS AND CLOUD?

mag. ing. el. Tomislav Bronzin, Vedran Kaldi

SAŽETAK:

Mobility (mobilni ureñaji i aplikacije za mobilne ureñaje) i Cloud Computing (računarstvo u oblaku) dva su pojma koja su se nametnula kao vodeći trendovi u IT industriji danas. I jedan i drugi pojam implementiran u konkretnim tehnologijama svaki sa svoje strane pružaju krajnjim korisnicima dostupnost informacija, podataka i alata i to: bilo gdje, bilo kada i na bilo kojem ureñaju. Razvojem usluga i tehnologija koje integriraju mobilne ureñaje i računarstvo u oblaku postiže se maksimalno ostvarenje njihovog potencijala, te slobodno možemo reći da danas jedno bez drugog gotovo da ne može!

Ovaj rad će se jednako osvrnuti na scenarije upotrebe mobilnih ureñaja povezanih s uslugama (servisima) koji se nalaze negdje u računalnom oblaku, kao i na računalnu i mrežnu arhitekturu i tehnološku implementaciju.

Ključne riječi: mobilni ureñaji, računarstvo u oblaku, cloud, aplikacije za mobilne ureñaje

ABSTRACT:

Mobility (mobile devices and mobile applications) and Cloud Computing are two concepts which we can see as leading trends in IT industry today. Their implementation in specific technologies brings information, data and tools or applications to the customers: anywhere, anytime and on any device. By integrating services and technologies related to mobile devices with cloud computing the both will reach their full potential.

This paper will present user scenarios for integration of mobile devices and services that are implemented using cloud computing, but it will also explain architecture and technical background of mobile solutions implementations.

Keywords: mobility, cloud computing, mobile devices, mobile solutions

1. UVOD

U naslovu i sažetku se ponavljaju dva pojma: mobilni ureñaji i računarstvo u oblaku.

Što su mobilni ureñaji? Koje sve ureñaje možemo smatrati mobilnima i kako se postavlja granica mobilnosti nekoga ureñaja? Uobičajena je praksa da se mobilnim ureñajima smatraju ureñaji koji imaju sposobnost računala, a da su toliko mali da ih se može držati u ruci. Jednostavno, ali možda i prejednostavno jer je trend proizvodnje takav da se danas na tržištu nalazi cijeli niz različitih veličina pametnih telefona, tableta, razne verzije mini laptopa kao što su netbook i laptop-tablet hibrida. U svakom slučaju granica više nije tako jasno odreñena i možemo smatrati za bilo koji prijenosni ureñaj sa sposobnostima računala da pripada mobilnom računarstvu. Prijenosni u smislu da ga možemo koristiti bilo gdje i bilo kada, bez obzira na veličinu/format.

Što je računarstvo u oblaku, odnosno sveprisutni cloud computing? Cloud odnosno „oblak“ se kao oblik u shemama pojavljuje još i prije Internet doba, a oduvijek označava skup mrežnih resursa. Kasnije postaje uobičajena oznaka za Internet, odnosno oznaka za javne mreže gdje se podrazumijeva se da se kroz oblak na shemi komunicira u osnovi TCP/IP1 i HTTP2 protokolima. Danas pod pojmom računalstvo u oblaku, odnosno „cloud computing“, a u svjetlu svega navedenoga, podrazumijevamo da se radi o dostupnosti računalne infrastrukture putem Internet protokola (cloud) i

1 TCP/IP – definicija u prilogu rada - pojmovnik 2 HTTP – definicija u prilogu rada - pojmovnik

korištenje njezine aktivnosti (computing). Računalna snaga koja nam je potrebna za odreñene aktivnosti na ovaj se način može unajmiti i koristiti putem servisa, bilo da nam treba infrastruktura (Iaas – Infrastructure As A Service), platforma (PaaS – Platform As A Service) ili softver (SaaS – Software As A Service). Servis kojim je dostupna ova usluga mora se moći koristiti bilo gdje i bilo kada.

I u definiciji mobilnih ureñaja i računalstva u oblaku pojavljuje se rečenica o dostupnosti, te se ponavljaju fraze „bilo gdje“ i „bilo kada“. Mobilni računalni ureñaj omogućuje korištenje cloud computing usluga u punom obimu te daje dodatni smisao podizanju odreñenog IT sistema u računalni oblak. S druge strane cloud computing mobilnim aplikacijama i ureñajima donosi prednosti kao što su – visoko dostupni servisi za pristup svježim podacima, računalnoj snazi te korisnički podaci – možemo ponovno dodati bilo gdje i bilo kada, te sada kada ih imamo integrirane – možemo govoriti i još o jednom važnom aspektu – suradnji (kolaboraciji) na dokumentima i podacima u timovima.

2. MJESTO SUSRETA

Rad korisnika IT sustava danas se ne ograničava samo na jedan ureñaj. Niti na jedu vrstu ureñaja. Na poslu koristimo poslovni PC ili prijenosno računalo spojeno na tvrtkinu infrastrukturu. Iskoristimo slobodno vrijeme da bi pregledali TV program na web stranicama dobavljača usluge multimedije. Sa prijenosnim računalom sa drugih lokacija se spajamo na tvrtkinu infrastrukturu ulazeći u


VPN (Virtual Private Network)3. Nakon gašenja „velikih“ ureñaja prelazimo na mobilne ureñaje, pregledavamo web putem pametnih telefona, pregledavamo poslovnu e-mail korespondenciju, stvaramo i dijelimo privatne sadržaje. Sa mobilnog telefona na primjer postavljamo snimanje TV emisije jer nismo na vrijeme stigli kući. Na večer putem TV prijemnika nakon odgledane emisije možemo ostaviti svoje dojmove na društvenim mrežama.

Sve je danas umreženo na način da praktično iste ili slične akcije možemo napraviti na potpuno različitim ureñajima i potpuno različitim mjestima. Aplikacije iz različitih okruženja (pod ovo se misli i na različiti hardver i na različiti softver) danas donose iste funkcionalnosti i iste podatke. Usluga se prenosi i kao da putuje kuda i mi idemo. A sa sobom nosi i naš identitet, i naše postavke, i informacije koje želimo. I sve to pamti, te isti posao obavljamo kroz računalo u uredu, mobilni ureñaj na putu ili TV kod kuće.

Kako bi ovo gore bilo ostvarivo mora postojati mjesto susreta, mjesto suradnje, mjesto na kojem se zajednički dijele usluge. A to mjesto je „računalni oblak“ (cloud), odnosno računalstvo u oblaku (cloud computing).

Povezivanje na računalni oblak i iskorištavanje resursa „skrivenih“ u računalnom oblaku omogućuje dijeljenje informacija bilo gdje i bilo kada, veliku skalabilnost aplikacija, visoku dostupnost usluge, osiguranu sigurnost podataka u smislu dupliciranja i pohrane pričuvnih kopija. I puno više.

Široko rasprostranjena dostupnost standardnim protokolima pruža dostupni i standardni kanal za povezivanje na koji se spajaju ureñaji različitih namjena i porijekla. Iz čega proističe prisutnost iste usluge na velikom broju različitih ureñaja.

Najveću korist iz razvoja pružanja računalne snage kao usluge u računalnom oblaku izvući će upravo mobilni ureñaji. Uvijek u pokretu, uvijek na drugom mjestu, veliki broj različitih, ponajviše pametnih mobilnih ureñaja, postaju vrlo korisni i upotrebljavani zahvaljujući visokoj

3 VPN - definicija u prilogu rada - pojmovnik

dostupnosti servisa u računalnom oblaku. Osnovni osjećaj koji nam pruža veza mobilnih ureñaja i računalnog oblaka je upravo povezanost. Povezanost sa izvorima informacija, važnim vijestima, poslovnim dokumentima, sa zajednicom istomišljenika ili stručnjaka – gdje god išli i u bilo koje vrijeme.

Ukoliko pogledamo brojke porasta prodaje mobilnih ureñaja u svijetu te povežemo ovaj porast sa željenim modelima korištenja istih ureñaja, moći ćemo lako zaključiti da je računarstvo u oblaku sa svojom mogućnošću brzog skaliranja resursa postalo dostupno u pravo vrijeme, no isto tako da će se puna snaga ovih resursa-servisa iskoristiti u godinama koje dolaze.

Po izvještajima tvrtke Gartner, prodaja mobilnih ureñaja u 2010.g. porasla je za gotovo 20%, ali što je još važnije za kontekst ovog rada, u izvještaju stoji da je prodaja pametnih telefona narasla za (velikih) 50%!

Tabela 1: Podaci o prodaji mobilnih ureñaja krajnjim korisnicima u 2010 (u tisućama komada)4

Company 2Q10 Units

2Q10 Market Share (%)

2Q09 Units

2Q09 Market Share (%)

Nokia 111,473.8 34.2 105,413.4 36.8

Samsung 65,328.2 20.1 55,430.1 19.3

LG 29,366.7 9.0 30,497.0 10.7

Research In Motion 11,228.8 3.4 7,678.9 2.7

Sony Ericsson 11,008.5 3.4 13,574.3 4.7

Motorola 9,109.4 2.8 15,947.8 5.6

Apple 8,743.0 2.7 5,434.7 1.9

HTC 5,908.8 1.8 2,471.0 0.9

ZTE 5,545.8 1.7 3,697.9 1.3

G’Five 5,208.6 1.6 NA NA

Others 62,635.2 19.30 45,977.2 16.1

Total 325,556.8 100.0 286,122.3 100.0

A korisnici mobilnih ureñaja, u koje ubrajamo i pametne telefone, žele puno toga: svoje dokumente bilo gdje i bilo kada, svoje podatke i poslovne zadatke pa i cijela poslovna okruženja bilo gdje i bilo kada, naravno u sigurnom okruženju. Svoje obiteljske slike i filmove dostupne na mobilnim ureñajima, uz mogućnost dijeljenja sa svojim prijateljima i rodbinom. Žele informacije bilo koje vrste, svježe on-demand ili se žele pretplatiti na „žive“ obavijesti.

3. MOBILNI UREðAJ I RAČUNARSTVO U OBLAKU

Rijetko tko danas nosi dva mobilna ureñaja – jedan mobilni ureñaj za poslovnu, a drugi mobilni ureñaj za privatnu upotrebu. Većina tipičnih korisnika koristi jedan

4 Izvor podataka: Gartner, kolovoz 2010

Slika 1- Tri ekrana i računalni oblak – omogućuju

dostupnost usluga i podataka na različitim ureñajima i aplikacijama, a istovremeno omogućuju suradnju izmeñu

članova tima


mobilni ureñaj za dvostruku upotrebu: poslovnu i privatnu.

I poslovna i privatna upotreba mobilnog ureñaja vezana je sa upotrebom računalstva u oblaku, no razlikuju se načini povezivanja za ove dvije uloge, kao i usluge ili opcije koje korisnici žele i koriste ovisno u kojoj se ulozi (kao privatna osoba ili poslovni korisnik) nalaze.

Kada se mobilni telefon koristi za privatne svrhe, onda se tipično koriste javno dostupni servisi, poput komunikacije putem društvenih mreža, dijeljenje informacija sa prijateljima i obitelji, dijeljenje slika i videa putem javnih servisa, gdje su Facebook, Twitter, YouTube samo neki od najpopularnijih. Uz nabrojano, često korisnici pregledavaju računalnu poštu na javnim servisima kao što su Google ili Hotmail ili razmjenjuju dokumente putem SkyDrive ili DropBox servisa, a za zajednički rad na dokumentima koriste se javni servisi kao što su Office 365 ili Google Docs. Svi ovi javno dostupni servisi, koji se koriste i sa mobilnih ureñaja, nalaz se u javno dostupnom računalnom oblakom. Zbog sveg nabrojanog, vidi se da sve nabrojano pokriva pristup programskoj podršci kao usluzi što se može smjestiti i kategorizirati kao Software as a Service (Saas)5 načina iskorištavanja snage „Cloud“ infrastrukture.

Poslovna upotreba mobilnih ureñaja zahtjeva veću sigurnost komunikacije kod povezivanja mobilnih ureñaja i računalnog oblaka, ne svodi se samo na korištenje usluga/poslovnih aplikacija koje koriste samo SaaS način, već i druge načine.

Pružatelji usluga računalnog oblaka kao što je Windows Azure ili Amazon DB Services proširuju način korištenja svojih usluga računalnog oblaka i kao platforme i kao infrastrukture. I za poslovne uloge, usluge i aplikacije, Računalni oblak se koristi i kao PaaS (Platform as a Service)6 i IaaS (Infrastructure as a Service)7.

Često zakoni i/ili poslovna i sigurnosna pravila uvjetuju da se prilikom korištenja poslovnih aplikacija ne dozvoljava pohrana svih podataka u računalni oblak. S druge strane, zahtjevi za skalabilnošću i pouzdanošću

5 SaaS - definicija u prilogu rada - pojmovnik 6 PaaS - definicija u prilogu rada - pojmovnik 7 IaaS - definicija u prilogu rada - pojmovnik

jednostavno navode na postavljanje za rad kritičnih modula u računalni oblak. Drugi zahtjev se odnosi na potrebu da aplikacija bude dostupna u cijelom svijetu na optimalni način – dakle ponovno se tu nameće računalni oblak/platforma kao rješenje. Kada postoji zahtjev da se dio podataka mora ostati „kod kuće“, za takve scenarije se nude rješenja poput Azure Connect koji omogućuje sigurnu komunikaciju baziranu na IP-u, odnosno sigurnu povezanost resursa koji se nalaze u okruženje tvrtkine mreže sa resursima u računalnom oblaku, kreirajući jednu vrstu privatne virtualne mreže izmeñu aplikacije u računalnom oblaku i aplikacije u lokalnoj mreži. Na taj se način povezuju dva svijeta i pokrivaju sve opcije, a sve u cilju iskorištenja punog opsega infrastrukture u oblaku. Na ovaj način mobilni korisnici kao da ne izlaze iz lokalne mreže makar putovali na drugi kraj svijeta. Sama infrastruktura će se pobrinuti za visoku dostupnost i lakoću povezivanja, a sa zadržanim poslovnim pravilima i sigurnošću koju zahtjeva pristup zaštićenim privatnim informacijama. Možemo zaključiti da uključivanjem ovih funkcionalnosti poslovne aplikacije zahtijevaju da polako računalni oblak pretvorimo u privatni oblak.

Privatni oblak u smislu dozvole pristupa – samo prethodno ovlaštene osobe, odnosno ureñaji će moći pristupiti ovim resursima.

I još uvijek se radi o jednom jedinom mobilnom ureñaju koji se povezuje na sve ove načine i sve nabrojane usluge i sve nabrojene aplikacije. Možda najveći izazov pri radu sa ovako složenim sistemom je identitet korisnika – kada je on privatni korisnik, a kada poslovni korisnik, kada se prijavljuje kroz sigurnu privatnu mrežu, a kada na javni servis. Na javnom dijelu postoje pokušaji dijeljenja identiteta kroz posebne usluge kao što je OpenID 8ili LiveID9 ili CARNET-ov AAI@Edu. Najpopularnije društvene mreže nude korištenje svojih autentifikacijskih mehanizama kao servisa koje mogu koristiti druge aplikacije, pa se recimo Facebook identitet može koristiti i na drugim uslugama. U biti se identitet i dalje kreira na svakoj aplikaciji posebno, ali se putem danas dostupnih usluga oni povezuju. Za poslovnu

8 OpenID - definicija u prilogu rada - pojmovnik 9 LiveID - definicija u prilogu rada - pojmovnik

Slika 1 - Mobilni ureñaj i računalstvo u oblaku: isti ureñaj

– različita upotreba (za posao i privatno)

Slika 3 - Poslovni mobilni ureñaj/Privatni cloud, privatni

mobilni ureñaj/Javni cloud


primjenu gdje se koriste LDAP10 ili Active Directory11 sustavi pitanje jednog identiteta rješava se u zatvorenim privatnim IT sistemima, dok se na sličan način želi riješiti pitanje Single-Sign-On načina rada za sve aplikacije. Sa mobilnog ureñaja ova povezivanja još uvijek se ne mogu odraditi u potpunosti bezbolno te je ovo područje na kojem se očekuje daljnji napredak.

4. APLIKACIJE ZA MOBILNE URE ðAJE I POVEZIVANJE SA OBLAKOM

Kada govorimo o aplikacijama za mobilne ureñaje, govorimo, po vrsti izrade aplikacija, o tri načina izvršavanja aplikacija: � Nativne aplikacije za mobilne ureñaje – su aplikacije

kreirane u specifičnom jeziku i za specifičnu platformu ciljanog ureñaja

� „Browser based“ aplikacije za mobilne ureñaje – su web aplikacije izgledom, načinom korištenja i sadržajem prilagoñene mobilnim ureñajima

� Hibridne aplikacije za mobilne ureñaje – kombiniraju oba navedena načina tako da osnovni dio aplikacije radi kao web aplikacija ali se izvršava unutar nativnog omotača te na taj način koristi prednosti native aplikacija.

Nativne aplikacije korisnicima pružaju korisničko iskustvo (user expirience) na koji su navikli na svojim ureñajima. One se izvršavaju brzo i sigurno jer rade na vlastitoj platformi. Nativne aplikacije imaju pristup svim funkcijama mobilnog ureñaja i hardverskim mogućnostima ureñaja te u punoj mjeri iskorištavaju snagu današnjih ureñaja. To je dakle odličan izbor kada je cilj razviti aplikaciju za točno odreñenu platformu, no ukoliko se želi proširiti njihova dostupnost na široki spektar mobilni ureñaja, onda j e potrebno za svaku različitu platformu pisati posebnu aplikaciju. Potrebno je, dakle, da razvojni inženjeri nauče onoliko programskih jezika i razvojnih okolina koliko se platformi cilja, što nije lako. Pri tom je, naravno, potrebno održavati nekoliko različitih aplikacija što je nemali problem.

„Browser based“ / Web aplikacije nose prednost u razvoju jedne aplikacije u poznatom okruženju te jednostavno osvježavanje i održavanje. U smislu aplikacija za mobilne ureñaje, mana im je što ne mogu u potpunosti oponašati korisničko iskustvo nativnih aplikacija, te ne mogu pristupati svim funkcijama mobilnih ureñaja. Isto tako njihovo izvršavanje ovisi o izvedbi web pretraživača (browser) na mobilnom ureñaju te o raznim načinima na kojima ove web tražilice tumače HTML. Pozitivno je to što se ovaj problem iz dana u dan smanjuje, jer su mobilni pretraživači (browseri) sve bolji, sve brži i sve standardiziraniji.

Na sve više mjesta i u sve više projekata se nameće „srednji put“ - izrada hibridnih aplikacija, kao rješenje koje kombinira prednosti nativnih i web aplikacija, odnosno ponajboljeg iz oba svijeta. Hibridne aplikacije funkcioniraju na način da se osnovna funkcionalnost aplikacije izvodi kao web, odnosno HTML aplikacija oko koje dolazi nativni omotač kojega se koristi da bi se pristupilo svim mogućnostima mobilnog ureñaja. Razvoj se radi korištenjem standardnih tehnologija HTML5, CSS 3 i JavaScript, a na kraju procesa se radi omotavanje za ciljanu platformu.

Standard koji dolazi – HTML 5 – donosi obećanje lakšeg razvoja za različite mobilne ureñaje, kao što su

10 LDAP- definicija u prilogu rada - pojmovnik 11 AD - definicija u prilogu rada - pojmovnik

izvanmrežni (Offline) rad i druge opcije, koje će u budućnosti (zajedno sa punom standardizacijom) proširiti mogućnosti izrade aplikacija baziranih na HTML 5 standardu.

Neovisno o načinu kreiranja aplikacija, sve one koriste povezivanje na servise u računalnom oblaku. Slijedi nekoliko primjera po tipu aplikacija.

Kao primjer nativne aplikacije možemo uzeti aplikaciju za praćenje kretanja (GPS 12tracking application). Nativna aplikacija koristi pristup ugrañenoj GPS funkcionalnosti mobilnog ureñaja. Unutar ureñaja, na za to predviñeno mjesto, pohranjuje podatke o promjenama koordinata. Kada korisnik kroz sučelje aplikacije zatraži prikaz svojega kretanja, aplikacija se povezuje na servise u računalnom oblaku i putem HTTP komunikacije povlači slikovne resurse koje prikazuje na ekranu ispod sloja koji sama aplikacija dodaje – linija i oznaka korisnikova kretanja. Ovi slikovni resursi u ukupnom su broju preveliki da bi stali na sam ureñaj kao dio aplikacije te je aplikaciji potrebna veza na Internet resurse sa kojih dobiva odreñene tražene komade slika. U zajedničkoj povezanosti nativna aplikacija i računalni oblak stvaraju sinergiju i pomažu u dostizanju korisnikovih očekivanja. Slične su i native aplikacije za društvene mreže tipa Facebook klijent za mobilne ureñaje ili Twitter nativne aplikacije za mobilne ureñaje. Svima im je zajedničko da glavni dio podataka i informacija za prikaz povlače iz računalnog oblaka putem HTTP protokola tipično REST13 načinom komunikacije. REST komunicira XML14 formatom poruka koje svojom veličinom nisu uvijek pogodne za mobilnu povezanost te ih je preporučljivo sažimati u transportu. Nativne aplikacije isto tako bez problema mogu ostvariti komunikaciju kroz SOAP15 protokol te se spajati na klasične SOAP web servise kada to zahtjeva namjena aplikacije. Tipično bi to bile poslovne aplikacije sa podignutim sigurnosnim mehanizmima ili spajanja na aplikacije sa već izgrañenim servisnim slojem.

Tipične web aplikacije prilagoñene za korištenje na mobilnim ureñajima su web odredišta pružatelja vijesti odnosno dnevnih tiskovina. Za primjer možemo pogledati mobilnu verziju Večernjeg lista. m.vecernji.hr u odnosu na svoju verziju za velike ureñaje donosi prilagoñeni izgled koji oponaša korisničko sučelje mobilnih ureñaja, donosi skraćeni izbor tema te tipične linkove – najnovije i najčitanije. Važno je navesti da je dobra praksa za ove aplikacije da ponude i link na svoju web aplikaciju za klasične tražilice gdje korisnik može kroz danas napredne mobilne tražilice doći do punog skupa informacija i funkcionalnosti koje mu trebaju. Na sličan način izvedena je i mobilna web aplikacija MobilityDay konferencije na http://m.mobilityday.com.

Kako su ove web aplikacije povezane sa računalnim oblakom? Jednostavno – one same dolaze iz oblaka i učitavaju se na mobilni ureñaj. Ovisno o tehničkoj implementaciji naknadno dovlače samo dijelove sadržaja korištenjem komunikacijskih tehnika kao što je AJAX16 i serijalizacijom informacija u komunikaciji u JSON17 formatu. Na svojoj strani one opet koriste računalni oblak i kao izvor servisa, i to nekad kao platformu, a nekad kao infrastrukturu. U ovom slučaju mobilnom ureñaju nije

12 GPS - definicija u prilogu rada - pojmovnik 13 REST - definicija u prilogu rada - pojmovnik 14 XML - definicija u prilogu rada - pojmovnik 15 SOAP - definicija u prilogu rada - pojmovnik 16 AJAX - definicija u prilogu rada - pojmovnik 17 JSON - definicija u prilogu rada - pojmovnik


važno koji način/implementacija računalnog oblaka je odabran za realizaciju servisa.

Primjer za hibridne aplikacije je Konzumova aplikacija za narudžbu u kuću, a koja je dostupna za više platformi. Rañena je korištenjem HTML5 standarda uz CSS3 oblikovanje izgleda te JavaScript programiranjem funkcionalnosti. Kroz nativne omotače pripremljena je za više ciljanih mobilnih platformi i ureñaja. Zahvaljujući nativnom omotaču hibridne aplikacije koriste prodajne i promotivne kanale proizvoñača mobilnih ureñaja, a razvoj je ipak ujednačen za sve platforme. Svi podaci, u ovom slučaju podaci o namirnicama koje se mogu naručiti, dolaze naravno sa servisa smještenih u računalnom oblaku. Kako je ovo HTML aplikacija sa JavaScriptom kao glavnim programskim jezikom podaci se preko HTTP protokola povlače u optimalnom JSON obliku.

Bez obzira na tip aplikacije ili mobilnog ureñaja – treba primijetiti da se stalno spominje spajanje na - servise. Bez obzira na način spajanja i korištenja servisa – servisi su prisutni. SOA18 (Servisno orijentirana arhitektura) se dakle nameće kao uobičajen i preporučen način projektiranja IT sistema.

5. ZAKLJU ČAK

Korisnici danas očekuju pristup svojim aplikacijama, podacima, informacijama, datotekama – doslovce bilo kada, bilo gdje i sa raznih ureñaja i platformi. S druge strane, više nego ikada se povećava broj, vrsta i tipovi mobilnih ureñaja, sa trendom daljnjeg povećanja i proširenja ponude. Podaci, informacije, dokumenti ne mogu više ostati zaključani i odvojeni od korisnika te ga moraju slijediti na njegovu putu. Jedini odgovor na ovaj problem je platforma računalnog oprema i SOA arhitektura s kojima se podiže dostupnost aplikacija, servisa i podataka kroz standardne javne protokole i standardnim načinima komunikacije.

Snažan razvoj Cloud Computing tehnologije i njegovo centralno pozicioniranje u fokus najvećih svjetskih kompanija zajedno sa širenjem tržišta mobilnih ureñaja čini simbiozu. Ova simbioza pozicionira mobilne ureñaje danas kao najpoželjniju tehnološke platformu.

Pojmovi:

TCP/IP Transmission Control Protocol/Internet Protocol je skup pravila odnosno komunikacijskih protokola koji omogućuju povezivanje dva računala i njihovu komunikaciju

HTTP HyperText Transfer Protocol je specijalizirani „stateless“ aplikacijski protokol namijenjen razmjeni poruka izmeñu HTTP servera i HTTP klijenata

VPN Virtual Private Network – tehnologija sigurnog povezivanja na lokalnu mrežu sa udaljene lokacije korištenjem javnih mreža uz enkripciju

SaaS Software as a Service – način distribucije software-a u kojem proizvoñač aplikacije ili pružatelj usluge osigura svu infrastrukturu na jednoj lokaciji a software je dostupan i koristi se tipično putem Interneta.

PaaS Platform as a Service –TODO

18 SOA - definicija u prilogu rada - pojmovnik

IaaS Infrastructure as a Service – TODO

OpenID Otvoreni standard za decentralizirani mehanizam autentifikacije i autorizacije.

LiveID Single Sign On (način prijave kroz jednu točku sa jednim korisničkim računom) servis koji pruža tvrtka Microsoft.

LDAP Lightweight Directory Access Protocol – aplikacijski protokol za čitanje i ureñivanje strukturiranih zapisa/direktorija/imenika (optimiziranih za brzo čitanje) putem Internet protokola.

AD Active Directory – Microsoft implementacija Directoy servisa.

GPS Global Positioning System – sistem globalne navigacije korištenjem satelita

REST

Representational State Transfer – način komunikacije korištenjem HTTP (GET, POST, PUT, DELETE) zahtjeva gdje se dodatna informacija nosi u URI-u zahtjeva a odgovor se vraća kao čisti XML ili JSON tekst

AJAX Asynchronous JavaScript and XML – skup metoda u izradi web aplikacija koje korištenjem asinkronih poziva prema web servisima omogućuju kreiranje bogatog HTML sučelja koje brzo reagira na korisnikove akcije

JSON JavaScript Object Notation je tekst bazirani standard dizajniran za kodiranje/dekodiranje podataka i objekata u JavaScript programskom jeziku

SOA Service Oriented Architecture - Servisno Orijentirana Arhitektura – arhitektura u kojoj je osnovni aplikativni dio jednog IT sistema samostalni servisni modul koji je dostupan putem Internet protokola a sa kojim se može komunicirati razmjenom poruka u standardnom formatu.

XML Exstensible Markup Language, specifikacija za općeniti markup jezik namijenjen prenošenju podataka i kreiranju vlastitih oznaka za specifične namjene


Literatura:

1 Tomislav Bronzin: " Scenariji za razvoj aplikacija na Windows Azure platformi“, WinDays 11 Technology, Opatija, 2011

2 Tomislav Bronzin: "Azure Services platforma“, WinDays 9 Technology, Opatija, 2009

3 Dobriša Adamec: „Microsoft Azure Services Platform Development“, WinDays 9 Virtual, Opatija, 2009

4 Tomislav Bronzin: „N-slojni informacijski sustavi“, CASE 11, Opatija, 1999

5 Tomislav Bronzin: „SOA - Service Oriented Architecture - malo drugačije“, CASE 17, Opatija, 2005

6 Tomislav Bronzin, Dobriša Adamec: „Kako graditi povezive aplikacije korištenjem .NET Framework 3.5 tehnologije i Visual Studio 2008.“

7 „What is Windows Azure?“, http://www.microsoft.com/windowsazure/

8 „Cloud Computing“, http://en.wikipedia.org/wiki/Cloud_computing

9 „IBM Cloud Computing“, http://www.ibm.com/cloud

10 „Salesforce Cloud Computing“, http://www.salesforce.com/cloudcomputing/

Podaci o autorima:

Tomislav Bronzin, mag. ing. el., Microsoft Regional Director & MVP

Tomislav Bronzin, mag. ing. el. je osnivač tvrtke CITUS, Microsoft Gold Certified partnera, čija je glavna djelatnost proizvodnja programskih rješenja i savjetovanje za razvoj aplikacija na Microsoft platformi. Autor je dva patenta s područja ICT-a registriranih u Hrvatskoj agenciji za intelektualno vlasništvo. Bio je uključen u projektiranje i implementaciju prvih nekoliko velikih mobilnih rješenja na Microsoftovoj platformi, uključivši one za Hrvatske šume i Hrvatske željeznice. Tomislav je nositelj počasnih titula Microsoft Regional Director, Microsoft MVP, te Microsoft Certified Trainer. Redovni je predavač na velikim Microsoftovim konferencijama u široj regiji, Microsoft TechEd Europe ili domaće WinDays i Mobility Day. Sudjelovao je kao predavač na akademskim konferencijama koje organizira Ministarstvo znanosti obrazovanja i športa, kao pozvani predavač predavao je na FOI-u i FER-u, bio je mentor timovima studenata na natjecanju Microsoft Imagine Cup. Uz navedeno, Tomislav je potpredsjednik Udruženja za IT pri HGK, predsjednik je Hrvatskog udruženja programera, suosnivač je http://www.mscommunity.net portala, te je član upravnog odbora INETA Europe. Tomislav Bronzin is Senior Advisor in CITUS, Microsoft Gold Certified Partner Company for Solution Development and Consulting for Application Lifecycle Management. He is owner of two ICT based patents which was used in first two large Mobile Solutions on Microsoft platform developed for Croatian Forests and Croatian Railways. Tomislav has more than 18 years of real-life experience with Microsoft technologies with current interest in development of distributed applications based on .NET Smart Client and Mobile Devices technology, resulting in having 2 patents in those areas as well in Microsoft Unified Communication Development. He is teaching students at University College for Applied Computer Engineering in Zagreb and he is often invited to speak at Faculty of Electrical Engineering and Computing (FER) and Faculty of Organization and Informatics. Tomislav has been a regular speaker at Microsoft conferences in the region, as well as at several academic conferences and he was speaker at Microsoft TechEd Europe. He is INETA Europe Vice President, Croatian Chamber of Economy - IT Association Vice President, President of the Croatian Association of Computer Programmers and co-founder of http://www.mscommunity.net. Tomislav has honorable titles: Microsoft Regional Director and Most Valuable Professional – Solution Architect.

Vedran Kaldi, ing., Microsoft Certified Trainer

Vedran Kaldi je glavni razvojni inženjer u tvrtki Citus. Posao zahtjeva specijalnost u velikom broju tehnologija, sa stalnim naglaskom na razvoj WPF, WCF i MVC web aplikacija u čijoj izradi se izvrsno snalazi. Kada može birati, radi na bazama podataka s posebnim interesom na optimizaciju i izvlačenje onih zadnjih 2% performansi iz upita. Kada ne programira, radi na edukaciji (kao Microsoft Certified Trainer), te predaje na konferencijama (poput Windays, MobilityDay...), Bootcamp treninzima, MSCommunity dogañajima i sl. U slobodno vrijeme bavi se downhill vožnjom bicikla.

CITUS d.o.o.



RAZVOJ APLIKACIJA ZA ANDROID PLATFORMU

DEVELOPMENT OF ANDROID MOBILE APPLICATIONS

Ognjen Ribi čić, mag.inf. Boris Tomaš, mag.inf. Zlatko Stapi ć

SAŽETAK:

Današnji trendovi u razvoju mobilnih aplikacija odraz su velike dinamike na tržištu mobilnih ureñaja. Ovaj rad se temelji na predstavljanju osnovnih koncepata i načina razmišljanja kod razvoja aplikacija za Android mobilnu platformu. Nastoji se ukazati na jednostavnost korištenja platforme kao i na standardni stil i pristup pisanja kvalitetnog programskog kôda. U radu su prikazane dobre prakse korištenja osnovnih i naprednijih koncepata u razvoju, uključujući i rad sa razvojnim okruženjem kao i specifičnosti Java jezika. U konačnici, temeljem iskustva autora, rad prikazuje i najčešće probleme s kojima se susreću razvojni inženjeri te načine njihovog rješavanja.

ABSTRACT:

Current trends in mobile applications software development are results of significant dynamics in mobile device market. This paper aims to introduce the basic concepts and ways of thinking regarding application development for the Android mobile platform. This work tries to point out a simple use of the platform as well as a standard style and an approach in defining a good programming code. Good practices are shown regarding the use of basic and advanced development concepts in Java language. Paper also states a few guidelines regarding the usage of integrated development environment. At the end, based on the authors experiences, few and common issues and problems for developers are identified and their solution is presented.

1. UVOD

Android je od prve inačice iz 2008. godine [1] do danas daleko napredovao kao skup softverskih alata koji uključuju operacijski sustav, sustav zajedničkih funkcija (engl. middleware) i aplikacija. Mobilni ureñaji postali su brži, SDK sofisticiraniji, a korisnici zahtjevniji. Indikator prije navedenog je nagli porast popularnosti platforme od strane korisnika, kao i programera od njezine publikacije. Sama platforma je otvorenog kôda (engl. open source) što omogućava razvoj bogatih i naprednih aplikacija u relativno kratkom vremenu uz nerijetko besplatnu podršku zajednice. Ta razvojna zajednica je takoñer opsežna, te omogućava putem grupa, poput „Google Groups“, komunikaciju s istom. Kao i svaka platforma, Android sadrži neke specifičnosti.

Ovaj rad se temelji na predstavljanju osnovnih koncepata i načina razmišljanja kod razvoja aplikacija za Android mobilnu platformu. Nastoji se ukazati na jednostavnost korištenja platforme kao i na standardni stil i pristup pisanja programskog kôda. U radu su prikazane dobre prakse korištenja osnovnih i naprednijih koncepata u razvoju, uključujući i rad sa razvojnim okruženjem kao i specifičnosti Java jezika. U konačnici, temeljem iskustva autora, rad prikazuje i najčešće probleme s kojima se susreću razvojni inženjeri te načine njihovog rješavanja.

Većina prikazanih koncepata u radu je prikazana i odgovarajućim primjerima koji prikazuju osnovu primjene koncepta o kojem se diskutira. Većina predložaka za izradu primjera je preuzeta iz projekta Remoter koji su autori razvili prije pisanja ovog rada i koji je trenutno u fazi objave na Android tržište.

Ovaj rad bi trebali čitati programeri koji su upoznati i imaju iskustva sa Java programskim jezikom. Svakako

prije navedeno treba shvatiti kao prijedlog, te zainteresirane ne bi trebalo demoralizirati i odvratiti od čitanja istog.

2. STRUKTURA APLIKACIJA

Kako je prije navedeno aplikacije se pišu u programskom jeziku Java. Jezik kao takav ima neke svoje specifičnosti koje svakako prije samog početka proučavanja izrade Android aplikacija valja pogledati, pa čak i proučiti. Razvojna okolina se sastoji od seta razvojnih alata (engl. SDK tools), koji služe za prevoñenje (engl. compile) izvornog kôda Android aplikacije, pripreme aplikacija (engl. deployment) kako bi se one mogle izvršavati na mobilnom ureñaju.

Sve podatke o aplikaciji, uključujući izvršni kôd, resurse potrebne za izvršavanje aplikacije, metapodatke i manifest podatke o aplikaciji, razvojno okruženje kod finaliziranja aplikacije pohranjuje u obliku jedne arhive sa ekstenzijom .apk [3].

Prilikom instalacije aplikacije na mobilnom ureñaju, ista dobiva svog vlastitog korisnika odnosno jedinstveno korisničko okruženje na Android platformi; takoñer aplikaciji se dodjeljuje vlastito virtualno okruženje (engl. virtual machine) te vlastiti „Linux ID“ [3]. Pri pokretanju, svakoj aplikaciji se dodjeljuje vlastiti proces unutar kojeg se aplikacija izvršava, ovaj mehanizam štiti Android platformu od neispravnih aplikacija tako da aplikacija može utjecati samo na svoj proces dok su ostali procesi izolirani od možebitnog štetnog procesa. Na ovaj način Andorid implementira princip dodjele minimalnih privilegija (engl. “principle of least privilege“) čime osigurava visoku sigurnost okruženja u kojima aplikacije ne mogu pristupati dijelovima sustava za koji nemaju dozvolu [3].


2.1 Aplikacijske komponente

Aplikacijske komponente su na Android platformi najvažniji elementi od kojih se sastoje aplikacije. Svaka komponenta ima svoj životni ciklus, te omogućava sustavu rad s aplikacijom na sebi svojstven način. Postoje četiri osnovne komponente [3]: � Aktivnost (eng. Activity) – Najčešće korištena

komponenta u aplikacijama, reprezentira ekran odnosno sučelje za korisničku interakciju.

� Servis (eng. Service) – Operacija koja se izvršava u pozadini, te se obično koristi za neke vremenski odnosno procesorski zahtjevne proračune. Service je u stanju pokrenuti vlastiti proces te ostvariti interakciju s istim.

� Pružatelj sadržaha (eng.Content provider) – Dio API-a koji omogućava rad sa zajedničkim podacima kao što su interna i eksterna memorija ili SQLite baza.

� Primatelj vanjskih dogañaja (eng. Broadcast receiver) – Služi za primanje poruka iz sustava, na primjer gašenje ekrana, stišavanje glasnoće ureñaja i ostali dogañaji.

2.2 Predefinirane varijable, resursi

Android za razliku od ostalih sustava ima vrlo dobro riješen problem internih resursa. Na primjer, svi elementi forme se dohvaćaju putem jedinstvenih identifikatora (engl. ID) ili oznaka (engl. tag). Ukoliko koristimo dohvaćanje putem identifikatora, postupak pretraživanja elemenata je veoma brz sobzirom da istog reprezentira cjelobrojna (engl. integer) varijabla. Takoñer spremanje preddefiniranih konstanti je omogućeno na sličan način kao i prije navedeni elementi forme.

2.3 Asinkrone poruke

Tri od četiri aplikacijske komponente aktiviraju se asinkronim porukama, intentima. To su „Activity“, „Service“ i „Broadcast reciver“. Intent omogućava pozivanje i povezivanje istih na izvršno okruženje (engl. runtime environment). Dakle, ako želimo pozvati novu formu, sve što trebamo napraviti jest stvoriti novi intent objekt, i kroz konstruktor objekta proslijediti klasu koja će se pokrenuti. Rezultat akcije je, na primjer pri kreiranju nove forme, novi zaslon odnosno forma koju smo kreirali i pozvali.

Kôd 1 Primjer pozivanja/stvaranja forme (klase)

Stoga, pozivanje aplikacijskih komponenata i ako je to potrebno slanje podataka istima je prvi bitan koncept na koji ćemo se osvrnuti u ovom radu. Ukoliko želimo poslati odreñene podatke novoj formi, dodajemo paket ili svežanj (engl. bundle) na intent. Spomenuti svežanj sadrži skup podataka koje želimo poslati. Takoñer kada se stvori nova forma iste podatke dohvaćamo putem “getera” iz intenta te ih po potrebi koristimo na novoj formi. Intenti zajedno sa aplikacijskim komponentama, Manifest datotekom i formama čine osnove programiranja u Android okruženju.

2.4 Forme i raspored elemenata

Za razliku od C-srodnih jezika kao što su C# ili Objective-C koji se koriste u Windows Phone odnosno na iPhone platformi, i koji omogućavaju “crtanje“ formi, Android platforma preferira kôdiranje dizajna formi. Najčešće se radi sa XML datotekama koje sadrže vizualni kôd forme, pomalo nalik na HTML, no moguće je iste i napraviti programski, što dakako oduzima dosta vremena i nije preporučljivo. Sukladno tome postoje komponente pregleda kontrola (engl. ViewGroup components), vrste razmještaja elemenata unutar zaslona kao što su LinearLayout, RelativeLyout, i tako dalje. Isto tako, postoje pogledi (engl. view) odnosno elementi koje prikazujemo. Koncept rada XML datoteka sa dizajnom temelji se na hijerarhiji. „ViewGroup“ unutar sebe može sadržavati elemente forme: „View“ ali i druge načine prikaza – „ViewGroup“ [9].

Kôd 2 Jednostavna forma (XML)

Kôd prikazan u isječku (Kôd 2) će rezultirati jednostavnom formom koja sadrži jednu tipku (engl. Button).

Klasa koja procesira formu je prikazana u isječku (Kôd 3). Kôd te klase je odgovoran za korisnički klik na tipku definiranu prije navedenim XML kôdom. Ukoliko se klikne na tipku, ispiše se preko brze obavijesti (engl. toast notification) tekst “Ovo je test”.

Kôd 3 Jednostavna klasa (Java)

Intent myIntent = new Intent(getBaseContext(), frmMain.class); startActivity(myIntent);

public class HelloAndroid extends Activity { /* Called when the activity is first created. */ @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.main); //Trazenje gumba unutar forme final Button btn = (Button)findViewById(R.id.btn) //Postavljanje slusatelja button.setOnClickListener( new OnClickListener() { public void onClick(View v) { Toast.makeText( HelloAndroid.this, "Ovo je test", Toast.LENGTH_SHORT).show();}}); } }

<?xml version="1.0" encoding="utf-8"?> <LinearLayout xmlns:android= "http://schemas.android.com/apk/res/android" android:orientation="vertical" android:layout_width="fill_parent" android:layout_height="fill_parent" > <Button android:id="@+id/btn" android:layout_width="wrap_content" android:layout_height="wrap_content" android:text="Klik" /> </LinearLayout>


2.5 Manifest datoteka

Manifest je XML datoteka koja je sastavni dio .apk arhive i ima specifičnu namjenu. Datoteka u potpunosti opisuje aplikaciju. Sve aktivnosti, a i ostale komponente, su opisane u datoteci na način da sustav razumije namjenu, korisničke dozvole i slično. Moguće je i ograničiti aplikaciju na verziju platforme obzirom da novije verzije donose sa sobom i različite funkcionalnosti [5].

Primjer jedne takve datoteke prikazuje isječak programskog koda (Kôd 4)

Kôd 4 Primjer AndriodManifest datoteke (XML)

3. OSNOVNI KONCEPTI

U ovom poglavlju pokušat ćemo približiti neke specifičnosti programiranja u Android okruženju. Bavit ćemo se najčešćim konceptima koji se pojavljuju prilikom izrade aplikacija kao što su osluškivači dogañaja (engl. event listeners), izbornici, obavijesti i ostali.

3.1 Osluškiva či doga ñaja

Osluškivač dogañaja je koncept Android platforme koji nam omogućava reagiranje na dogañaje kada se dogode, te po potrebi i obrañivanje istih. Koncept se temelji na povezivanju osluškivača na dogañaj nekog od prethodno navedenih elemenata te time i na izmijeni izvršavanja njegove funkcionalnosti. Takoñer potrebno je spomenuti kako je moguće koristiti Java koncept koji omogućava premošćivanje standardnih metoda izvršavanja funkcionalnosti i zamjensko korištenje vlastitih metoda. Koncept premošćivanja se kao i u nekim drugim jezicima implementira korištenjem predefinirane naredbe „@Override”, a zanimljivo je spomenuti da se u Android razvojnom okruženju može premostiti sve metode definirane na razini sustava.

Sličan je pristup implementaciji funkcionalnosti pri reakciji na ostale „napredne“ dogañaje kao što su na primjer dogañaj dodira (engl. touch event) ili dogañaj geste (engl. gesture event), no o tome u sljedećim poglavljima.

Kôd 5 Primjer osluškivača dogañaja

3.2 Izbornici

Specifičnost Android okruženja je neposredna interakcija programera i razvojnog okruženja pri kreiranju izgleda formi, izbornika, animacija i ostalih pretežno XML baziranih rješenja. Kao i forme, izbornike (engl. menu) je moguće napraviti programski, ali ipak, kako je praksa pri izradi aplikacija korištenje XML datoteka, taj pristup ćemo koristiti i kod izrade izbornika. Izbornik je u pojedinim elementima sličan klasičnoj formi korisničkog sučelja, no ujedno ima i znatna pojednostavljenja ovog koncepta. Takoñer hijerarhija elemenata kod izbornika slična je hijerarhiji elemenata formi.

Kôd 6 Definicija izbornika (XML) – Menu.xml datoteka

3.3 Obavijesti

U Android okruženju postoje tri različite vrste elemenata za prikaz obavijesti korisniku: � Brza obavijest � Obavijest u statusnoj traci � Obavijest na dijaloškom okviru (engl. dialog

notification)

Kôd 7 Završavanje definicije izbornika (Java)

Brza obavijest (engl. toast notification) je privremeni objekt koji služi za trenutno obavještavanje korisnika. Zauzima prostor koji mu je potreban da ispiše poruku, dok aplikacija i dalje ostaje vidljiva i interaktivna [9].

@Override public boolean onCreateOptionsMenu(Menu menu) { MenuInflater inflater = getMenuInflater(); inflater.inflate(R.menu.menu, menu); return true; } @Override public boolean onOptionsItemSelected(MenuItem item){ switch (item.getItemId()) { case R.id.settings: return true; default: return super.onOptionsItemSelected(item); } }

<?xml version="1.0" encoding="utf-8"?> <menu xmlns:android="http://schemas.android. com/apk/res/android"> <item android:id="@+id/settings" android:title="@string/settings"/> </menu>

<?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="app.test.example" android:versionCode="1" android:versionName="1.0"> <uses-sdk android:minSdkVersion="5" /> <application android:label="@string/app_name"> <activity android:name=".Test" android:label="@string/app_name"> <intent-filter> <action android:name= "android.intent.action.MAIN" /> <category android:name= "android.intent. category.LAUNCHER" /> </intent-filter> </activity> </application> </manifest>

final Button btn = (Button) findViewById(R.id.btn); btn.setOnClickListener(

new OnClickListener()

{ public void onClick(View v)

{ Toast.makeText(

HelloAndroid.this,

"Ovo je test", Toast.LENGTH_SHORT).show();

}});


Obavijest u statusnoj traci (engl. status bar notification) označava trajniji tip notifikacije korisnika. Prikazuje se, kako ime govori, u statusnoj traci, te pri selekciji okida intent definiran u obavijesti [9].

Kôd 8 Definiranje dijaloga

Obavijest na dijaloškom okviru (engl. dialog notification) je definirana kao novi mali dijaloški okvir koji se prikazuje na vrh trenutnog dijaloškog okvira, te može pružati interakciju korisniku. Moguće ga je koristiti i za unos malih količina podataka [9]. Dijalog se stvara i prikazuje na način kako je to navedeno ovim programskim isječkom:

4. NAPREDNI KONCEPTI

Tijekom korištenja naprednih koncepata u razvoju aplikacija za Android ureñaje, često se služimo svim navedenim osnovnim konceptima kako bi se zadovoljila funkcionalnost odreñene komponente i postigla željena nova funkcionalnost. Budući da SDK nudi mnoštvo različitih koncepata, ovaj rad opisuje prema našem izboru najčešće i najkorištenije koncepte.

4.1 Prilagodnici

Jedan od tih koncepata su prilagodnici (engl. adapters). Adapteri su koncepti koji omogućavaju izmjenu, to jest prilagodbu odreñene skupine podataka na neki od predefiniranih načina. Primjer takve prilagodbe je „SimpleAdapter“.

Ako primjerice koristimo listu za izbor jedne od ponuñenih vrijednosti, a stavke te liste su izvedene iz skupa jednostavnijih atributa, iste možemo putem prije navedenog adaptera prilagoditi, te umetnuti u listu kao njene vrijednosti. Postoji mnoštvo različitih adaptera, čime se još jednom približavamo shvaćanju opsežnosti Android razvojnog okruženja kao i njegovih mogućnosti.

Kôd 9 Korištenje adaptera

4.2 Dijeljena svojstva

Kako iz imena zaključujemo radi se o zajedničkim postavkama aplikacije (engl. shared preference). Moguća je promjena primitivnih tipova podataka u obliku ključ => vrijednost. Takoñer „Activity“ ima indirektnu pod-klasu „PreferenceActivity“ koja nam omogućava pregled postavki, sa preddefiniranom funkcionalnošću, spremljenom unutar odreñene XML datoteke ili unutar klase koja koristi „PreferenceActivity“. Spomenuta klasa automatski omogućava izmjene nad prije navedenim primitivnim podacima [5].

Kôd 10 Korištenje koncepta dijeljenih svojstava

4.3 Unutarnja memorija

Unutarnja memorija omogućava spremanje podataka aplikacija u internu memoriju ureñaja. Uz razne dodatne API-je omogućeno nam je manipuliranje nad raznim tipovima datoteka. Valja napomenuti kako se ova vrsta pohrane podataka koristi za spremanje privatnih podataka koji ne bi trebali biti dostupni ostalim aplikacijama ili korisniku [5]. U sljedećem programskom isječku se može vidjeti način pohrane podataka u datoteku u unutarnjoj memoriji Android ureñaja.

Kôd 11 Korištenje unutarnje memorije

4.4 Vanjska memorija

Gotovo uvijek pri ovom pojmu mislimo na SD memorijske kartice. Temeljna razlika izmeñu unutarnje i vanjske memorije je u dostupnosti podataka. Naime Andorid, kako je prije navedeno, definira više razina sigurnosti podataka, a podaci zapisani na ovaj način postaju dostupni svim aplikacijama pa čak i korisniku što postaje suština postojanja ovakve funkcionalnosti [5].

Kôd 12 Korištenje vanjske memorije

4.5 Mobilna baza podatka

Jedan od dakako standardnih, ali i primamljivih koncepata mobilnih ureñaja je funkcionalnost korištenja mobilne baze podataka. Android okruženje rabi sqlite3 verziju baza podataka, te postoji mnoštvo primjera kako spomenutu bazu koristiti. Potrebno je naglasiti kako je pisanje pomoćne (engl. helper) klase, koja će umjesto

File path = getExternalStorageDirectory(); if (path != null) { File file = new File(path, "file"); OutputStream os = new FileOutputStream(file); os.write(new byte["test"]);}

String FILENAME = "file";

String string = "test";

FileOutputStream fos = openFileOutput(FILENAME,

Context.MODE_PRIVATE);

fos.write(string.getBytes());

fos.close();

final CharSequence[] items = {getString(R.string.add), getString(R.string.connect)}; final AlertDialog.Builder options = new AlertDialog.Builder(this); options.setTitle(getString(R.string.quick_actions)); options.setCancelable(true); options.setItems(items, new DialogInterface.OnClickListener() { public void onClick(DialogInterface dialog, int item) { //kod koji se izvršava prilikom poziva } }); options.show(); //aktiviranje dijaloga

ArrayList<Map<String, String>> server_lst =list_values; String[] from = {"name", "version"}; int[] to = {R.id.name, R.id.version}; SimpleAdapter adapter = new SimpleAdapter(getApplicationContext(), list, R.layout.list, from, to); list.setAdapter(adapter);

final EditText name = (EditText) findViewById( R.id.text_name); SharedPreferences prefs = PreferenceManager.getDefaultSharedPreferences( this); name.setText(prefs.getString("name", "vrijednost"));


nas odrañivati obradu upita, što na većim projektima može skratiti vrijeme izrade [5].

Kôd 13 Korištenje SQLite baze podataka

4.6 HTTP

Kao pametni telefon treće i četvrte generacije - generacije mobilnog Interneta, Android pruža opsežni API za komunikaciju sa Internetom. Pokrivena je cjelokupna funkcionalnost HTTP protokola, što uključuje i mogućnosti korištenja raznih web servisa na razini GET i POST metoda.

Kôd 14 Primjer jednostavnog dohvaćanja sadržaja web stranice

Isječak Kôd 14 dohvaća sadržaj web stranice www.google.com koristeći standardni HTTP protokol sa GET metodom.

4.7 XML

Kako se do sada moglo zaključiti, platforma je orijentirana ka korištenju XML standarda, što nas može dovesti do zaključka kako ista sadrži i «jaki» XML API. Android pruža podršku za DOM, SAX i Pull parser koncepte. Od verzije 2.2 Android API je proširen s xPath1.0 funkcionalnošću za navigaciju XML dokumentom.

4.8 Gesture

Dodavanjem „Multi-Touch“ funkcionalnosti, Android dobiva podršku za geste. Geste su interakcije sa ureñajem prstima u vidu dodira (engl. tap), dvostrukog dodira (engl. double tap), približavanja prstima (engl. pinch zoom), pomaka (engl. swipe), i tako dalje. Kreiranjem osluškivača, predajemo dogañaj gesture

klasi putem koje iste obrañujemo. Specifičnost ove podrške je u praktički neograničenosti primjene ovih gesti. Dakako korištenje istih je dosta olakšano putem Gesture API-ja. Geste trebaju svoju vlastitu osluškivačku klasu kao na primjer TrackpadGestureListner klasa koja implementira dva sučelja (engl. interface): � OnGestureListener � OnDoubleTapListener

Kôd 15 Čitanje podataka iz XML datoteke

Sama klasa sadrži sljedeće dogañaje: � onDown � onFling � onLongPress � onScroll � onShowPress � onSingleTapUp � onDoubleTap � onDoubleTapEvent � onSingleTapConfirmed

4.9 Grafika

Kompletno Android sučelje i komponente su u suštini 2D grafike - svi elementi su 2D elementi. Transformacije ovih elemenata svode se na manipuliranje širinom i visinom. Takoñer moguće je animirati elemente, no o tome u sljedećim poglavljima [6].

Uz 2D podržane su 3D animacije i to na dva načina: OpenGL i Renderscript animacije. OpenGL je opće poznat koncept 3D animacija te je dovoljno reći kako razvojno okruženje podržava šest standardiziranih verzija istoga. Dakle radi se o klasičnoj manipulaciji kroz API sučelje. Za razliku od OpenGL-a, Renderscript koristi najbolji resurs za obradu grafike u konkretnom trenutku, što čak može biti i GPU (engl. Graphic Processing Unit) ukoliko ga ureñaj ima.

Takoñer, Renderscript se razlikuje po još nekim karakteristikama od standardnog programiranja u Androidu. Naime, isti je namijenjen korisnicima kojima nije problem programirati u C-u, točnije C99 standardu što za sobom može povesti i probleme. Naime, budući je moguće renderiranje na GPU-u, ispravljanje pogrešaka (engl. debugging) može postati problematičan. Predlaže se korištenje ove metode obrade animacije ukoliko je naglasak na performansama to jest gdje OpenGL ne rezultira dovoljno kvalitetnim i brzim programskim kodom [6].

DocumentBuilder builder = factory.newDocumentBuilder(); FileInputStream fin = openFileInput(file_name); Document dom = builder.parse(fin); NodeList servers_from_xml = dom.getElementsByTagName("some_elem"); for (i=0; i < servers_from_xml.getLength(); i++) { Node node = servers_from_xml.item(i); String name = node.getAttributes().item(0).getNodeValue(). toString(); }

public class DBHelper extends SQLiteOpenHelper { private static final int DATABASE_VERSION = 2; private static final String DATABASE_NAME = "sqlite_db"; DictionaryOpenHelper(Context context) { super(context, DATABASE_NAME, null, DATABASE_VERSION); } @Override public void onCreate(SQLiteDatabase db) { db.execSQL("some SQL query"); } }

URL connectURL = new URL("www.google.com"); HttpURLConnection http = (HttpURLConnection)connectURL.openConnection(); http.setDoInput(true); http.setDoOutput(true); http.setUseCaches(false); http.setRequestMethod("GET"); http.connect();//spajanje na poslužitelj http.getOutputStream().flush(); String response = getResponse(http);


Kôd 16 Definiranje animacije (XML)

Android takoñer podržava 2D animacije koje se mogu provoditi nad elementima forme. Sastoje se od deklarativne XML datoteke ili programskog kôda, te programskog kôda za obradu odnosno izvršavanje 2D animacija [6].

Isječak Kôd 16 prikazuje jednostavnu animaciju te ukazuje na opsežnost i snagu Android platforme prilikom rada sa grafikom odnosno 2D animacijama [6].

Kôd 17 Definiranje animacije (JAVA)

4.10 Rad s mrežnom infrastrukturom

Koncepti korištenja bežične mreže (WiFi, Bluetootha, GSM) su takoñer kao i velika većina koncepata relativno jednostavni za korištenje. Dovoljno je zatražiti od sustava dozvolu za korištenje, te manipulirati objektima. Kod ovih koncepata može doći do problema obzirom na različite verzije SDK-a. Naime, starije verzije ne podržavaju neke funkcionalnosti, te je potrebno istima ograničiti pristup putem Manifest datoteke ili implementirati kontrolu verzije unutar same aplikacije.

GPS za razliku od bežičnih mreža nije doživio veće promjene, te korištenje istoga takoñer ne predstavlja velike probleme. Rad s GPS-om se svodi na traženje dozvole i korištenje preddefiniranih objekata. Slijedeći isječci kôda prikazuju korištenje pojedinih infrastrukturnih koncepata na Android mobilnim ureñajima:

Kôd 18 Korištenje WiFi infrastrukture

Kôd 19 Korištenje Bluetooth infrastrukture

Kôd 20 Korištenje GSM infrastrukture za pozive

Kôd 21 Korištenje GPS infrastrukture

Ovisno o traženoj funkcionalnost potrebno je dozvoliti korištenje odgovarajuće infrastrukture unutar manifest datoteke. Korišteni objekti u primjerima postoje ukoliko postoji tražena infrastruktura na mobilnom ureñaju, u suprotnom vrijednost objekta je null.

4.11 Google APIs

Podrška za rad s Google vanjskim API-jima unutar vlastitog mobilnog operacijskog sustava je i za očekivati. Tako je na primjer korištenje Google Maps servisa moguće ugraditi u aplikaciju, odabirom odgovarajućeg API-a prilikom stvaranja novog projekta.

Koncept Google Maps API-ja je drukčije prirode zbog toga što se koristi na relativno jednostavan način, ali dodatne kontrole na Google kartu dodatno komplicira implementaciju [4].

Kôd 22 Dodavanje Google Maps komponente (XML)

Unutar XML kôda forme stvaramo element tipa „com.google.android.maps.MapView“ kako to prikazuje isječak u kodu (22). Takoñer, unutar manifest datoteke je potrebno dodati i odgovarajući isječak definiran u kodu koji slijedi (23).

Kôd 23 Proširenje manifest datoteke

4.12 Rad s dretvama

Android podržava višedretvenost (engl. multi-threading), što nam uvelike olakšava izradu i funkcioniranje složenijih aplikacija. Dretve se mogu koristiti na dva načina: tako da se izvršavaju na „UI Thread-u“ što naravno blokira isti, ili kao pozadinske dretve, čiji je posao obično odraditi neki vremenski opsežniji posao, tako da se „UI Thread“ ne blokira, što znači da korisnik može nastaviti rad s aplikacijom dok čeka na rezultat izvršavanja. Komunikaciju izmeñu dretvi moguće je realizirati na više načina. Jedan od poznatijih i primjenjenijih je korištenje „Handlera“, kako bi se slale poruke meñu dretvama i dogovorio tijek izvršavanja. Još jedan važan koncept preuzet iz Jave je korištenje tako zvanih sinkroniziranih (engl. syncronized) blokova za sinkronizaciju izmeñu dretvi [10].

4.13 Dinami čna izmjena formi

Kod Android platforme moguće je izmjenjivati prikaz elemenata (View-ove) prilikom izvršavanja aplikacije ukoliko prikaz ovisi o prijašnjoj akciji. Primjer ovog koncepta je mogućnost izmjene sadržaja u sklopu dijaloga, kako je prije navedeno za unos malih količina podataka. Isti postupak vrijedi takoñer i za izbornik, svojstva, animacije i ostale koncepte.

final Animation a = AnimationUtils.loadAnimation(Trackpad.this, R.anim.anim_xml); a.reset(); some_element.startAnimation(a);

< com.google.android.maps.MapView android:id="@+id/mapView" android:layout_width="fill_parent" android:layout_height="fill_parent" android:enabled="true" android:clickable="true" android:apiKey="some api key"/>

<uses-library android:name="com.google.android.maps"/> <uses-permission android:name="android.permission.INTERNET"/>

<?xml version="1.0" encoding="utf-8"?> <set xmlns:android= "http://schemas.android.com/apk/res/android"> <translate android:fromXDelta="100%p" android:toXDelta="0%p" android:duration="500" /> <alpha android:fromAlpha="0.0" android:toAlpha="1.0" android:duration="500" /> </set>

WifiManager wm = (WifiManager)getSystemService(Context.WIFI_SERVICE);

BluetoothAdapter bm = BluetoothAdapter.getDefaultAdapter();

TelephonyManager tm = (TelephonyManager)getSystemService( Context.TELEPHONY_SERVICE);

LocationManager lm = (LocationManager)getSystemService( Context.LOCATION_SERVICE);


4.14 Ostali koncepti

Android SDK se pobrinuo i za ostale koncepte kao što su vibracije, zvuk, slika, pokretna slika i tako dalje, te je u platformu ugrañena opsežna funkcionalnost za manipulaciju nad istima kroz primjenu odgovarajućih klasa. Koncepti se relativno jednostavno koriste i u skladu su ostatkom Java odnosno Android filozofije [7].

5. PROBLEMI

5.1 Instalacija okruženja

Iz ranije navedenoga, programira se u programskom jeziku Java. Kako bismo isto mogli provoditi važno je stvoriti adekvatno razvojno okruženje. Ovisno o operativnom sustavu na kojem razvijamo aplikaciju, preuzimamo SDK sa službenog web mjesta: “http://developer.android.com/sdk/index.html”. SDK instalacija je automatizirani proces. Kako se na stranicama preporučuje korištenje Eclipse integriranog razvojnog okruženja (eng. IDE), istoga takoñer preuzimamo sa Interneta. Nadalje, Java JRE (engl. Java Runtime Environment) koji dolazi sa OS-om nije namijenjen razvoju, te je potrebno preuzeti Java JDK (engl. Java Development Kit).

Pokretanje razvojnog okruženja vremenski ne traje dugo. Prije opisani proces zahtjeva, naravno ovisno o brzini Interneta kojim raspolažete, oko 30-tak minuta. Ovisno o izborima prilikom instalacijske procedure, ovo razvojno okruženje može zauzeti dosta prostora na tvrdom disku. To je shvatljivo obzirom da SDK može sadržavati više virtualnih slika mobilnih OS-a, koji razumljivo i zauzimaju dosta prostora.

5.2 Emulatori i fizi čki ure ñaji

U Eclipse-u je potrebno umetnuti putanju do novo kreirane SDK mape, te stvoriti emulator koji će nam omogućiti razvoj aplikacije bez korištenja stvarnog ureñaja. Ukoliko imamo fizički ureñaj emulator nije potreban, te je moguće izvršavati aplikacije i ispravljati pogreške na samome ureñaju, što za sobom dovodi i prve probleme prilikom izrade aplikacija: emulirana verzija Androida ne može podržavati funkcionalnosti kao što su WiFi, BT, GPS, IR i tako dalje, iz razloga što je za te funkcionalnosti potreban fizički ureñaj. Ukoliko se izrañuju aplikacije koje koriste baš ove koncepte, nužno je nabaviti fizički ureñaj. Fizičke mobilne ureñaje moguće je putem USB kabla spojiti na računalo. Kako bismo to mogli napraviti moramo biti upoznati s odreñenim konceptima. Naime USB veza radi besprijekorno samo na OSx platformi. Kod Windows-a potrebno je instalirati posebne USB pokretače (engl. drivers) kako bi se mobilni ureñaj mogao koristiti za razvoj aplikacija. Linux OS ne razumije „Vendor id” ureñaja te je potrebno napraviti tablicu ovih oznaka.

5.3 Ispravljanje pogrešaka

Ovisno o odluci o korištenju fizičkog ureñaja, za efikasno traženje pogrešaka u kôdu, logiranje i ispravljanje pogrešaka, potrebno je i postaviti “AndroidManifest.xml” datoteku. U aplikacijski element dodaje se atribut debuggable=“true” [8].

Kada imamo okruženje u kojemu možemo raditi, preostaje nam jedino opisati neke moguće probleme koji nastaju prilikom razvoja. Dakako tema rada nije rješavanje semantičkih i logičkih grešaka, već moguće nedoumice oko koncepata.

5.4 Dizajn formi

Tipični primjer primjene koncepata na krivi način su forme. Naravno valja naglasiti kako neki koncepti nisu namijenjeni da se koriste na ovaj ili onaj način. Problemi kod izgleda formi su ideje dizajnera koje nisu provedive na jednostavan način – putem ugrañenih funkcionalnosti, te ih treba doslovno programirati korištenjem onDraw metode ili slično. Kako je paleta ureñaja na tržištu velika, postoji dosta razlika meñu modelima. Tako na primjer često problem predstavljaju širina i visina ekrana. Android podržava dva načina odreñivanja veličine elemenata: statični i relativni. Dolazimo do zaključka kako je bolje koristiti relativni način odreñivanja veličine elemenata s obzirom na raspon veličine ekrana. Dakako ovakav način pozicioniranja za sobom dovodi specifične probleme. Ne rijetko dolazi do problema prilikom pozicioniranja elemenata ili previše kompleksnog dizajna. Provoñenje takvog dizajna ponekad nije efektivno, te bi se dizajnera trebalo obrazovati. Google tj. Andorid se i za to pobrinuo, te na svoje stranice stavio paket za dizajnere (engl. designer pack) u kojem se nalazi skoro sve za aktivni početak dizajniranja. Takoñer se na istima nalazi i vodič kako započeti, na što paziti i slično. Poznati „problem” prilikom izrade formi jest pozicioniranje tekstualnih oznaka (engl. label) u odnosu na polje za unos podataka bez definiranja fiksnih veličina. Rezultat je često jedan element prikazan lijevo, a drugi desno. Nažalost rješenje ovog problema je široko prihvaćeni „hack“ prikazan isječkom:

Kôd 24 Pozicioniranje kontroli relativno jednu do druge

Isto tako važno je znati prednosti i mane odreñene grupe pogleda (engl. View), kako biste mogli iskoristiti sve njegove prednosti a možda i sakrili mane.

Ako se na kratko osvrnemo na prije navedeno, primjećujemo kako programiranje u Androidu može jako brzo postati jako komplicirano.

6.5 Dinami čne liste

Tipičan primjer kompliciranja su dinamične liste vrijednosti. Takvom problemu se može pristupiti na dva načina, ovisno o mjestu i načinu primjene. Zamislimo dva scenarija, jedan scenarij potrebuje listu vrijednosti iz baze za izbor neke od ponuñenih vrijednosti, dok drugi predstavlja pretraživanje datoteke u sustavu.

<TableLayout android:id="@+id/buttons" android:layout_width="fill_parent" android:layout_height="wrap_content"> <TableRow> <ImageButton android:id="@+id/button_left " android:layout_width="0dip" android:layout_height="wrap_content" android:layout_weight="1" /> <ImageButton android:id="@+id/button_right " android:layout_width="0dip" android:layout_height="wrap_content" android:layout_weight="1" /> </TableRow> </TableLayout>


Adresirajmo prvo prvi scenarij. Raditi novu formu za izbor radi ovakvog problema može narušiti dizajn. Meñu naprednijim konceptima spominjali smo “Adaptere”. Isti su kreirani baš za ovakve svrhe.

Kôd 25 Dinamične liste uz pomoć adaptera

Primijetimo neke prednosti ovoga kôda: vrlo jednostavna primjena ovog koncepta je kada je poznat cilj i svrha, može se napraviti efikasno i modularno rješenje zahvaljujući sofisticiranom adresiranju polja (može se mijenjati način prikazivanja bez da se dira prikazani dio kôda), te brzina. Naime, u programiranju manje je više (engl. “less is more”).

Što se tiče drugog primjera, liste datoteka koje biste pretraživali, koristili bismo drugačiji adapter. Malim pretraživanjem dokumentacije primijetili bismo kako Android podržava nešto nalik na “Activity” ukoliko koristimo “ListView” kao omotač naših elemenata unutar forme. “ListView” je pogled u obliku liste, koji ima predefinirane akcije kao na primjer pretraživanje (engl. scroll). Prije spomenuti “Activity” je u stvari “ListActivity” - klasa koja proširuje activity. Putem nje može se prikazati lista i koristiti sve prednosti ovog pogleda. Takoñer kao u prethodnom primjeru postavljamo adapter na listu, u ovom slučaju na “Activity” što rezultira jednom listom, preko cijelog ekrana. Tada je jednostavno napraviti dodatnu funkcionalnost obzirom na neki od dogañaja.

Dakle, dva slična koncepta primijenjena na znatno različitim primjerima približavaju nas shvaćanju rada i razvoja aplikacija u ovom okruženju. Vrlo je važno, razlikovati i primjenjivati koncepte gdje su potrebni na način kako su zamišljeni.

5.6 Dretve

U napredne koncepte svrstane su i dretve. Višedretvenost je ponekad važna, no ne i neizbježna. Android posjeduje razne koncepte kojima omogućava izvršavanje aplikacije, te su dretve samo jedan segment istih. Prije same upotrebe dretvi trebali bismo znati prvo neke činjenice. Android posjeduje ANR dogañaj (engl. Application Not Responding) kako bi osigurao stabilnost OS-a [10]. Ukoliko je “UI Thread” blokiran dulje od približno 5 sekundi, javlja se ANR dijalog. Dedukcijom dolazimo do zaključka kako ne smijemo zaustaviti izvršavanje „UI Thread” iz razloga što to predstavlja loše korisničko iskustvo (engl. User Experience). Ako baš želimo koristi dretve, prebacujemo se na posebne, pozadinske dretve (engl. backround threads) ili dretve radilice (engl. worker threads) koje služe za izvršavanje zadatka na način da ne blokiraju glavnu dretvu. Android posjeduje razne načine komunikacije izmeñu dretvi, pa čak i komunikacije sa glavnom dretvom. Za razliku od kompliciranih dretvi, Android nudi sličnu zamjenu u vidu izvršenja asinkronog zadatka (engl. AsyncTask). Isti za razliku od dretve može biti pokrenut samo jedanput, te mora biti stvoren na glavnoj dretvi. Takoñer ima mogućnost rada u pozadini i to putem ugrañene funkcije doInBackground [10].

Kôd 26 Stvaranje dretve

Kôd 27 Stvaranje AsyncTask-a

Kratkim osvrtom primjećujemo kako Android očito pruža dosta jako razvojno okruženje. Uz dobru dokumentaciju i dobru ideju, lako je razvijati bogate aplikacije. Nešto malo vremena za programiranje, te nešto više vremena za razmišljanje rezultira formulom uspjeha u ovom okruženju.

6. ZAKLJU ČAK

U radu su opisani samo neki osnovni i neki napredniji koncepti koji se koriste prilikom izrade Android aplikacija. Ukazano je na mnoge prednosti i mane rada u ovoj platformi. Konzistentno provoñenje kvalitetne prakse i kulture programiranja na Android platformi ju svakako čini jednostavnijom i primamljivijim izborom. Koncepte je uvijek potrebno koristiti na način kako su i zamišljeni. Takvim pristupom aplikacije mogu dobivati na svrsishodnosti, te platforma profitirati zbog svojih načela otvorenog koda. Android platforma je od samih početaka bila stigmatizirana kao konkurencija Apple iPhone platformi (iOS). I kao takva se morala boriti kvalitetom kako bi opstala na tržištu. U zadnje vrijeme se sve češće može čuti i pročitati kako Android polako nadilazi iPhone i iOS. Tome se ponajviše može zahvaliti velikoj zajednici otvorenog koda koja do Androida nije imala svog predstavnika na tržištu mobilnih platformi. Google kao pokretač Android pokreta puno energije i resursa ulaže u održavanje zajednice kako bi ta ista zajednica vratila uloženo kroz unapreñenje Android platforme. Zbog svog ekskluzivnog odnosa prema svojim developerima Apple sigurno privlači jedan dio zajednice na svoju stranu unatoč tome što je financijski puno teže biti iOS developer nego Android developer gdje su svi resursi javno i besplatno dostupni osim, naravno, fizičkog ureñaja.

U samo 3. godine, od ne tako davne 2008. godine, primjećujemo solidan utjecaj ove platforme na mobilni svijet. Napredak, dorade, performanse a i tržište svakako govore za sebe. Tržište mobilnih aplikacija je danas

ArrayList<Map<String, String>> server_list = list_values; String[] from = {"name", "version"}; int[] to = {R.id.name, R.id.version}; SimpleAdapter adapter = new SimpleAdapter(getApplicationContext(), list, R.layout.list, from, to); list.setAdapter(adapter);

new Thread(new Runnable() { public void run() { final Bitmap b = loadImage(); image.post(new Runnable() { public void run() { image.setImageBitmap(b); } }); } }).start();

private class DownloadImage extends AsyncTask<String, Void, Bitmap> { protected Bitmap doInBackground(String url) { return loadImage (url); } protected void onPostExecute(Bitmap result) { image.setImageBitmap(result); } }


jedno od najkonkurentnijih tržišta gdje svi veliki igrači ulažu mnogo resursa za razvoj. Prepoznato je da je mobilna platforma sama po sebi beskorisna ukoliko ne posjeduje široku paletu aplikacija. Model malih i relativno jeftinih aplikacija na jednom mjestu se pokazao izuzetno primamljivim za potencijalne korisnike mobilne platforme. Mobilna platforma mora svojim tehničkim karakteristikama i jednostavnošću razvoja aplikacija moći privući što više developera koji će oplemeniti platformu za dodatnim aplikacijama. Uz tehnički dio, proizvoñač platforme mora developerima pružiti i

primamljiv poslovni model po kojem developer sudjeluje u dobiti koja je nastala prodajom aplikacije koju je on razvio. Nedostatak Android platforme je jedino u činjenici da su konačni korisnici, u pravilu, došli iz zajednice otvorenog koda i navikli su na besplatne aplikacije.

Kao i u drugim područjima, sraz izmeñu kvalitete i kvantitete te izmeñu poslovnih modela koji uključuju i ne uključuju plaćanje ima značajne i duboke argumente koji vuku na jednu i na drugu stranu. Smatramo da je najbolje ostaviti čitatelju da sam odluči.

Literatura:

1 Morrill D.: Announcing the Android 1.0 SDK, release 1, Android Developers Blog, 2008. Izvor: http://android-developers.blogspot.com/2008/09/announcing-android-10-sdk-release-1.html (učitano: 14.4.2011.)

2 Rogers R., Lombardo J., Mednieks Z., Meike B.: Android Application Development: Programming with the Google SDK, O'Reilly Media Inc., Sebastopol, 2009.

3 ***: Android Basics: Application Fundametals, Android Developers, 2011. Izvor: http://developer.android.com/guide/topics/fundamentals.html (učitano, 30.04.2011)

4 ***: Framework Topics: Audio and Video, Android Developers, 2011. Izvor: http://developer.android.com/guide/topics/media/index.html (učitano, 30.04.2011)

5 ***: Framework Topics: Data Storage, Android Developers, 2011. Izvor: http://developer.android.com/guide/topics/data/data-storage.html (učitano, 30.04.2011)

6 ***: Framework Topics: Graphics, Android Developers, 2011. Izvor: http://developer.android.com/guide/topics/graphics/index.html (učitano, 07.05.2011)

7 ***: Framework Topics: Location and Maps, Android Developers, 2011. Izvor: http://developer.android.com/guide/topics/location/index.html (učitano, 30.04.2011)

8 ***: Framework Topics: The AndroidManifest.xml File, Android Developers, 2011. Izvor: http://developer.android.com/guide/topics/manifest/manifest-intro.html (učitano, 09.05.2011)

9 ***: Framework Topics: User Interface, Android Developer, 2011. Izvor: http://developer.android.com/guide/topics/ui/index.html (učitano, 14.05.2011)

10 ***: Technical Resources: Painless Threading, Android Developers, 2011. Izvor: http://developer.android.com/resources/articles/painless-threading.html (učitano, 30.04.2011)

Podaci o autorima:

Ognjen Ribi čić, univ. bacc. inf. e-mail: [email protected] Ognjen Ribičić, univ. bacc. inf., je od svoje 13. godine u stalnom doticaju sa računalima i informatičkim svijetom, što i odabire kao svoju primarnu struku. 2009. godine završava svoje prvostupničko obrazovanje na Tehničkom veleučilištu u Zagrebu, te iste godine nastavlja naobrazbu na Fakultetu organizacije i informatike u Varaždinu. Područja interesa su mu razvoj mobilnih i Web aplikacija, te razvoj, održavanje i modeliranje baza podataka, što i jest njegovo usmjerenje na diplomskom studiju.

Boris Tomaš, mag. inf. tel: +385 42 390 853 fax: +385 42 213 413 e-mail: [email protected] Boris Tomaš, mag. Inf. je od 2010. godine zaposlen kao asistent na Katedri za razvoj informacijskih sustava na Fakultetu organizacije i informatike u Varaždinu. Na istom fakultetu je i student poslijediplomskog doktorskog studija Informacijskih znanosti. Područja interesa su mobilne aplikacije, razvoj programskih proizvoda, razvoj GIS aplikacija, multimedijski sustavi i aplikacijski marketing te marketing programskih proizvoda. Posjeduje dugogodišnje iskustvo sa Microsoft tehnologijama za razvoj aplikacija za većinu arhitektura i platformi.

Zlatko Stapi ć, mag. inf. tel: +385 42 390 853 fax: +385 42 213 413 e-mail: [email protected] Zlatko Stapić, mag. inf. je od 2006. godine asistent na Katedri za razvoj informacijskih sustava na Fakultetu organizacije i informatike u Varaždinu, te polaznik poslijediplomskog doktorskog studija Informacijske znanosti na istom fakultetu. Njegova nastavna aktivnost je prvenstveno usmjerena na kolegije koji se odnose na programsko inženjerstvo, analizu i


razvoj programa, modeliranje poslovnih procesa i razvoj informacijskih sustava, te značajne napore ulaže u radu sa studentima za što je dobio i posebna priznanja. Iz znanstvenog i stručnog rada treba izdvojiti višegodišnje voditeljstvo stručnih projekata razvoja programskih proizvoda i sudjelovanje na različitim stručnim i znanstvenim projektima iz područja razvoja, unapreñenja poslovnih procesa, projektnog menadžmenta i slično. U posljednje vrijeme se intenzivno bavi razvojem aplikacija za mobilne ureñaje, što je i predmet njegovog istraživanja u okviru doktorske disertacije, a osobito je vrijedno istaknuti da razvija za skoro sve platforme, uključujući izmeñu ostalog Android, Symbian te Windows Phone 7. Zlatkov detaljniji životopis, s popisom svih radova, projekata i nagrada, te drugih važnih podataka može se pronaći na njegovoj osobnoj web stranici, na http://www.foi.hr/djelatnici/zlatko.stapic. Zlatko Stapić is a young researcher and teaching assistant at the Faculty of Organization and Informatics working at the Information systems development department. His main areas of interests include classic and agile software engineering methodologies, software and information systems development, business processes modeling and others. Fakultet organizacije i informatike

Pavlinska 2

42000 Varaždin


GOOGLE APPS MOBILNE APLIKACIJE

GOOGLE APPS MOBILE APPLICATIONS

Adriana Baranek

SAŽETAK

Google Apps su web aplikacije koje povećavaju produktivnosti i u njima su uključeni Gmail, Docs, Sites, Calendar, Contacts, Groups, Chat. Kako bi i na mobilnim telefonima poslovni korisnici bili produktivni Google je razvio brojne mobilne aplikacije za Google Apps koje omogućavaju da i u pokretu komunicirate, organizirate se i surañujete sa svojim suradnicima. Izmeñu ostalog, pokazat ćemo kako, dok ste na putu, možete ispisati u uredu sa svog mobilnog ureñaja te kako s mobilnog ureñaja možete, zajedno s kolegama koji su u uredu, ureñivati dokument. Brojne su mogućnosti administriranja Google Apps domene a izmeñu ostalih administrator u tom dijelu upravlja i mobilnim ureñajima. Na kraju ćemo pokazati i neke od novosti koje su uvedene u Google Apps na mobilnim ureñajima tijekom zadnjih šest mjeseci. Ovaj rad će osigurati uvid u korištenje Google Apps na mobilnim telefonima ali i pokazati dubinu i širinu tehnoloških inovacija kojima Google poslovnim korisnicima omogućava vrhunsku efikasnost i produktivnost.

ABSTRACT

Google Apps is a suite of web appplications intended to increase productivity. These applications include Gmail, Docs, Sites, Calendar, Contacts, Groups and Chat. To ensure productivity to its business users, who are often depending on their mobile devices, Google has developed numerous mobile applications for Google Apps, thus enabling communication, organization and collaboration with colleagues while en route. We will have a small demo on how you can print from your office printer while out of office, with just a little help from your mobile device and how, with it, you can collaborate on a document with your colleagues in the office. Google Apps offers numerous possibilities for administration of Google Apps domains. Among them is the option for the administrator to manage mobile devices. To top it off, we will showcase several novelties which were introduced to Google Apps mobile devices in the past six months. This will provide insight into functionality of Google Apps on mobile devices and present how far Google technical innovations can go to enable its business users achieve maximum efficiency and productivity.

1. UVOD

Desetljeće nije posebno velik korak za čovjeka, ali jest za tehnologiju. Davne 1991. na sajmu u Genevi predstavljena je velika inovacija - pilotska mobilna mreža druge generacija - GSM. U početku se koristila samo za govornu komunikaciju, već iduće godine bila je omogućena komunikacija kratkim tekstualnim porukama - SMS-om - koje i danas koristimo. Mobilne mreže treće generacije koje se danas koriste za pružanje usluga mobilnog Interneta omogućavaju povezivanje brzinama od nekoliko megabita u sekundi u oba smjera što je više od onoga što pružaju uobičajene ADSL usluge povezivanja na Internet.

Prevladavajuće je vjerovanje da pametni telefoni i ostali prijenosni ureñaji danas donose novu kvalitetu u svijet tehnologije. Porast korištenja mobitela kao kompjutera potaknuo je renesansu u razvoju prijenosnog softvera. Iako su igrice još uvijek najprodavanija aplikacija, poslovni softver velikim koracima grabi ka vrhu. I to je trend koji ne pokazuje naznake usporavanja.

Prema istraživanju Google Apps Resellera iz New Yorka, White Stratus, 19,5% poduzeća u SAD-u koristi Google Apps u nekom obliku. Studija pokazuje da su Google Apps usluge ostvarile značajan utjecaj u korporativnom svijetu u odnosu na početak korištenja usluge.

Google Apps su web aplikacije koje povećavaju produktivnost, a korištenje mobilnih ureñaja je iznimno bitan dio života poslovnih ljudi. U skladu s tim Google

Apps su dostupne na mobilnim telefonima, nude razne opcije i mogućnosti koje poslovnim ljudima omogućuju punu produktivnost i izvan ureda.

2. GOOGLE APPS

Kolaboracija tj. suradnja meñu zaposlenicima oduvijek je bila glavni čimbenik dobrog i ažurnog poslovanja. Stoga je to bila i primarna ideja Googleovih programera. Ideja koja je postala temeljem i misli vodiljom kod osmišljavanja paketa usluga koji se danas zove Google Apps. Taj komplet usluga (Gmail, Docs, Calendar, Sites) fokusiran je na dva segmenta: komunikaciju i kolaboraciju. Google Apps osiguravaju veću produktivnost tako da su idealne aplikacije za suvremeno poslovanje.

SLA od 99.9% osigurava da će Vaši zaposlenici uvijek imati pristup aplikacijama koje su im neophodne za obavljanje radnih zadataka, a informatičari neće gubiti vrijeme vodeći računa o prekidima u radu sustava.

Google Apps imaju SAS 70 Type 2 i FISMA certifikaciju. Poduzeća mogu prilagoditi Google Apps kako bi se Google Apps uklopili u njihove tehničke, branding i poslovne zahtjeve. Google Apps se mogu povezati s postojećom IT infrastrukturom. Npr. Single sign-on povezuje Google Apps s Vašim postojećim sustavom autentikacije. Google Apps je moguće povezati i s postojećim imeničkim servisom.


Uz sve te mogućnosti koje Google Apps donose suvremenim poduzećima bilo je logično da će mobilni pristup tim uslugama biti iznimno bitan. Produktivnost zaposlenika nije samo ograničena na ured i na jednu lokaciju, kao nekada. Isto kao što danas očekujemo pristup Facebooku sa svih lokacija, nema razloga da za poslovne aplikacije ne vrijede isti zahtjevi. Komuniciranje sa suradnicima i poslovnim partnerima, organiziranje sastanaka, suradnja na dokumentima s mobilnih ureñaja, Google Apps na mobilnim ureñajima omogućavaju sve to i još puno više.

Google Apps na mobilnim ureñajima su u potpunosti besplatni za korisnike Google Apps te omogućuju pristup aplikacijama s BlackBerry, iPhone, Windows Mobile, Android ureñaja, ali i s manje moćnih ureñaja.

3. POSEBNOSTI GOOGLE APPS ZA MOBILNE UREðAJE

Google je za mobilne ureñaje razvio veliki broj posebno prilagoñenih aplikacija koje omogućavaju pristup svih Google aplikacijama. Isto kao što smo navikli da nam je npr. Facebook dostupan na putu, želimo imati dostup i svojim mailovima i dokumentima i izvan ureda.

Budući je za poslovne korisnike pristup Google Apps uslugama neophodan i izvan ureda u skladu s tim Gmail, Docs i ostale Google Apps usluge dostupne su im i na putu, na poslovnom sastanku ili na poslovnoj večeri.

Google je prilagodio svoje aplikacije za pojedine mobilne telefone. S vašeg mobilnog telefona možete pristupiti aplikacijama koje su prilagoñene za korištenje na njemu preko web-stranice: http://m.google.com.

S druge strane, za veliki broj pametnih mobilnih ureñaja postoje i posebne aplikacije koje omogućavaju pristup Google aplikacijama. Za daljnje informacije na osobnom računalu možete pronaći pregled aplikacija za različite mobilne ureñaje na stranici: http://www.google.com/mobile/more. Dostupnost i funkcionalnost aplikacija ograničena je na pojedine države, vrste i verzije mobilnih ureñaja te jezika na kojem se koriste aplikacije.

Za uvid u ponudu Google aplikacija na mobilnim telefonima, predstavit ćemo nekoliko najzanimljivijih aplikacija iz ponude:

� Google Mobile App aplikacija omogućava glasovno i tekstualno pretraživanje, a na većini telefona koristiti se za kratice prema drugim Googleovim aplikacijama. Na Blackberry telefonima omogućava i učinkovito pretraživanje elektroničke pošte. Aplikacija prepoznaje lokaciju i tako olakšava pretraživanje (npr. dovoljno je u tražilicu upisati samno “pizza” i ona će izbaciti poveznicu na najbližu pizzeriju). Riječi koje se pretražuju se pamte i tako se olakšava buduće pretraživanje. Moguća je i okomita pretraga aplikacija Google Maps, Images, News, i Shopping. Novost je ugrañen Google Googles (više u tekstu niže). Povezivanje s drugim Googleovim aplikacijama poput Gmaila i Mapsa je brzo i jednostavno.

� Google Sync aplikacija omogućava sinkronizaciju kontakata, elektroničke pošte i kalendara te udaljenu administraciju i za one telefone koji ne koriste operativni sustav Android. Na većini ureñaja Google Sync koristi Microsoft® Exchange ActiveSync® protokol.

� Google Maps - omogućava sigurno i brzo snalaženje na nepoznatim lokacijama nudeći cestovni i satelitski prikaz mjesta. Papirnate karte više nisu potrebne za snalaženje; u gradu u kojem ste po prvi put možete se snalaziti bolje od lokalnih stanovnika. Aplikacija ima ugrañeno odreñivanje pozicije korisnika tj. mobitela, što je obavezni temelj za mnoge njene funkcije. Jedna od najkorisnijih je jednostavni pronalazak sadržaja u vašoj blizini. Znači, u šetnji gradom uvijek ćete znati gdje je vama najbliži restoran, kino, ili bolnica. Do vašeg odredišta stići ćete i ugrañenom navigacijom koja će vas korak po korak dovesti do cilja. Upute su dostupne za pješake kao i za aute. Takoñer je moguć i višeslojni prikaz više značajki odjednom, na istoj karti. Npr. Promet, satelit, pretraživanje i dr.

� Google Places - potražite dućan, bankomat, restoran ili nešto drugo na karti i doñite do mjesta gdje se nalazi koristeći upute koje dobijete. Mjesta je moguće ocijeniti (Android) te pregledati ranije ocjene što olakšava odluku je li to pravo mjesto za vas. Pretraživanje je moguće po kategoriji i ključnoj riječi, a možete i sami dodati svoju kategoriju. Ova aplikacija ugrañena je i u Google Maps kako bi se ujedinile njihove značajke i korisniku dale maksimalni potencijal.

Slika 1 - Usporedba brzina pristupa Internetu


� Google Latitude - pogledajte gdje su prijatelji s kojima se nalazite ili provjerite ima li koga od vaših prijatelja u blizini. Ova aplikacija iznimno je korisna kod “gubitka” prijatelja ili poslovnog partnera koji je prvi puta u vašem gradu i negdje je krivo skrenuo i zalutao. Izgubljeni čovjek ne može vam reći gdje se nalazi, ali zašto vi to ne biste rekli njemu i izveli ga na pravi put. Naime, Latitude omogućuje dijeljenje lokacije s prijateljima i prikazivanje njihovih lokacija na karti. Nezamjenjivo za održavanje društvenog života, bez opterećenja. Provjerite je li u blizini netko od vaših prijatelja s kojim bi se mogli sastati ili doznajte je li vaš supružnik na poslu ili na putu kući pa može kupiti mlijeko. Pratite prijatelja koji putuje po svijetu. Uz sve to, privatnost vaših podataka i dalje je u vašim rukama jer vi nadzirete tko smije i kada vidjeti vašu lokaciju. Svoju lokaciju možete dijeliti, postaviti, sakriti ili se odjaviti iz usluge Google Latitude. Takoñer možete nadzirati tko može vidjeti vašu lokaciju i uz koju razinu detalja. Latitude nudi i dodatne mogućnosti. Možete doznati povijest svoje lokacije, postavite upozorenja, objaviti svoju lokaciju, integrirati je s Google Talk statusom i još mnogo toga.

� Google Goggles - pretražuje web pomoću slika. Goggles koristi tehnologiju prepoznavanja slika za prepoznavanje objekata i pomoću nje dostavlja relevantne rezultate pretrage. Identificira proizvod, poznate krajolike, pročelja dućana, umjetnička djela i popularne slike na webu. Ova aplikacija može i prevesti riječi na engleski, francuski, talijanski, njemački i španjolski. Goggles može izvesti informacije o kontaktu s vizitki.

� Voice actions (Android) - posljednja aplikacija koju je razvio Google za mobilne ureñaje. Možda i najzaraznija aplikacija, svojom praktičnošću, jednostavnošću te kratkim i logičnim naredbama, možda je i najzanimljiviji dodatak mobitelu.Za korištenje je, za sada, potrebno ispuniti dva uvjeta. Prvi je da koristite Android 2.2 (Froyo) ili noviju verziju, a drugi je da jezik ureñaja mora biti podešen na engleski. Potrebno je samo izgovoriti naredbu (npr. “send email to Mike LeBeau How's life in New York treating you? The weather's beautiful here!") i ureñaj će obaviti ostalo. Ukoliko pošaljete poruku na putu do posla, dok uñete u ured, u vašem inboxu bi vas već mogao čekati odgovor. Na ovaj način možete i nazvati neki dućan ili restoran (npr. “call pizzeria Venti New York), učitati web-stranicu (npr. go to Wikipedia”), pretraživati web Googleom (samo izgovoriti riječi za pretragu, npr. “pictures of Zagreb”) te mnogo drugih mogućnosti čiji se popis nalazi na http://www.google.com/mobile/voice-actions/

� Google Docs (Android) - aplikacija za ureñivanje i razmjenu sadržaja tj. dokumenata (tekst, slika, proračunska tablica, prezentacija itd.), dostupna je preko Android marketplacea. Ovom aplikacijom zaobilazi se potreba za preglednikom i izravno spaja na Google Docs korisnički račun. U Docsu se može zatim, zasebno ili više ljudi odjednom, ureñivati bilo koji dokument. uz ovu standardnu uslugu, moguće je i kamerom telefona slikati neku sliku i zatim ju konvertirati u tekstualni dokument u Google Docsu i dijeliti ga sa svojim kontaktima. Moguć je i izravni pristup Docsu putem prečica na početnom zaslonu. U Docse je ugrañen i OCR pa nije problem izraditi ni

Slika 2 - IPhone Google Mobile App

Slika 3 - Android Google Docs App


tekstualni dokument iz slikovnog dokumenta kao npr. fotografije.

� Gmail (Blackberry) - Blackberry telefoni pružaju mnogo mogućnosti, ponajprije za e-poštu. Aplikacija Gmail za Blackberry omogućava arhiviranje e-pošte, izvještavanje o spamu (neželjenoj pošti), a u organizaciji poruka pomažu zvjezdice i oznake. Razgovorni prikaz omogućava traženje relevantne poruke. Sve e to odvija uz stalnu sinkronizaciju podataka.

� 2-step verification (2 koraka provjere) - daje dodatnu sigurnost za korisnike Google Appsa zahtijevajući unos verifikacijskog koda, uz korisničko ime i lozinku, kod pristupa računu. Ovom provjerom štiti se korisnički račun od

neovlaštenog pristupa ako netko sazna lozinku. Čak i ako se lozinka probije, slučajno pogodi ili ukrade, lopov nema pristup ureñaju bez unosa verifikacijskog koda, do kojeg može doći samo korisnik preko svog mobilnog telefona.

� Google Cloud Print - uz korištenje preglednika Chrome ili štampača koji sam podržava Google Cloud Print, ova usluga - trenutno u beta verziji - omogućuje Vam povezivanje Vašeg Google Apps računa sa štampačem u uredu. Korištenjem te usluge i preko Vašeg mobilnog ureñaja možete ispisati svoje dokumente u uredu i dok ste na putu!

Zaposlenici tvrtke koji pristupaju uslugama Google Appsa mogu im pristupati s raznih mobilnih ureñaja uključujući Android, BlackBerry®, iPhone, Windows Mobile, te ostale ureñaje. Ovisno o ureñaju, korisnici mogu sinkronizirati svoj email i dogañanja u kalendaru koji se nalaze u sklopu njihovog Google Appsa računa sa svojim mobilnim ureñajem te koristiti ostale Googleove usluge na tom ureñaju.

Brojne su mogućnosti za konfiguraciju usluga Google Appsa na mobilnom telefonu. Za pomoć kod sinkronizacije ureñaja s drugim softverom na stolnom računalu kao što su to BlackBerry®

Desktop Manager, Microsoft® Outlook, i iTunes, potrebno je proučiti upute za korištenje samog ureñaja.

4. MOGUĆNOSTI ZA ADMINISTRATORE DOMENE NA KOJOJ SE KORISTI GOOGLE APPS

Google Apps administracija uključuje brojne mogućnosti kojima poduzeće koje koristi Google Apps usluge na svojoj domeni može na jednostavan način prilagoditi Google Apps usluge svojim politikama i procedurama.

Administratorska kontrola Google Apps-a za bilo koji mobilni ureñaj čini Google Apps snažnom mobilnom platformom za poslovanje i omogućuje poduzećima

Slika 4 - Google Apps panel za administraciju mobitela


postavljanje detaljnih postavki za upravljanje mobilnim aplikacijama..

Administratori mogu upravljati mobilnim ureñajima preko kontrolnog sučelja, a neke od mogućnosti koje su im dostupne su i: � Zahtjev da ureñaj koristi enkripciju podataka � Automatsko brisanje ureñaja nakon odreñenog broja

uspješnog unosa lozinke � Onemogućavanje korištenja kamere na mobilnom

ureñaju � Ograničavanja da se stare lozinke mogu više

koristiti � Zahtjev za promjenom lozinke nakon isteka

odreñenog vremena � Onemogućavanje sinkronizacije podataka kada je

ureñaj u roamingu kako bi se smanjio trošak.

Dostupnost značajki ovisi o ureñajima a više detalja nalazi se na stranici Mobile Security Settings (http://www.google.com/support/a/bin/answer.py?hl=en&answer=173393).

Ako niste sigurni je li taj proizvod ono što vam treba, Google Apps možete na brzinu isprobati tako da na bilo kojem mobitelu pokrenete Gmail and Google Calendar kao brze Web aplikacije (nije potrebno preuzeti aplikaciju).

Samo usmjerite svoj mobilni preglednik na adresu http://mail.google.com/a/your-domain.com ili http://calendar.google.com/a/yourdomain.com, i zamijenite your-domain.com u svakoj adresi imenom vaše domene. Više proizvoda i informacija možete

pronaći na stranici Google Mobile Products for Enterprise

Postoje i opcije kojima se osigurava dodatna zaštita. Google nudi mogućnosti za administratore Google Appsa da sami ureñaji zahtijevaju enkripciju podataka ili primjerice automatski obrišu sve podatke iz ureñaja u slučaju se odreñeni broj puta unese kriva lozinka a mogu i poslužiti za lociranje ureñaja u slučaju krañe.

Moguće je onemogućiti korištenje kamere telefona, i ponovno korištenje starih lozinki, te postaviti zahtjev da se nakon odreñenog vremenskog intervala traži promjena lozinke. Kod korisnika koji su često na putu u inozemstvu, moguće je onemogućiti sinkronizaciju podataka u roamingu, kako bi se kontrolirala potrošnja.

Isto tako, administratori Google Apps za korisnike podržanih vrsta mobilnih telefona imaju mogućnost brisanja svih podataka koji se nalaze na mobilnom ureñajima zaposlenika u slučaju krañe telefona.

5. IZVADAK IZ NEDAVNIH NOVOSTI VEZANIH UZ GOOGLE APPS NA MOBILNIM UREðAJIMA

Kao i sve Googleove usluge, i postojeće aplikacije za mobitele stalno se usavršavaju, te izrañuju nove koje odgovaraju na zahtjeve tržišta i kojima se želi podići razina iskoristivosti obilnih ureñaja.

Htjeli bi napomenuti da su u nastavku samo neke od najnovijih novosti vezanih uz Google Apps na mobilnim ureñajima.

1. Nova verzija Google Apps konektora za Blackberry Enterprise Server - podržana je Gmail funkcionalnost “Send as”

2. Nove opcije podržane u Google Sync za mobilne ureñaje - administratori mogu uključiti ili isključiti Google Sync za pojedine organizacijske jedinice u sučelju administratora

3. Google Docs aplikacija za Android - jednostavno kreirajte nove dokumente i pristupajte važnim materijalima, otvarajte dokumente iz Gmaila, OCR kako bi kreirali dokumente iz fotografija, dijeljenje dokumenata s kontaktima na telefonu

4. Undo opcija u mobilnom Gmailu - undo dolazi u pomoć i na mobilnim telefonima

Novosti o Google Apps uvijek možete detaljno pratiti na web stranicama Miadrije, na našoj Facebook stranici ili direktno na Google blogovima.

Slika 5 - Google Apps device policy

Slika 6 - Google Apps na mobilnim platformama


6. ZAKLJU ČAK

Veća produktivnost, sigurnost podataka, jednostavnost, uz uštedu vremena

Pristup informacijama, rad sa i na njima, te njihovo dijeljenje čine temelj na kojem se gradi produktivnost i dobri rezultati svake tvrtke. Veliki broj tvrtki svih veličina podesilo je snažni Google Apps koristeći brzu pretragu, razmjenu poruka i alata za kolaboraciju u oblaku, a sve to uz neusporedivo najbolju sigurnost i kapacitet. Ono po čemu se Google Apps razlikuje od drugih sličnih usluga u oblaku je mogućnost podešavanja raznih značajki kako bi korisnik sam mogao skrojiti uslugu kakva njemu

odgovara. Dakle, ovaj proizvod se prilagoñava korisniku, a ne korisnik njemu. To su karakteristike i ostalih spomenutih aplikacija koje prvenstveno služe za bolje i učinkovitije poslovanje, no korisne su i u svakodnevnom životu.

Pametni telefoni, kao prijenosna računala, udvostručuju produktivnost i štede vrijeme jer vrijeme provedeno izvan ureda (npr. na putu) više nije prazan hod.

Uz pametni telefon i Google Apps, važna pitanja možete doslovno rješavati na putu. Na taj način Vaša produktivnost i efikasnost, a i zadovoljstvo bit će veći.

Literatura:

1 http://www.whitestratus.com/articles/have-you-gone-google

2 http://www.google.com/apps/intl/en/business/index.html

3 http://www.google.com/mobile/

4 www.google.com/support/a/bin/answer.py?hl=en&answer=173393

Podaci o autoru:

Adriana Baranek Miadria d.o.o. za usluge Direktorica Adresa: Ilica 1/A, 5. kat Telefon: +385/1/3090-917 Fax: +385/1/4841-704 E-mail: [email protected] Adriana Baranek je direktorica poduzeća Miadria koje je Google Apps Authorized Reseller. Po struci je diplomirana ekonomistica, a 17 godina radila je u Zagrebačkoj banci kako na visoko specijaliziranim poslovima računovodstva i izvještavanja, tako i na poslovima voditeljice Ureda za odnose s dioničarima i rating agencijama. Njena najuža specijalnost je primjena informatike u poslovanju kroz implementaciju naprednih informatičkih rješenja na način koji omogućava i naprednim korisnicima ali i onima koji tehnologiju još nisu u potpunosti usvojili povećanje efikasnosti i produktivnosti u svakodnevnom radu ali i u strateškom odlučivanju. Adriana Baranek is CEO of company Miadria, Google Apps Authorized Reseller from Croatia. She mastered economics from Zagreb University and has been with Zagrebačka banka for 17 years in highly specialised accounting and reporting functions but also as Zagrebačka banka Investor Relations Officer. Her specialty is application of information technology solutions in businesses environment through implementation of advanced IT solutions in a way that enables both advanced users and users that have not fully mastered IT technology to increase efficiency and productivity in day-to-day activities and in making strategic decisions.

CASEcloud - CLOUD COMPUTING POSLOVNA INTELIGENCIJA 123

KRITIČNI FAKTORI USPJEHA IMPLEMENTACIJE ERP SUSTAVA

THE CRITICAL SUCCESS FACTORS OF ERP SYSTEMS IMPLEMENTATION

Damir Stepani ć, prof.dr.sc. Katarina Ćurko

SAŽETAK:

Današnji ERP sustavi podržavaju širok spektar industrija i nastavljaju ugrañivati sve više funkcionalnosti za poduzeća. Takav razvoj tržišta uvjetovan je interakcijom korisnika ERP sustava koji konstantno zahtijevaju promjene i poboljšanja i proizvoñača koji pokušavaju svojim proizvodom najbolje podržati zahtjeve tržišta. Samim time, tržište se konstantno mijenja i ostaje jedno od najdinamičnijih segmenata IT tržišta.

Različiti načini pristupa ERP implementaciji donose različite ishode. Kako bi implementacija ERP sustava bila uspješna potrebno je pravilno izbalansirati kritične faktore uspjeha. Radeći istraživanje o tome koji su kritični faktori uspjeha u implementaciji ERP sustava, zašto su oni kritični te u kojoj mjeri su oni bitni za korisnike, konzultante i dobavljače, ovaj rad nastoji identificirati kritične faktore uspjeha u ERP implementaciji i objasniti utjecaj pojedinog faktora na uspješnost uvoñenja ERP sustava.

ABSTRACT:

Today's ERP systems support a wide range of industries and continue to incorporate more functionality for companies. Such market development is conditioned by the interaction of ERP systems users that require constant changes and improvements, and manufacturers who try to support market demands. Therefore, the market is constantly changing and remains one of the most dynamic segments of the IT market.

Different ways of approaching ERP implementation give different results. In order to successfully implement an ERP system it is necessary to properly balance the critical success factors. By researching what are the critical success factors in ERP implementation, why are they critical, and to what extent they are relevant to users, consultants and suppliers, this paper seeks to identify critical success factors in ERP implementation and to explain the impact of each factor on the success of ERP system introduction.

1. UVOD

Uspješne ERP implementacije donose velike koristi za poduzeće, ali isto tako mogu biti pogubne za organizacije koje ne uspiju u implementaciji. Tijekom posljednjeg desetljeća mnoga poduzeća investirala su značajna financijska sredstva u implementaciju ERP sustava, meñutim nisu svi projekti bili uspješni. Neuspješne implementacije mogu biti promatrane s dva aspekta: kompletan i djelomičan neuspjeh. Kompletno neuspješnim projektima implementacije se smatraju oni u kojima su kompanije odustale od realizacije ili su završili tako katastrofalno da su poduzeća pretrpjela dugotrajnu financijsku štetu, dok djelomično neuspjeli projekti završavaju s manjim procesima prilagodbe (Taube i Gargeya, 2005).

Analitičari obično smatraju neuspjehom ako su vremenski rok i implementacijski troškovi višestruko prekoračeni (preko 200%) , ako ciljevi nisu postignuti (manje od 50%) ili implementacija rezultira nekompletnom instalacijom modula sustava i zbog toga s koristima manjim od očekivanih (Al-Mashari, 2003). Čak i sa značajnim investicijama u vrijeme i resurse, nema garancije za uspješan ishod te podcjenjivanje kompleksnosti implementacijskog projekta čini jedan od glavnih razloga neuspjeha. Strana i domaća literatura navodi ovakve projekte kao visoko rizične s malom stopom uspjeha. Tako Magnusson et al. (2004) navode stopu neuspjeha od 90%, Kovačič i Bosilj Vukšić (2005) 89%-91%, Umble i Umble (2002) 50%-75%, Zhang et al.

(2003) 67%-90%, dok Sarkis i Sundarraj (2003) spominju stopu neuspjeha od dvije trećine.

Cilj ovog rada je detaljnije istražiti kritične faktore koji utječu na uspjeh implementacije ERP sustava te istražiti kako oni utječu na smanjenje stope neuspjeha. O samoj problematici implementacije ERP sustava postoji opsežna literatura, no kao što je napomenuto zbog visoke stope neuspjeha nova istraživanja u ovom području su nužna. Postoji dakle mnoštvo novih mogućnosti za dodatna istraživanja koja mogu voditi novim otkrićima te tako doprinijeti smanjenju stope neuspjeha projekta implementacije. Nadalje u samoj literaturi koja se bavi tematikom ERP implementacije nedostaje opisa neuspješnih projekata u praksi, što samo po sebi nije čudno, jer poduzeća nevoljko javno izlažu neuspješne projekte, što dalje navodi na potrebu i važnost o opširnijem istraživanju faktora koji utječu na uspješnost implementacije ERP sustava (Zhang et al., 2003).

2. DEFINIRANJE KRITIČNIH FAKTORA USPJEHA

Kritični faktori uspjeha (KFU) se često koriste kako bi se identificirali i utvrdili ključni elementi potrebni za uspjeh poslovne operacije (Hossain i Shakir, 2001). Nadalje kritični faktori uspjeha se mogu opisati kao mali broj operativnih ciljeva koje je lako utvrditi, uobličenih od industrije, poduzeća, voditelja i okoline koji osiguravaju uspjeh organizacije (Laudon i Laudon, 1998). Rockhart i

124 CASEcloud - CLOUD COMPUTING POSLOVNA INTELIGENCIJA

Scott (1984) daju sličnu definiciju te napominju da su KFU operativni ciljevi poduzeća i ostvarenje ovih ciljeva će osigurati uspješno djelovanje.

Rockhart (1982) napominje da upotreba i definiranje KFU ovise o subjektivnoj sposobnosti, stilu i perspektivi rukovoditelja. Nadalje objašnjava da se oblikovanje KFU može promatrati s četiri točke gledanja: oni koji su oblikovani od industrije, oblikovani operativnim strategijama poduzeća te oni koji su oblikovani percepcijom upravitelja i promjenama u okolini.

U radu će biti analizirani KFU u implementaciji ERP sustava s aspekta operativne strategije poduzeća jer ERP sustav uključuje znanje o poslovnoj praksi, akumulirano iz provedenih implementacija u mnogim organizacijama, od strane proizvoñača (Seddon i Shang, 2002).

2.1 Mjerenje i definicija uspjeha

Jedna od najtrajnijih tema u području informatičkih sustava je o uspjehu sustava (DeLone i McLean, 1992). Prijašnja istraživanja su adresirala mjerenje rezultata, činitelja koji su prethodili uspjehu i objašnjenja uspjeha i neuspjeha. No meñutim s pojavom novih informacijskih tehnologija pojavljuje se ponovno pitanje uspjeha. U okviru ERP sustava, uspjeh ima posebnu važnost budući da su troškovi i rizici implementacije i usvajanja vrlo visoki.

Optimalni uspjeh se odnosi na najbolje ishode koje poduzeća mogu postići s poslovnim sustavima, uzimajući u obzir njihovu poslovnu situaciju, mjerenim naspram portfelja projekta, operativnom i dugoročnom poslovnom metrikom (Markus i Tanis, 2000). Optimalni uspjeh može biti dinamičan, u smislu da ono što je moguće za organizaciju može varirati vremenom, kako se mijenjaju uvjeti poslovanja.

Definicija i mjerenje uspjeha nisu lagan posao, jer uspjeh ovisi o točki gledanja s koje se vrši mjerenje. Obično se misli na različite stvari kada se govori o uspjehu ERP projekta. Voditelji projekta i ERP konzultanti često definiraju uspjeh u smislu izvršenja projektnog plana na vrijeme i u okviru budžeta. No meñutim korisnici čiji je posao usvajanje i korištenje ERP sustava naglašavaju važnost odvijanja operacija bez poteškoća u ERP sustavima i postizanje poslovnih unapreñenja (Axline et al., 2001).

Važan čimbenik u mjerenju uspjeha proizlazi i iz činjenice kada se uspjeh mjeri (Larsen i Myers, 1997). Voditelji projekta i implementatori si mogu dopustiti promatranje uspjeha u kratkom roku, ali investitori i rukovoditelji poduzeća imaju dugoročnu perspektivu (Axline et al., 2001). Dodatno Axline (2001) napominje da poduzeća koja su implementirala ERP sustav trebaju promatrati uspjeh na dugi rok, a ne samo u trenutku usvajanja.

Još jedan važan faktor u mjerenju uspjeha je usvajanje ciljeva, očekivanja i percepcija onih koji usvajaju sustav kao standard za definiranje i mjerenje uspjeha. U ovom slučaju kriterij osoba koje usvajaju sustav se koristi za utvrñivanje stvarnog nivoa postignuća. Ali ove subjektivne procjene mogu biti nepouzdane jer koriste interne mjere i ciljeve koji ne mogu biti prihvatljivi svakom poduzeću te se na taj način ne mogu generalizirati za sve slučajeve.

Kod implementacije ERP sustava takoñer treba imati na umu da to nije informatički projekt i da glavne odluke treba donositi poslovanje, budući da projekt implementacije predstavlja dio poslovne strategije. Iako je izbor ERP sustava veoma važan za uspjeh

implementacije, sama tehnologija ne smije zasjeniti poslovne potrebe. Ako su izbor i implementacija uglavnom voñeni od strane informatičkih stručnjaka, a manje od strane eksperata iz područja poslovanja, tvrtka ulazi u prilično veliki rizik u pronalaženju pravog odgovora na krivo postavljeno pitanje. Zapravo, sve treba započeti na postavkama strateškog cilja tvrtke, i očekivanjima od novog sustava, odnosno jasne definicije što novi sustav mora raditi. Sva funkcionalna područja tvrtke moraju izraziti svoja mišljenja kako bi projekt uspio. Tehnološki eksperti trebaju imati čvrsti stav kod donošenja odluke u izboru same tehnologije, koja treba biti stup projekta.

Kako bi se mogla provoditi implementacija ERP sustava potrebno je točno postaviti i konfigurirati mrežu i kompjutorsku okolinu, a prije samog puštanja u stvarni rad neophodna su mnoga testiranja kako rada sustava tako i testiranje izvršavanja poslovnih transakcija. Takoñer bi trebalo imati na umu da ne postoji savršeni softver kao ni savršena implementacija.

2.2 Analiza troškova

Ukupan trošak vlasništva (engl. Total Cost of Ownership - TCO) predstavlja važan faktor koji utječe na ERP strategije i odluke. On predstavlja ukupan iznos troškova koji će nastati kroz životni vijek sustava (Bradford, 2008). Općenito na TCO utječu: � Veličina poduzeća – veći poslovni volumen zahtijeva

skalabilan sustav, koji je sposoban podržati veliki broj transakcija.

� Broj ERP korisnika – više korisnika znači kompleksnije upravljanje i više pristupa izlaznim/ulaznim ureñajima. Nadalje dobavljači ERP sustava uobičajeno naplaćuju licence po broju i tipu korisnika.

� Funkcionalnost – dubina i širina funkcionalnosti koja će biti podržana od sustava obično ovisi o broju implementiranih modula.

Aberdeen grupa je 2006. godine provela analizu, u 1100 poduzeća raznih veličina, o ukupnim troškovima implementacije. Na temelju tog istraživanja spoznali su tri različita elementa ukupnih troškova povezanih s ERP implementacijom: � iznos potrošen na softver, � iznos potrošen na eksterne usluge, � interni troškovi.

Dodatno razni autori navode još i trošak hardvera kao dio ukupnih troškova. Za funkcioniranje ERP sustava potrebna je odgovarajuća IT infrastruktura: poslužitelji, mrežne komponente, radne stanice. Meñutim neki od ovih troškova mogu se izbjeći ako se sustav iznajmljuje od drugih poduzeća (engl. Hosting).

Kupnja ERP softvera obično obuhvaća troškove licenciranja koji reguliraju upotrebu softvera. Tipično cijena za licence ovisi o broju krajnjih korisnika i o broju implementiranih modula. Na primjer ako poduzeće odluči implementirati modul za financije, upravljanje ljudskim potencijalom, obračun plaća, upravljanje odnosa s kupcima, proizvodnju ili ima veliki broj korisnika, trošak licenci će biti veći nego za manje poduzeće s manjim brojem korisnika i s manje modula. Dobavljači dodatno otežavaju kalkulaciju omogućujući popuste na volumen koji smanjuju cijene po modulu ili po korisniku. ERP sustavi takoñer iziskuju pohranu podataka te je potrebno takoñer licencirati i upotrebu baze podataka. Trošak licence za bazu podataka se obično temelji na broju korisnika koji će ulaziti u sustava ili na broju procesora.


Bilo koja implementacijska faza može uključivati angažman vanjskih resursa koji uključuju konzultante, specijaliste za implementaciju i upravitelje projektima. Troškovi usluga se teško procjenjuju i najčešće predstavljaju najveću stavku u budžetu ERP implementacije. Iako mnogi planeri projekta aproksimiraju ove troškove koristeći omjer troškova licenci prema troškovima implementacije, potrebno je istaknuti da troškovi implementacije imaju više veze s kompleksnošću poslovnih procesa koji se implementiraju nego s brojem licenciranih korisnika. Odreñeni softverski produkt može imati 2:1 implementacijski omjer, što znači da za svaku utrošenu jedinicu na softver korisnik planira utrošiti dvije jedinice na implementacijske troškove. Često omjer troškova usluga i troškova softvera pruža indikaciju o prilagodljivosti i lakoći implementacije sustava za napredne funkcionalnosti.

Interni troškovi variraju izmeñu poduzeća i projekata, pa je stoga ovu komponentu teško procijeniti. Najveći faktor internih troškova je gubitak produktivnosti za članove projektnog tima koji pored svojih regularnih dužnosti sudjeluju i u implementaciji. Većina članova projektnog tima utrošiti će 100% njihovog vremena na projektne zadatke u najintenzivnijim fazama projekta. Za procjenu internih troškova, može se koristiti kalkulacija prema ekvivalentu punog radnog vremena (engl. Full Time Equivalent – FTE) koji će biti potreban za projekt. FTE se kalkulira tako da se pomnoži postotak vremena projektnih članova posvećenih projektu s dužinom njihovog angažmana na projektu i s ukupnim brojem članova tima. Troškovi izobrazbe kadrova često se podcjenjuju, iako su to vrlo visoki troškovi i često se prave greške zaboravljajući da se radnici moraju prilagoditi na novi softver i nove procese. Izobrazba izvan tvrtke odnosi se uglavnom na korištenje softvera, što nije dovoljno jer korisnika treba podučiti i novom načinu rada, a takvo znanje može dobiti samo unutar tvrtke. Kako bi korištenje softvera bilo pravilno, osobe koje educiraju zaposlenike moraju imati široko znanje o tome kako se neki procesi izvode u drugim tvrtkama i kako su se ti procesi izvodili prije uvoñenja ERP sustava. Zbog toga, IT odjel i poslovanje zajedno trebaju osigurati kvalitetnu obuku korisnika.

Konačno potrošnja ne završava s puštanjem sustava u produkciju. Troškovi održavanja za nadogradnju hardvera, potrebe za dodatnim konfiguracijama te podrška sustavu se takoñer moraju uzeti u obzir. Poput implementacijskih troškova, troškovi održavanja i podrške se mogu takoñer izračunati kao postotak od cijene licence. Mnogi dobavljači softvera naplaćuju periodično troškove održavanja i podrške koji pokrivaju povremene usluge konzaltinga, tehničke podrške, ispravku grešaka (engl. Bugs) i nadogradnju na nove verzije.

Istraživanja pokazuju da mnoga poduzeća podcjenjuju TCO koji proizlaze iz spomenutih sfera. Najveći krivac za to je podcjenjivanje i nepoznavanje ukupne veličine

internih troškova. Istraživanje Aberdeen grupe (2006) potvrdilo je upravo tu činjenicu. Iako interni troškovi čine značajni dio ukupnih troškova, veliki dio ispitanika nije ponudio iznos internih troškova, dok oni ispitanici koji su ponudili iznos, on je prema mišljenju Abredeen grupe bio značajno podcijenjen. Ta činjenica je navela na zaključak da mnoga poduzeća nemaju adekvatni način procjene internih troškova te iako čine značajni dio ukupnih troškova, nisu uključeni u elemente komparacije Aberdeen studije.

Prirodno bi bilo očekivati korelaciju izmeñu veličine ERP implementacije i troškova. Kako raste veličina poduzeća, broj korisnika se povećava zajedno s ukupnim troškovima softvera i usluga. Kako su popusti na volumen standardna pojava u odreñivanju cijene ERP sustava, za očekivati je da se smanjuju troškovi po korisniku kako raste broj korisnika. Ovo očekivanje se pokazalo točnim kao što se može i vidjeti iz tablice 1. koja prikazuje prosječan trošak softvera i usluga prema veličini poduzeća prema istraživanju Aberdeen grupe. Istraživanje je pokazalo da je i pretpostavka ako raste broj korisnika ukupni troškovi softvera i odražavanja rastu, takoñer točna.

Meñutim, iako cijena softvera po korisniku konzistentno pada s dodatnim korisnicima, to ne mora biti slučaj is ukupnim troškovima softvera i usluga. Iz tablice 1. je vidljivo da cijena softvera i usluge po korisniku pada kako raste veličina poduzeća, meñutim poduzeća s prihodom iznad 1 milijarde USD ustvari plaćaju više po korisniku nego poduzeća u rasponu prihoda od 500 milijun USD do 1 milijarde USD. To je rezultat kombinacije faktora. Prije svega implementacije u velikim poduzećima su izuzetno kompleksne. Dodatno, manja poduzeća nastoje zbog ograničenih budžetnih sredstava manje koristiti vanjske resurse i na taj način smanjiti troškove.

Postoje i skriveni troškovi povezani s implementacijom ERP sustava. Jedan od skrivenih troškova je i konstantno klizanje opsega projekta, u smislu stalnog povećanja opsega projekta. Troškovi konverzije podataka čine takoñer skrivene troškove. Prije same konverzije podataka iz starih sustava, oni se moraju očistiti. Čišćenje podataka može zahtijevati ponovni pregled kako bi se uskladila neophodna modifikacija procesa. Većinu starih podataka nemoguće je konvertirati pa se oni moraju ručno unositi u novi sustav što znači dodatno trošenje vremena i novca. Troškovi prilagodbe sustava odnose se na prilagodbu u smislu mijenjanja standardnog ERP softvera koje treba izbjegavati ako je ikako moguće. Kada ERP softver ne može podržati jedan od poslovnih procesa i kad se donese odluka da se izmijeni standardno rješenje, takva prilagodba se može odraziti na svaki modul jer su oni usko povezani.

Svakom novom nadogradnjom ERP paketa, potrebno je ponovo provoditi prilagodbu u sustavu jer ona nije uključena u novu verziju. Kako ovo nije posao

Tablica 1 Prosječan trošak softvera i usluga po veličini poduzeća Izvor : Aberdeen Group, 2006

Prosječan

broj korisnika

Prosječna cijena

softvera ($)

Cijena softvera po korisniku

($)

Prosječna cijena

usluge ($)

Prosječna cijena

softvera + usluge ($)

Cijena softvera + usluga po

korisniku ($) Ispod 50 milijuna $ 38 138,806 4,820 98,635 235,606 7,853

Od 50 mil. $ do 100 milijuna $ 84 363,425 4,622 339,321 702,746 8,827 Od 100 mil. $ do 250 milijuna $ 150 480,048 3,171 485,590 965,638 6,869 Od 250 mil. $ do 500 milijuna $ 256 527,273 2,916 600,455 1,127,727 6,247

Od 500 mil. $ do i milijarde$ 292 561,667 2,463 495,000 1,056,667 2,537 Preko 1 milijarde$ 1,485 1,137,500 1,535 1,562,500 2,700,000 3,278


dobavljača, mora se osigurati dodatni kadar koji će raditi na takvoj prilagodbi i njenom daljnjem održavanju. Troškovi integracije i testiranja zavise o potrebi povezivanja postojećih i novih rješenja. Testiranje ERP integracije mora biti provedeno kroz procesno orijentiranu perspektivu, pa je dobro da se umjesto testnih podataka i prijenosa podataka iz jedne aplikacije u drugu pokrene poslovni proces koji će imati za cilj kreirati stvarnu narudžbu kroz sustav i to od ulaza narudžbenice, kroz otpremnicu i primku do plaćanja sa sudjelovanjem zaposlenika koji će taj posao obavljati. Temeljito kreiranje budžeta implementacije ERP sustava zahtijeva od projektnog tima dubinsko snimanje za vrijeme faze planiranja razvoja životnog ciklusa ERP sustava.

2.3 Podjela kriti čnih faktora uspjeha

Različiti kritični faktori uspjeha (KFU) ERP implementacije i različita klasifikacija po važnosti se citira u literaturi. Nekoliko autora je pisalo o uspjesima i neuspjesima ERP implementacije, ali se uglavnom fokusiraju na uska područja poput poslovne strategije, tehnologije ili prilagoñenosti organizacije (Hong i Kim, 2002).

Proučavani su kritični faktori uspjeha od različitih autora poput Al-Mashari et al. (2003), Esteves-Souza i Pastor-Collado (2000), Gargeya i Brady (2005), Holland i Light (1999), Kuang et al (2001), Magnusson et al. (2004), Somers i Nelson (2004), Sternad et al. (2007), Umble et al. (2003) i dr. Usprkos različitosti, pregled literature omogućuje sažimanje odreñenog broja kritičnih faktora uspjeha, koji su najčešće navoñeni od autora.

Nakon proučavanja različitih kritičnih faktora citiranih od raznih autora te temeljem vlastitog iskustva i razumijevanja generirana je lista faktora koju autori rada smatraju važnom i povezanom s uspješnom implementacijom ERP sustava.

Radeći analizu, neki faktori su grupirani u jedan faktor jer autori smatraju da su usko povezani. Na primjer, faktor sponzor projekta je stavljen pod faktor podrška vrhovnog menadžmenta. Podrška vrhovnog menadžmenta je širok pojam koji obuhvaća sve aktivnosti od podrške, odobrenja, identificiranja projektnih prioriteta do alociranja resursa. Sljedeći primjer je stavljanje faktora edukacija korisnika pod faktor program upravljanja promjenama budući da on obuhvaća komponente od prepoznavanja potrebe za promjenom do edukacije i treninga krajnjih korisnika i IT službe.

Na taj način je prepoznato deset faktora koji su po mišljenju autora kritični za uspješnu implementaciju ERP sustava:

1 podrška vrhovnog menadžmenta, 2 poslovni plan i vizija, 3 strategija implementacije, 4 program upravljanja promjenama, 5 projektni menadžment, 6 projektni tim, 7 modeliranje poslovnih procesa s minimumom

prilagodbi, 8 nadzor i ocjenjivanje rada, 9 razvoj softvera, testiranje i rješavanje problema, 10 stari (engl. Legacy) sustavi.

Kritični faktori uspjeha bi se trebali klasificirati unutar specifičnih kriterija zbog lakšeg razumijevanja, poput modela koji su prezentirali Pinto i Slevin (1987), a kasnije proširili Holland i Light (1999).

Upravo su Pinto i Slevin (1987) prvi argumentirali da voditelji projekta moraju biti kompetentni i u strateškim i u taktičkim aspektima upravljanja ERP projektom kako bi uspješno upravljali istima. Kako bi to razjasnili napravili su profil projekta ERP implementacije koji se sastojao od deset kritičnih faktora uspjeha organiziranih u strateškom i taktičkom okviru. Kritični faktori uspjeha podijeljeni su u stratešku (plansku) fazu i taktičnu (akcijsku) fazu implementacijskog projekta.

Strateški dio odnosi se na misiju projekta, podršku vrhovnog menadžmenta i na projektni plan s naznačenim individualnim aktivnostima projektne implementacije. Taktički elementi sastoje se od komunikacije izmeñu svih utjecajnih skupina, uključivanja potrebnih kadrova u projektni tim te pribavljanje potrebne tehnologije i ekspertize za tehničke aktivnosti. Korisničko prihvaćanje, nadziranje u svim fazama i rješavanje problema su takoñer klasificirani kao taktički faktori (Pinto i Slevin, 1987). U radu je odabran njihov tip klasifikacije jer podjela kritičnih faktora uspjeha u strateške i taktičke pridonosi jednostavnijem razumijevanju i isticanju razlika.

Holland i Light (1999) dalje su proširili model kritičnih faktora uspjeha ERP projekata i njihove integracije. Oni su takoñer grupirali kritične faktore uspjeha u strateške i taktičke, ali sami faktori su dodatno prošireni (Tablica 2.).

Holland i Light naglasili su potrebu usuglašavanja poslovnih procesa sa softverom tijekom implementacije. Dalje argumentiraju da strategija i taktika nisu meñuovisne, Benjamin i Levinson (1993) takoñer identificiraju potrebu za upravljanjem organizacijskim, procesnim i tehnološkim promjenama u sveobuhvatnom smislu. Strategija mora voditi taktiku u cilju potpune integracije triju glavnih upravljačkih procesa: planiranja, izvršavanja i kontrole (Holland i Light, 1999).

Neki autori smatraju da osim strateških i taktičkih okvira za podjelu kritičnih faktora uspjeha, postoji i kulturološki okvir. Oni smatraju da organizacijska kultura značajno utječe na implementaciju ERP sustava u poduzeću te svrstavaju pojedine faktore pod taj okvir. No meñutim autori smatraju da kulturna različitost podjednako utječe na sve faktore, a ne samo na pojedine te vodi ka različitim rezultatima ERP implementacije.

Dakle, kultura je uključena u strateške i taktičke faktore koji direktno ili indirektno utječu na implementacijski proces ERP sustava. Kada dva poduzeća implementiraju potpuno iste ERP sustave, ponekad je ishod sasvim različit (Seddon et al., 2003). Tehnički problemi mogu biti analizirani i riješeni od strane stručnjaka, no meñutim ljudskim faktorom je mnogo teže upravljati. Usvojena korporativna kultura predstavlja faktor koji se ne može zanemariti u smislu uspješnosti ERP implementacije. U implementaciji ERP sustava kulturološke faktore dijelimo

Tablica 2 Podjela kritičnih faktora Izvor: Holland i Light, 1999

STRATEŠKI TAKTIČKI

Konzultacije klijenta

Informacije iz starih sustava Ljudstvo

Poslovna vizija Promjena poslovnih procesa i postavke softvera

ERP strategija Prihvaćanje od strane korisnika

Podrška vrhovnog menadžmenta

Nadziranje i povratne informacije

Projektni plan Komunikacija

Uklanjanje grešaka


na organizacijsku kulturu, učinkovitu komunikaciju i kulturološku različitost izmeñu korisnika, konzultanata i isporučitelja.

Organizacijska kultura je podijeljena u tri sloja (Schein, 1992). U vanjskom sloju nalaze se vrijednosti o strategiji, misiji, ciljevima organizacije. U srednjem sloju nalaze se vjerovanja, koja predstavljaju teme o kojima zaposlenici organizacije razgovaraju. U unutarnjem sloju nalaze se pretpostavke koje se uzimaju 'zdravo za gotovo', a koje predstavljaju one aspekte organizacijskog života koje je teško objasniti. Svi ti kulturološki aspekti utjecati će na način rada u organizaciji. Kultura za zajedničkim vrijednostima i ciljevima vodi ka uspjehu jer naglašava kvalitetu i spremno prihvaća nove tehnologije te znatno pomaže u implementacijskom naporu (Kuang et al., 2001). Budući da su strateška rješenja, ERP sustavi će promijeniti način na koji su ljudi navikli raditi. Inovativne, otvorene organizacijske kulture će olakšati sudjelovanje korisnika kroz cijeli proces implementacije. Otvorene i kreativne kulture prepoznaju zaposlenike kao primarni izvor ideja, akcija i učinka, što rezultira stabilnim radnim okruženjem koje osnažuje odanost zaposlenika (Ross, 1996). S druge strane, organizacijska kultura koja ne podupire učenje i dijeljenje informacija djelovati će obeshrabrujuće na zaposlenike i utjecati na mogućnost neuspjeha u implementaciji novog sustava.

Učinkovita komunikacija je ključni faktor u organizacijskom i individualnom uspjehu. Način na koji primamo, povezujemo i dajemo poruke u organizaciji može biti ključ uspjeha i u implementaciji ERP sustava (Harris, 2002). Djelotvorna komunikacija može olakšati penetraciju novog sustava u organizaciju. Trebala bi obuhvatiti sve nivoe poduzeća, od višeg menadžmenta da operative, kako bi svi bili upoznati s promjenama poslovnih procesa koje donosi uvoñenje ERP sustava koji će utjecati na njihova ovlaštenja i obveze. Učinkovita komunikacija potiče volju za sudjelovanjem u promjenama i rezultira ubrzavanjem reinženjeringa poslovnih procesa. Konstantna komunikacija pomaže takoñer u otklanjanju otpora uvoñenja novog sustava u čitavom poduzeću. Upoznavanje zaposlenika s onim što se mijenja, zašto se mijenja i kako će to pomoći organizaciji važno je za prihvaćanje projekta (Mendel, 1991). Zbog toga, efektivna komunikacija mora biti formirana i podržavana kroz cijelo poduzeće, dok traje implementacija ERP sustava. Komunikacija uključuje formalnu promociju projektnog tima i objavljivanje

napretka projekta ostatku poduzeća. S druge strane, komunikacija izmeñu internih i eksternih grupa (isporučitelja i konzultanata) ne može takoñer biti zanemarena. Dobra komunikacija može maksimizirani podršku od strane isporučitelja i konzultanata, što u konačnici znači da poduzeće može bolje iskoristiti svoje tehničke resurse.

Kulturološka različitost izmeñu korisnika, konzultanata i isporučitelja označava ne samo organizacijsku kulturu nego i nacionalnu kulturu. Trompenaars (1994) ističe kako se nacionalna kultura može opisati u tri razreda: kako se ljudi odnose jedni prema drugima, kakav imaju stav prema vremenu i odnos prema okolini. Prema Coulianos et al. (2000) mogu postojati dva problema: 1 Kultura isporučitelja, uključena u ERP paket, je u

sukobu s organizacijskom kulturom korisnika. 2 Malobrojni konzultanti razumiju organizacijsku

kulturu i poslovne procese korisnika.

Dakle, uobičajeni problem kod uvoñenja ERP sustava je neprilagoñenost tj. nesrazmjer izmeñu funkcionalnosti koje nudi paket i funkcionalnosti koje su potrebne poduzeću. Kako bi premostili kulturnu različitost, poduzeća moraju odabrati izmeñu promjene organizacijske kulture i poslovnih procesa kako bi se uklopile u standardne ERP sustave ili prilagoditi (engl. Customize) paket kako bi funkcionalnosti softvera podržavale poslovne procese organizacije. Dakle, poduzeća moraju uzeti u obzir kulturološke različitosti izmeñu isporučitelja softvera, konzultanata i samih sebe prije nego li se odluče koji ERP sustav će nabaviti i implementirati. Jer u suprotnom bi moglo doći do velikih problema u napredovanju projekta ili čak napuštanja istog. (Marcus i Tanis, 2000).

Uzimajući u obzir sve navedene klasifikacije te iskustvo na implementacijskim projektima ERP sustava, dana je podjela kritičnih faktora uspjeha na strateške i taktičke, kao što je prikazano na tablici 3.

3. STRATEŠKI FAKTORI IMPLEMENTACIJE ERP SUSTAVA

Implementacijski proces se u ovom radu odnosi na razdoblje od iniciranja projekta do stavljanja u produkciju (engl. Going Live). Iniciranje projekta započinje s odlukom o financiranju ERP projekta. Nakon iniciranja projekta ERP sustava, slijedi kreiranje poslovnog

Tablica 3: Podjela kritičnih faktora uspjeha od strane autora

1. Podrška vrhovnog

menadžmenta

2. Poslovni plan i vizija

3. Strategija implementacije

4. Program upravljanja

promjenama

5. Projektni menadžment

1. Projektni tim

2. Modeliranje poslovnih

procesa s minimumom

prilagodbi

3. Nadzor i ocjenjivanje rada

4. Razvoj softvera, testiranje i

rješavanje problema

5. Stari sustavi

STRATEŠKI

TAKTI ČKI


slučaja, imenovanje voditelja projekta, selekcija softvera i implementacijskog partnera te planiranje projekta (Markus i Tanis, 2000). Nakon stavljanja ERP sustava u produkciju, on je u stvarnoj upotrebi kroz poslovne procese. Greške ( engl. Bugs) će se pojavljivati u ovom razdoblju i više rada će biti usmjereno na nadgledanje i konstantno prilagoñavanje sustava dok se greške ne eliminiraju i sustav ne stabilizira (Markus i Tanis, 2000).

U nastavku navodimo strateške kritične faktore koji utječu na uspjeh ERP implementacije.

3.1 Podrška vrhovnog menadžmenta

Podrška vrhovnog menadžmenta prepoznata je od strane mnogih istraživača kao jedan od ključnih faktora uspjeha ERP implementacije. Projekt mora imati odobrenje i podršku od vrhovnog menadžmenta (Bing et al., 1999; 1999; Shanks et al., 2000; Sumner, 1999). Vrhovni menadžment mora javno i eksplicitno prepoznati projekt kao prioritet (Shanks et al., 2000). Viši menadžment mora biti angažiran vlastitim sudjelovanjem i spremnošću da dodijeli vrijedne resurse za implementacijski projekt (Holland i Light, 1999). To uključuje ne samo pružanje odgovarajuće količine resursa i vremena za dovršetak posla, nego i neophodan kadar za implementaciju (Roberts i Barrar, 1992).

Stav vrhovnog menadžmenta prema projektu odreñuje količinu resursa dodijeljenih na projekt implementacije. U ERP projektima podrška vrhovnog menadžmenta je još važnija. Propagiranje i podrška od strane vrhovnog menadžmenta, kao simbola prioriteta poduzeća, može ojačati posvećenost svih zaposlenika u projekt. Podrška vrhovnog menadžmenta rezultira organizacijskom predanošću, koja je ključni faktor utjecaja na uspjeh ERP implementacije (Bingi et al., 1999). Pojedina poduzeća stavljaju odgovornost za implementaciju ERP sustava u ruke tehničkih odjela i tako čine vitalnu pogrešku koja često rezultira neuspjehom projekta. Dakle, može se zaključiti da uključenost samo IT odjela u ERP implementaciji nije dovoljna, nego glavna inicijativa treba dolaziti od vrhovnog menadžmenta, jer nedovoljna podrška od vrhovnog menadžmenta vodi ka neuspjehu projekta. Drugim riječima, IT specijalisti i vrhovni menadžment trebaju surañivati i uspostaviti partnerstvo kako bi projekt implementacije ERP sustava bio uspješan.

Takoñer je važno da projekt ima sponzora s visokog nivoa menadžmenta koji je u stanju sprovesti organizacijske promjene kada je to potrebno. Podrška sponzora projekta je kritična za postizanje konsenzusa i nadgledanje cijelog životnog ciklusa implementacije ERP sustava (Rosario, 2000). Netko treba biti postavljen kao 'zaštitnik' ERP projekta kroz čitavu organizaciju (Shanks et al., 2003; Sumner, 1999). Falkowski et el. (1998) navode da 'zaštitnik' projekta mora biti visoko pozicionirani sponzor koji ima moć postaviti ciljeve i opravdati promjene. Rogers (1995) takoñer napominje važnost sponzora projekta te navodi da za skupe ili radikalne projekte (uobičajene karakteristike ERP projekata), sponzor treba biti snažna individua s visokom pozicijom u hijerarhiji. Sponzor treba djelovati kao zastupnik sustava te biti nepokolebljiv u promicanju koristi novog sustava. Osim toga, vještine voñenja sponzora projekta igraju ključnu ulogu u uspjehu implementacije, jer mora stalno rješavati konflikte i upravljati otporom, kao i upravljati promjenama (Murray i Coffin, 2001). ERP implementacija obično zahtijeva dodatne sate rada od zaposlenika pored njihovih redovitih obveza. Prekovremeni rad i stres mogu smanjiti moral zaposlenika, što zahtijeva od sponzora projekta da

pojača moral projektnog tima i osigura predanost svih članova.

3.2 Poslovni plan i vizija

Budući da implementacije ERP sustava obično prekoračuju vremenski okvir tipičnog poslovnog projekta, poslovni plan i vizija su potrebni kako bi usmjeravali kontinuirani organizacijski napor. Rosario (2000) naglašava važnost posjedovanja poslovnog plana, dok Wee (2000) navodi da poslovni plan mora biti opći pregled strateških i opipljivih koristi, resursa, troškova, rizika i vremenskog okvira. Misija projekta bi trebala takoñer biti povezana s poslovnim potrebama i jasno utvrñena (Roberts i Barrar, 1992). Holland i Light (1999) ističu potrebu za jasnim poslovnim modelom o tome kako bi organizacija trebala djelovati iza implementacijskog napora, i potrebu za ciljevima i koristima koje je moguće prepoznati i mjeriti. Takvi ciljevi moraju biti jasno definirani i dobro razumljivi (Shanks et al., 2003). Postizanje navedenih ciljeva ili koristi je važno za održavanje organizacijske predanosti implementaciji ERP sustava. Trebalo bi postojati opravdanje za investiciju u ERP sustav temeljeno na promjenama u poslovnim procesima koji su usklañeni s budućim smjerom uključene organizacije (Falkowski et al., 1998). Nadalje, poduzeća težeći prema kontinuiranom poboljšanju ERP implementacije, uspostavljaju dugoročnu viziju (Ross, 1999).

3.3 Strategija implementacije

Postoje dva glavna načina implementacije ERP sustava: fazni i frontalni (engl. Big Bang) (Bradford, 2008). Fazni pristup je sporiji način uvoñenja u kojem se ERP sustav uvodi po funkcijama (modul po modul) ili geografskim područjima. Frontalni pristup (engl. Big Bang) je agresivniji način implementacije u kojem je čitavi opseg projekta adresiran odjednom kroz čitavo poduzeće.

Dodatno, implementacijska strategija širenja (engl. Roll-Out) može se kombinirati s preostalim navedenim implementacijskim strategijama povećavajući ili smanjujući funkcionalni opseg.

Izbor strategije implementacije odreñuju vrijeme i resursi odnosno ljudi i novac. Veličina i cilj će takoñer utjecati na odluku o izboru strategije implementacije. Naime, postoje i brojni drugi slučajevi koji mogu utjecati na izbor prave strategije kao što su spajanje i razdvajanje tvrtke, nove zakonske regulative, poboljšanja softverskih nedostataka tekućeg sustava, potreba za reinženjeringom poslovnih procesa te smanjenje troškova programiranja unutar tvrtke itd.

3.4 Program upravljanja promjenama

Prepoznavanje potrebe za promjenom je vrlo važno jer što je veća potreba za promjenom, vjerojatnije je da će vrhovni menadžment i dioničari podržati implementaciju ERP sustava (Falkowski et al., 1998). Strukturnim promjenama koje uključuju ljude, organizaciju i kulturne promjene, treba upravljati (Rosario, 2000). Kultura sa zajedničkim vrijednostima i snažnim identitetom poduzeća na kojoj se provode promjene je kritična. Vrlo je preporučljiva uključenost korisnika u dizajn i implementaciju novih poslovnih procesa i ERP sustava te je neophodna formalna edukacija i trening kako bi korisnici razumjeli kako će ERP sustav utjecati na njihove poslove (Holland i Light, 1999).

Otpor korisnika povezuje se s gotovo svakom promjenom sustava, čak i više s promjenom velikog informacijskog sustava poput ERP-a (Grabski et al.,


2000). Glavni otpor proizlazi iz zabrinutosti korisnika da će njihov posao biti eliminiran ili promijenjen od načina na koji su navikli raditi. Najveći izazov dolazi kada radnici koji su zbog reinženjeringa poslovnih procesa premješteni sa svojih prvotnih pozicija, zbog procesa 'tugovanja', počnu biti manje produktivni (Arnold et al., 2000). Appleton (1999) takoñer napominje kada se organizacija pomiče prema kompleksnom informacijskom sustavu (npr. ERP), vjerojatne su promjene u odnosima zaposlenika. Neki zaposlenici će trebati izgraditi nove radne odnose, nove razmjene informacija izmeñu odjela te preuzeti dodatne odgovornosti. To može voditi do otpora, konfuzije i straha. Zato su za uspješnu implementaciju potrebni menadžeri koji posjeduju komunikacijske i vještine za izgradnju tima (Appleton, 1999).

Uključenost korisnika od samog početka procesa implementacije je takoñer prepoznata kao ključna aktivnost za pridobivanje korisnika za projekt (Cameron i Meyer, 1998). Korisnici moraju imati ulogu u aktivnostima odabira projekta, odobravanja tehničkog pristupa predloženih od strane dizajnera sustava te u upravljanju i kontroli. Sukladno tome mnoga poduzeća razviju formalne planove komunikacije te izdaju redovita izvješća o statusu kako bi postigla veći nivo prihvaćanja ERP projekta. U slučaju ERP selekcije, korisnici mogu pomoći u utvrñivanju kolika je efikasnost postignuta u pružanju usluga. Ovakva participacija i uključenost korisnika je važna kako bi se osiguralo da su korisničke potrebe zadovoljene, pridobila korisnička privrženost i izbjegao otpor. Uključenost korisnika omogućuje projektnom timu svijest o korisničkim zahtjevima i adresiranje njihove zabrinutosti.

3.5 Projektni menadžment

Dobar projektni menadžment je prijeko potreban jer uspjeh u implementaciji ERP sustava se uobičajeno procjenjuje na temelju stupnja zadovoljenja planiranog vremena i budžeta. Pojedincu ili grupi ljudi treba dati ovlaštenje voñenja projekta (Rosario, 2000). Jiang et al. (1996) navode da je kompetentan voditelj projekta drugi najvažniji faktor implementacije informacijskog sustava. Nekoliko autora ističe da opseg projekta u smislu broja sustava koji se implementiraju, uključenosti poslovnih jedinica i potrebnih izmjena poslovnih procesa, treba biti jasno definiran i kontroliran (Holland i Light, 1999; Shanks et al., 2000; Rosario, 2000). Ross (1999) je takoñer napomenuo da je definiranje opsega projekta ključno za uspjeh ERP implementacije. Sve predložene promjene moraju se procijeniti naspram poslovnih koristi i ukoliko je moguće, implementirati u kasnijoj fazi. Dodatno, zahtjev za proširenje opsega mora biti procijenjen u smislu dodatnog vremena i troškova koji proizlaze iz predloženih promjena (Sumner, 1999).

Potrebno je takoñer definirati prijelomne točke projekta s jasnim i realističnim datumima isporuke. Terminski plan projekta mora biti usvojen te je potrebno upravljati eskalacijama problema i konflikata (Rosario 2000). Projektni menadžment se mora proširiti i izvan opsega i ciljeva projekta kako bi uključio i druge aspekte i pitanja projekta. Neka ključna pitanja koja se spominju u literaturi kao potencijalne zamke u implementaciji informacijskih sustava su nerealni rokovi i budžet (Boehm, 1991), odlazak ljudstva, nedostatak motivacije i truda i nedostatak sustava za mjerenje (Block, 1983). Sva ova pitanja su relevantna za implementaciju ERP ustava i mogu uzrokovati neuspjeh projekta ako se s njima ne upravlja učinkovito.

4. TAKTIČKI FAKTORI IMPLEMENTACIJE ERP SUSTAVA

Ovo poglavlje daje uvid u pet taktičkih faktora koji utječu na kratkoročne operativne ciljeve te su kritični za uspjeh ERP implementacije.

Holland i Light (1999) naglašavaju potrebu usklañivanja poslovnih procesa sa softverom tijekom implementacije. Nadalje, navode kako prirodno strategija i taktika nisu neovisne jedna o drugoj. Dok strateški faktori utječu na dugoročne ciljeve, taktički faktori su usmjereni na kratkoročne operativne ciljeve. Strategija treba voditi taktiku kao bi se potpuno integrirala tri glavna upravljačka procesa: planiranje, izvršenje i kontrola.

4.1 Projektni tim

ERP projekt uključuje sve funkcijske odjele u poduzeću. Zahtijeva kooperaciju tehničkih i poslovnih eksperata kao i krajnjih korisnika. Zbog toga su timski rad i sastav projektnog tima od strane implementatora, konzultanata i isporučitelja posebno istaknuti u literaturi. ERP tim se treba sastojati od najboljih ljudi te biti izbalansiran, sastavljen od eksternih konzultanata i internih zaposlenika, kako bi interni ljudi mogli razviti potrebne tehničke vještine za dizajn i implementaciju ERP sustava. Implementacijski tim takoñer mora biti multidisciplinarni, sastavljen od tehničkih specijalista, ključnih korisnika i operativnog osoblja, kao i od konzultanata s potrebnim vještinama i znanjem za oblikovanje i redizajn poslovnih procesa (Caldas i Wood, 2000).

Nadalje, članovi projektnog tima moraju biti ovlašteni za donošenje brzih odluka. (Shanks et. Al., 2000). Poslovno i tehničko znanje zajedno ključni su za uspjeh projekta (Bingi et al., 1999). Članovi projektnog tima moraju biti dodijeljeni projektu na puno radno vrijeme kako bi se osigurao njihov fokus na projekt i omogućio nesmetan tijek projekta. Razmjena znanja izmeñu različitih strana, osobito izmeñu implementacijskih partnera, je neophodna i zahtijeva povjerenje kojim se upravlja na redovitim sastancima. Dijeljenje rizika i nagrada pridonijeti će zajedničkom radu i postizanju ciljeva (Wee, 2000).

Često, poduzeća ne shvaćaju u potpunosti važnost odabira najboljih zaposlenika s odgovarajućim vještinama za potrebe projekta. Odgovarajući zaposlenici za projekt nisu samo oni koji posjeduju znanje o procesima u poduzeću, nego oni koji posjeduju i znanje o najboljim poslovnim procesima u industriji. Velike konzultantske kuće nude smjernice za odabir implementacijskog tima, no meñutim poduzeća ih često ne slijede u potpunosti. Ignoriranje potreba projekta i nemogućnost osiguravanja vodstva i smjernica od strane projektnog tima je glavni razlog neuspjeha ERP projekata. Lako je identificirati funkcijska područja koja se nevoljko odriču najboljih resursa za potrebe projekta. Takve poteškoće je potrebno nadvladati kako se ne bi kompromitirala uspješnost projekta (Bingi et al., 1999).

Prema anketi koju su proveli Jiang et al. (1996), projektni tim sastavljen od kompetentnih članova je jedan od najvažnijih faktora uspjeha u implementaciji informacijskog sustava. Haines i Goodhue (2000) naglasili su da interakcija izmeñu konzultanata i zaposlenika ima direktni utjecaj na uspjeh ERP implementacije.

Poduzeća učestalo traže pomoć eksternih konzultanata kada imaju probleme s visoko centraliziranim organizacijskim strukturama ili nedostatkom iskustva


(Raman et al., 1996). U visoko centraliziranim organizacijama, vrhovni menadžment često ne prepoznaje ili nije upoznat sa stvarnim operativnim procesima. Stoga konzultanti i isporučitelji informacijskih sustava djeluju kao posrednici koji brišu barijere u znanju izmeñu različitih upravljačkih nivoa u organizaciji. Konzultanti mogu pomoći u analizi potreba sustava, asistirajući poduzeću u izradi nacrta poslovnih procesa od najnižih nivoa sve do višeg menadžmenta. Oni mogu takoñer preporučiti koji hardver i softver je najprikladniji te pomoći poduzeću u implementaciji sustava.

Potreba za konzultantskom podrškom u implementaciji ERP sustava je veća nego kod drugih IT projekata, jer ERP implementacijski projekt zahtijeva širok spektar vještina i znanja poput upravljanja promjenama, upravljanja rizikom, modeliranje poslovnih procesa uz dodatna tehnička znanja. Dodatno, ERP sustav je baziran na programerskim jezicima i konceptima koji su najvjerojatnije nepoznati postojećem IT osoblju te konzultanti mogu pomoći poduzeću u svladavanju poteškoća na temelju svog dosadašnjeg iskustva i znanja. Oni mogu provoditi treninge kako bi se razvile vještine i znanja koja nedostaju u poduzeću.

Meñutim, poduzeća se ne bi trebala u potpunosti oslanjati na konzultante, budući da oni imaju ograničena znanja o operativnim aktivnostima konkretnog poduzeća. Dakle, iako konzultanti i isporučitelji posjeduju znanja o najboljim praksama u industriji, samo ljudi unutar poduzeća znaju više o njegovom operativnom poslovanju, pa menadžment mora pažljivo analizirati svaku situaciju umjesto da prihvaća svaku sugestiju konzultanata i isporučitelja softvera.

4.2 Modeliranje poslovnih procesa s minimumom prilagodbi

Modeliranje poslovnih procesa je metodologija koja omogućuje poduzećima da odrede svoje poslovne procese kao niz aktivnosti i transakcija koje zajedno ostvaruju neki poslovni cilj. Modeliranje poslovnih procesa kao pristup usmjeren je na razumijevanje temeljnih poslovnih procesa i na razvoj repozitorija poslovnih procesa gdje su poslovna pravila jedan od najvažnijih elementa za detaljne i formalizirane opise svih činjenica koje će biti implementirane tijekom razvoja informacijskog sustava.

U procesu konfiguracije ERP sustava, dogoditi će se veliki broj promjena poslovnih procesa kako bi se iskoristile mogućnosti najboljih praksa koje nudi sustav. Poduzeća moraju biti voljna prihvatiti ugrañene najbolje prakse, kad god je to moguće, i modelirati svoje poslovne procese prema istima. Wee (2000) ističe da jednom kada je sustav u upotrebi, reinženjering treba nastaviti s novim idejama i nadogradnjama kako bi se iskoristile sve mogućnosti koje nudi ERP sustav. Poduzeća bi trebala biti voljna promijeniti poslovne procese kako bi se uklopili u softver te se minimalizirao broj potrebnih prilagodbi (Shanks et al., 2000). Softver se mora minimalno prilagoñavati kako bi se smanjile mogućnosti pogreške i iskoristile prednosti novih verzija i izdanja. Murray i Coffin (2001) primijetili su da mnoga poduzeća rade nepotrebne i kompleksne prilagodbe (engl. Customizations) ERP softvera jer pojedinci koji iniciraju promjene ne razumiju u potpunosti poslovne prakse u poduzeću ili odnose izmeñu različitih poslovnih praksi. To dodatno naglašava važnost jasnog poslovnog plana i razumijevanja postojeće poslovne prakse.

Poduzeća trebaju identificirati njihovu trenutnu poslovnu strukturu i poslovne procese povezane s njihovim postojećim IT sustavom na početku ERP projekta i

povezati ih s poslovnim procesima sadržanim u ERP sustavu. Konfiguracija ERP softvera je drugačija od gradnje prilagoñenog sustava jer se razvojni fokus pomiče od analize i dizajna sustava prema konfiguraciji softvera (Holland i Light, 1999). Filozofija modeliranja poslovnih procesa zasniva se ne samo na usuglašavanju poslovnih procesa sa softverom, nego i u pojednostavnjenju poslovnih procesa eliminacijom redundantnih aktivnosti.

4.3 Nadzor i ocjenjivanje rada

Prijelomne točke i ciljevi trebaju biti aktivno nadgledani kako bi se pratio tijek i napredak ERP projekta (Murray i Coffin, 2001). Roberts i Barrar (1992) navode korištenje dva kriterija: 1 Za mjerenje troškova, datuma isporuke i kvalitete

treba koristiti kriterije na bazi projektnog menadžmenta.

2 Operativne kriterije potrebno je koristiti za mjerenje produkcijskog sustava.

Nadzor i povratne informacije uključuju razmjenu informacija izmeñu članova projekta i analizu povratnih informacija primljenih od krajnjih korisnika (Holland i Lihgt, 1999). Idealno, trebalo bi imati rani dokaz o uspješnosti kako bi se izbjegao skepticizam. Moral tima je značajna komponenta uspjeha projekta. Od članova tima traži se da provode veliki dio radnog vremena na projektu te uz stres od uobičajenih obveza vrlo brzo gube moral (Rosario, 2000). S konstantnom procjenom stanja, projekt se lako može pratiti te s dokazima o napretku projekta mogu se dodatno motivirati članovi projektnog tima.

Menadžment treba informacije o utjecaju ERP sustava na učinak poslovanja, za što je potrebno dizajnirati izvještaje. Redovita izvješća i informacije o projektu pomažu menadžmentu u praćenju napretka implementacijskog procesa.

ERP sustav je kompleksan i sadrži puno omjera i provjera. Uobičajen rizik je točnost, vidljivost i integritet podataka kroz čitav sustav. Menadžment mora razumjeti da se tijekom implementacije mogu javiti tehnički zastoji koji će poremetiti tijek projekta. Zato se veliki napori moraju usmjeriti kako bi se eliminirali veliki tehnički problemi te uspostaviti nadzor sustava, kako bi se identificirali problemi koji su se dogodili, a nisu bili vidljivi.

Cameron i Meyer (1998) navode da će imenovanje pojedinca visokog izvršnog nivoa, s velikim znanjem operativnih procesa, za voñu projekta osigurati praćenje tijeka projekta. Voditelj projekta će biti izravno odgovoran za ishod projekta. Jiang et al. (2001) ističu da je potrebna otvorena komunikacija i kooperacija izmeñu svih strana (isporučitelja, menadžmenta, korisnika i konzultanata) kako bi se nadgledao napredak projekta i omogućila procjena učinka.

4.4 Razvoj softvera, testiranje i rješavanje problema

Razvoj i testiranje softvera, specifično za ERP projekte mora biti dobro promišljeno i organizirano. Cjelovita ERP arhitektura mora biti uspostavljena prije implementacije, uzimajući u obzir najvažnije zahtjeve u implementaciji. To sprječava ponovna podešavanja u svakoj fazi implementacije (Wee, 2000). Murray i Coffin (2001) ističu da će korištenje odgovarajućih metoda modeliranja, arhitekture i alata pomoći u postizanju uspjeha ERP implementacije.


Mogu se kreirati i dokumentirati definicije sistemskih zahtjeva. Holland i Light (1999) navode da je rješavanje problema kritično za uspjeh ERP projekta. Poduzeća koja implementiraju ERP sustave moraju usko surañivati s isporučiteljima i konzultantima kako bi riješila softverske probleme.

Rigorozna i sofisticirana testiranja softvera olakšavaju implementaciju (Rosario, 2000). Softverski problemi poput grešaka (engl. Bugs) u sustavu mogu se pojaviti tijekom testiranja. Pogotovo, modificirani sustavi povećavaju mogućnost pojavljivanja grešaka. Brz odgovor, strpljenje, upornost i sposobnosti vatrogasnih akcija, važne su za rješavanje problema (Rosario, 2000). Stoga, aktivna suradnja s isporučiteljima i konzultantima je nužna kako bi se riješili i eliminirali problemi.

Integracija sa sustavima razvijenim unutar poduzeća i sa specijaliziranim softverskim produktima, koji opslužuju specifične industrijske potrebe poduzeća, zajedno s ERP sustavom je neophodna kako bi se postigla puna korisnost implementacije. Kada srednji sloj (engl. Middleware) nije dostupan, poduzeća trebaju razviti vlastita sučelja kako bi postigla takvu integraciju (Bingi et al., 1999).

4.5 Stari sustavi

Stari sustavi uključuju postojeće poslovne procese, organizacijsku strukturu, kulturu i informacijsku tehnologiju. Stoga, oni ne mogu biti kontrolirani poput ostalih faktora u modelu (Holland i Light , 1999). Neizbježno, oni odreñuju količinu potrebnih organizacijskih promjena za uspješnu implementaciju ERP sustava te odreñuju početnu točku implementacije.

Procjenom postojećih starih sustava, može se definirati priroda i opseg problema s kojima će se susresti u implementaciji. Na primjer, ako su stari sustavi ekstremno kompleksni, s različitim tehnološkim platformama i mnoštvom procedura za upravljanje poslovnim procesima, onda će količina tehničkih i organizacijskih promjena biti velika. Ako poduzeće već ima zajedničke poslovne procese i jednostavnu tehničku arhitekturu, promjene su male. Stari sustavi nisu odvojeni problem, budući da njihov dizajn i operacije vežu mnoge komponente poslovanja, poput tijeka rada i procesa.

Rogers (1995) navodi generalno da je složenost inovacije negativno povezana s brzinom prihvaćanja iste. Kako bi bila uspješna, implementacija ERP sustava mora prevladati pitanja složenosti koja proizlaze iz starih IT i poslovnih sustava.

Prema Roberts i Barrar (1992) nužno je stabilno i uspješno poslovanje, kao i uspjeh u drugim poslovnim područjima za uspješnu ERP implementaciju. Oni navode kako stabilno i uspješno poslovanje vodi k većoj vjerojatnosti jakog organizacijskog identiteta te je otvorenije za promjene koje omogućuju uspješnu ERP implementaciju.

5. ZAKLJU ČAK

Uspješna implementacija ERP sustava obuhvaća mnogo različitih zadataka. Vrlo je teško usredotočiti se podjednako na sve faktore koji utječu na implementaciju ERP sustava. Kako prepoznati važnost pojedinih faktora i njihov utjecaj te kako alocirati ograničene resurse na kritične faktore temeljni je fokus ovog rada.

U radu je prikazano deset kritičnih faktora uspjeha te su klasificirani kao taktički i strateški faktori uspjeha implementacije ERP sustava. Strateški faktori utječu na

dugoročne ciljeve, dok su taktički faktori usmjereni na kratkoročne ciljeve.

Projekt uvoñenja ERP sustava mora imati snažnu podršku vrhovnog menadžmenta. Menadžment mora sudjelovati u projektu i biti spreman dodijeliti resurse za implementacijski projekt. Vrlo je važno da projekt implementacije ERP sustava ima jasno definiran poslovni plan i viziju. Poslovni plan mora sadržavati pregled strateških i specifičnih koristi, troškova, resursa i vremenskog okvira, dok vizija mora biti povezana s poslovnim potrebama i takoñer jasno utvrñena. Primjenom odgovarajuće strategije smanjuju se rizici implementacije jer strategije kao i metodologije predstavljaju dugogodišnje iskustvo svih onih koji su sudjelovali u radu na projektu implementacije ERP sustava. Potrebno je upravljati strukturnim promjenama koji uključuju ljude, organizaciju i kulturne promjene. Vrlo je važno uključiti korisnike u dizajn i implementaciju novih poslovnih procesa te je neophodna edukacija i trening kako bi korisnici mogli prepoznati kako će ERP sustavi utjecati na njihove poslove. Dobar projektni menadžment je prijeko potreban jer uspjeh u implementaciji ERP sustava se uobičajeno procjenjuje na temelju ostvarenja planiranog vremena i budžeta. Projekt treba biti voñen, a opseg projekta jasno definiran i kontroliran.

Projektni tim je jedan od ključnih taktičkih faktora u implementaciji ERP sustava. Budući da ERP pokriva širok spektar funkcionalnosti, važno je imati tim sastavljen od stručnjaka iz više funkcionalnih područja. Takoñer je važno i povjerenje izmeñu članova tima. U procesu implementacije i konfiguracije ERP sustava, dogoditi će se veliki broj promjena poslovnih procesa kako bi se iskoristile mogućnosti najboljih praksa koje nudi sustav. Poduzeća moraju biti voljna prihvatiti ugrañene najbolje prakse, kad god je to moguće, i modelirati svoje poslovne procese prema istima. Bitno je naglasiti da se metodologija rada mora obavljati po jasno strukturiranim koracima s prijelomnim točkama te se mora osigurati čvrsti i konstantni nadzor nad projektom. Cijeli proces mora biti popraćen detaljnom dokumentacijom što, iako zahtjeva dodatan rad, kasnije osigurava jednostavnije održavanje sustava i druge akcije nakon implementacije rješenja. Detaljna dokumentacija, takoñer tijekom implementacije osigurava lakše praćenje pojedinih aktivnosti i olakšava snalaženje i komunikaciju pojedinih članova tima u timskom radu. Razvoj i testiranje softvera mora biti dobro organizirano i provedeno. Brzi odaziv, strpljenje i ustrajnost u rješavanju problema vrlo su važni za uspješno odvijanje projekta. Stari sustavi (engl. Legacy) uključuju postojeće poslovne procese, organizacijsku kulturu i informacijsku tehnologiju poduzeća te odreñuju početnu točku implementacije. Neizbježno, oni odreñuju količinu potrebnih organizacijskih promjena za uspješnu implementaciju ERP sustava.

Kultura je uključena u strateške i taktičke faktore koji direktno ili indirektno utječu na implementacijski proces ERP sustava. Kada dva poduzeća implementiraju potpuno iste ERP sustave, ponekad je ishod sasvim različit. Usvojena korporativna kultura predstavlja faktor koji se ne može zanemariti u smislu uspješnosti ERP implementacije.

Kraj projekta implementacije ERP sustava bi trebao rezultirati zadovoljnim klijentom, čiji poslovni procesi su kvalitetno podržani i koji je ostvario unaprjeñenje u svome poslovanju, a s druge strane i zadovoljnim isporučiteljom koji dobiva još jednu referencu i vrlo vjerojatan nastavak suradnje s postojećim i stjecanje


novih korisnika. Iako svaki projekt ima svoj cilj i samim time završetak, uspješne ERP implementacije ne završavaju datumom početka rada s novim sustavom već upravo tada bi trebalo započeti sa stalnim procesom optimizacije, usavršavanja i održavanja sustava kako bi

se postigla što bolja prilagoñenost promjenjivim potrebama poduzeća. Ne smije se zaboraviti da cilj projekta nije instalacija ERP sustava već postizanje odreñenih poslovnih ciljeva, a ERP sustav je samo alat u službi tog cilja.

Literatura:

1 Aberdeen Group (2006). The total Cost Of ERP Ownership [online]. Dostupno na: www.oracle.com/corporate/analyst/reports/corporate/cp/es101306.pdf [16. Travnja 2010.]

2 Al-Mashari, M. et al (2003). Enterprise resource planning: A taxonomy of critical factors. European Journal of Operational Research, 146 (2), str. 352-364.

3 Appleton, E. (1999). How to survive ERP. Datamation, March..

4 Arnold, V. et al (2000). On the Death and Dying of Originality in the Workplace: A Critical View of Enterprise Resource Planing Systems’ Impact on Workers and the Work Environment. Working Paper, University of South Florida.

5 Axline, S. et al (2001). Learning from experiences with ERP: problems encountered and success achieved. U: Shanks G., Seddon P. B., i Willcocks L. P. , Second-wave enterprise resource planning systems . Edinburgh: Cambridge University Press, str. 23-54.

6 Benjamin, R. I., i Levinson, E. (1993). A framework for managing IT enabled change. Sloan Management Review, 34 (4), str. 23-33.

7 Bingi, P. et al(1999). Critical issues affecting an ERP implementation, Information Systems Management, str. 7-14.

8 Block, R. (1983). The politics of projects. Englewood Cliffs, NJ: Yourdon.

9 Boehm, B. W. (1991). Software risk management: Principles and practices. IEEE Software, 8, str. 32–41.

10 Bradford M. (2008). Modern ERP: Select, Implement & Use Today's Advanced Business Systems. North Carolina: North Carolina State University.

11 Caldas, M. P. i Wood, T. (2000). Stripping the big brother: snooping into the Enterprise Systems (ERP) Fad. Paper presented at the 18th SCOS - Standing Conference on Organizational Symbolism, Athens.

12 Cameron, D., i Meyer, L. (1998). Rapid ERP implementation-a contradiction. Management Accounting , 80 (6), str. 56-60.

13 Coulianos, N. et al (2000). Implementing Enterprise Resource Planning packages in different corporate and national cultures. Journal of Information Technology, (15), str. 267-279.

14 De Lone, W. H., i McLean, E. R. (1992). Information systems success: the quest for the dependent variable. Information Systems Research, 3(1), str. 60-95.

15 Esteves-Souza, J., i Pastor-Collado, J.A. (2000). Towards the unification of critical success factors for erp implementations [online]. Dostupno na: http://www.army.mil/escc/docs/bit2000.pdf [ 20 Travnja 2010.]

16 Falkowski, et al (1998). A recipe for ERP success. Beyond Computing, str. 44-5.

17 Gargeya, V.B. i Brady, C. (2005). Success and failure factors of adopting SAP in ERP system implementation. Business Process Management Journal, 11 (5), str. 501-516.

18 Grabski, S. V. et al (2000). Successful implementation of ERP systems: risks and complementary Factors. Working Paper, Eli Broad College of Business, Michigan State University, East Lansing.

19 Haines, M. N. i Goodhue, D. L. (2000). ERP implementations: The role of implementation partners and knowledge transfer. Proceedings of the Information Resources Management Association (IRMA) International Conference, Anchorage, str. 34–38.

20 Harris, T. E. (2002). Applied organizational communication. Lawrence Erlbaum Associates, Inc.

21 Holland C. P. &Light B. (1999). A Critical Success Factors Model For ERP Implementation. Focus [online]. Dostupno na: http://www.imamu.edu.sa/Scientific_selections/abstracts/Documents/A%20Critical%20Success%20Factors%20 Model%20For%20ERP%20Implementation.pdf [21. ožujka 2010.]

22 Hong, K-K., i Kim, Y-G. (2002). The critical success factors for ERP implementation: an organizational fit perspective. Information& Management, (40), str. 25-40.

23 Hossain, L., i Shakir, M. (2001). SIF for understanding the ERP selection in New Zealand. Journal of Decission Systems-Special Issue on ERP and their Impact on Decission Making. Paris: HEREMES Science Publications.

24 Jiang, J. J. et al (1996). Ranking of system implementation success factors. Project Management Journal, 27, str. 49–53.

25 Kovačič, A. i Bosilj Vukšić, V. (2005). Management poslovnih procesov: Prenova in informatizacija poslovanja s praktičnimi primeri, Ljubljana: GV založba.

26 Kuang, J. et al (2001). Critical factors for successful implementation of enterprise systems. Business Process Management Journal, 7 (3), str. 285.

27 Larsen, M. A., i Myers, M. D. (1997). BPR success or failure? A business process reengineering model in financial services industry. Proceeding of the International Conference of Information Systems. Atlanta, GA, str. 367-382.


28 Laudon, J., i Laudon, K. (1998). Management information systems: new approaches to organization and technology. New York: Macmillan PublishingCo. Ltd.

29 Magnusson, J. et al (2004). Forecasting erp implementation success – towards a grounded framework [online]. Dostupno na: http://is2.lse.ac.uk/asp/aspecis/20040100.pdf [23. Ožujka 2010.]

30 Markus, M. L., i Tanis, C. (2000). The enterprise systems experience-from adoption to success. In framin the domains of IT research: glimpsing the future through the past, Cincinnati: Pinnaflex Educational Resources.

31 Mendel, B. (1991). Overcoming ERP project hurdles. InfoWorld, (21), str. 29.

32 Murray, M., & Coffin, G. (2001). A case study analysis of factors for success in ERP system implementations. Proceedings of the Seventh Americas Conference on Information Systems, Boston.

33 Musaji Y. F. (2002). Integrated Auditing of ERP Systems. New York: John Wiley & Sons, Inc.

34 Pinto, J. K. i Slevin, D. P. (1987). Balancing strategy and tactics in project implementation. Sloan Management Review, 29 ( 1), str. 33-41.

35 Raman, K. S. et al (1996). Top management support, external expertise and information systems implementation in small business. Information Systems Research, 7( 2), str. 248-267.

36 Roberts, H.J. i Barrar, P.R.N. (1992). MRPII implementation: key factors for success. Computer IntegratedManufacturing Systems, 5 (1), str. 31-8.

37 Rockhart, J. (1982). The changing role of information systems executive: A critical success factors perspective. Sloan Management Review, (4), str. 1-24.

38 Rockhart, J. i Scott, M.(1984). Implications of changes in information technology for corporate strategy. Interfaces, 14 (1), str. 84-95.

39 Rogers, E. M. (1995). Diffusion of innovations.New York: The Free Press.

40 Rosario, J. G. (2000). On the leading edge: critical success factors in ERP implementation projects. Business World.

41 Ross, J. (1996). Dow Corning Corporation: Business processes and information technology. Center for Information Systems Research, Sloan School of Management, MIT.

42 Sarkis, J., Sundarraj, R.P. (2003) Managing large-scale global enterprise resource planning systems: a case study at Texas Instruments. International Journal of Information Management, 23 (5), str. 431-442.

43 Schein, E. H. (1992). Organizational culture and leadership. San Francisco: Jossey-Bass Publishers.

44 Seddon, P. B. et al (2003). Second-wave enterprise resource planning systems. New York: Cambridge University.

45 Seddon, P. B., i Shang, S. (2002). Assessing and managing the benefits of enterprise systems: the business manager’s perspective. Information Systems Journal, 5 ( 12) str. 271-299.

46 Shanks G. et al (2003). Second-Wave Enterprise Resource Planning Systems: Implementing for Effectiveness. Cambridge: Cambridge University Press.

47 Shanks, G. et al (2000). Differences in critical success factors in ERP systems implementation in Australia and China: Acultural analysis. Proceedings of the 8th European Conference on Information Systems, Vienna, Austria, str. 37–544.

48 Somers, T.M. i Nelson, K.G. (2004). A taxonomy of players and activities across the ERP project life cycle. Information & Management, 41 (3), str. 257–278.

49 Sternad, S. et al (2007). Model kritičnih dejavnikov uspeha uvajanja rešitev SAP in Navision. Naše Gospodarstvo, 53 (1/2,) str. 37-47.

50 Sumner,M. (1999). Critical success factors in enterprise wide information management systems projects. Proceedings of the Americas Conference on Information Systems, Milwaukee, str. 232–234.

51 Taube, L.R., Gargeya, V.B. (2005). An Analysis of ERP System Implementions: A Methodology, The Business Review, Cambridge; 4 (1), str. 1-6.

52 Trompenaars, F. (1994). Riding the waves of culture: understanding cultural diversity in business, London: Nicholas Brealey Publishing.

53 Umble, E.J. et al (2003). Enterprise resource planning: Implementation procedures and critical success factors. European Journal of Operational Research, 146 (2), str. 241–257.

54 Umble, E.J., Umble, M.M. (2002). Avoiding ERP implementation failure. Industrial Management, 44 (1), str. 25-33.

55 Wee, S. (2000). Juggling toward ERP success: keep key success factors high [online]. Dostupno na: http://www.erpnews.com/erpnews/erp904/02get.html. [25. Travnja 2010.]

56 Zhang, L., et al (2003). Critical Success Factors of Enterprise Resource Planning Systems Implementation Success in China [online]. Dostupno na : http://www.computer.org/portal/web/csdl/doi/10.1109/HICSS.2003.1174613


Podaci o autorima:

Damir Stepani ć Aplication Senior Sales consultant Oracle Hrvatska Budmanijeva 1 10000 Zagreb e-mail: [email protected] Damir Stepanić je 2002. godine diplomirao na Ekonomskom fakultetu u Zagrebu. Na istom fakultetu 2011. godine završava poslijediplomski specijalistički studij, smjer poslovno upravljanje – MBA. U Oracle Hrvatska obavlja funkciju Applications Senior Sales Consultanta te djeluje kao podrška prodajnom timu i menadžmentu u konstrukciji prodajne strategije Oracle Aplikacija. Takoñer provodi aktivnosti kao što su priprema i isporuka sadržaja za konferencije i seminare, edukacija korisnika i partnera o novim proizvodima i funkcionalnostima te preuzima ulogu u product management zadacima poput analize i razvoja lokalizacije i testiranja novih proizvoda. Kao konzultant i projektant takoñer je radio na mnogim projektima implementacije poslovnih informacijskih sustava u javnom i financijskom sektoru. Damir Stepanić graduated at the Faculty of Economics and Business in Zagreb. He also holds an MBA in business. He is Application Senior Sales Consultant in Oracle and acting as a support to sales and management team in the construction of sales strategy. He is also preparing and delivering content in marketing activities, such as conferences, seminars, white papers, articles, educating customers and partner organizations in Oracle Applications and value propositions in the designated products, and taking role in product management related tasks like, localizations analysis and development.

Prof.dr.sc. Katarina Ćurko Ekonomski fakultet u Zagrebu Tel +385-1-2383282 Fax +385-1-2335633 e-mail: [email protected] Katarina Ćurko je profesor na Ekonomskom fakultetu u Zagrebu na Katedri za informatiku. Predaje na diplomskom i poslijediplomskom studiju. Na diplomskom studiju predaje kolegije Informatiku, Upravljanje podacima i Poslovne informacijske sustave, a na poslijediplomskom studiju predaje kolegij Sustavi za upravljanje podacima. Godine 1997. doktorirala je na Ekonomskom fakultetu u Zagrebu. Njeno područje istraživanja uključuje: skladištenje podataka, analitičke obrade, poslovnu inteligenciju, modeliranje podataka, sustave upravljanja znanjem, razvoj i implementacija poslovnih informacijskih sustava.


PRIMJENA INTELIGENTNOG INTEGRALNOG INFORMACIJSKOG S USTAVA ZA OPTIMIZACIJU PROIZVODNOG PROGRAMA

INTELLIGENT INTEGRAL INFORMATION SYSTEM USE FOR PRODUCTION PROGRAM OPTIMIZATION

prof. dr. Kova č Dragan

SAŽETAK:

U radu se prikazuje rješavanje problema optimizacije proizvodnog programa u okviru integralnog sustava za upravljanje poslovanjem, koji:

� pokriva brojne poslovne funkcije (upravljanje proizvodnjom, projektima, održavanjem, prodaju, nabavu, trgovinu, financije, place, ljudske resurse itd

� ima ugrañenu internu inteligenciju, tj. mogućnost rješavanja kompleksnih problema kao linearno programiranje, mrežno planiranje, stohastičke simulacije itd

� ugrañenu sposobnost da prihvati eksternu inteligenciju, tj. znanje iz okoline – slobodno zadate formule za različite kalkulacije, slobodno zadate financijske modele itd.

Iznosi se konkretan primjer, sa prikazom postupka rješavanja problema, iz koga je vidljivo da su u toku cijelog postupka tijesno isprepleteni interna inteligencija IS, podsustavi koji podržavaju različite poslovne funkcije i angažman stručnjaka za različite oblasti poslovanja u analizama i procjenama.

Sadržaj izlaganja je slijedeći: � Uvod � Kratak opis Podsustava za optimizaciju proizvodnje � Izbor reprezentanata proizvodnog programa � Izračun koeficijenata za funkciju kriterija � Utvrñivanje koeficijenata za ograničenja kapaciteta � Definiranje ograničenja proizvodnih kapaciteta � Postavljanje 1-ve varijante modela optimizacije � Izračun optimalnog programa za 1-vu varijantu � Plan kapaciteta za 1-vu varijantu � Analiza rezultata za 1-vu varijantu � Postavljanje 2-ge varijante modela optimizacije � Izračun optimalnog programa za 2-gu varijantu � Plan kapaciteta za 2-gu varijantu � Analiza 2-ge varijante � Rezultati i zaključci � Rezime postupka.

RESUME:

Solving production program optimization by use of an intelligent integral IS, that: � covers various business functions (production management, project management, finance, purchasing, sales,

payroll, human relations etc.) � has built in internal intelligence, i.e. advanced capabilities like linear programming, network planning, stochastic

simulations etc. � has built in capability to accept external intelligence, e.g. user defined formulas for various calculations, user

defined financial models etc ... � ... and all that is intertwined with standard business procedures.

The paper is presented using an actual example, as follows: � Choice of product representatives � Computing coefficients for Function of criteria � Production capacities coefficients defined � Production capacities limits estimation � Determine 1-st variant of optimization model � Compute optimal program for 1-st variant � Make production capacities plan for 1-st variant � Determine 2-nd variant of optimization model � Compute optimal program for 2-nd variant � Make production capacities plan for 2-nd variant � Analysis of 2-nd variant � Results and conclusions. � Resume of actions.


1. UVOD

U radu se prikazuje postupak optimizacije proizvodnog programa tvornice (za izradu namještaja), u okviru integralnog informacijskog sustava za upravljanje poslovanjem, koji tvornica svakodnevno koristi u svom poslovanju.

Software, koji se za ovo koristio je SUPER (Sustav Upravljanja Poslovanjem Elektroničkim Računalom) firme SUPER-KING d.o.o., Zagreb.

SUPER integralno podržava brojne poslovne funkcije (upravljanje proizvodnjom, izgradnjom kompleksnih objekata, održavanje postrojenja i objekata, maloprodaju i veleprodaju, financije, osnovna sredstva, plan i analizu, obračun plaća, ljudske resurse itd), te sadrži i komponente koje nazivamo interna i eksterna inteligencija informacijskog sustava.

Interna inteligencija ovdje se definira kao sposobnost informacijskog sustava da rješava probleme, uz korištenje kompleksnih algoritama, kao što su linearno programiranje, mrežno planiranje, stohastičke simulacije, koncept grupne tehnologije i konstrukcije, terminiranje proizvodnje itd

Eksterna inteligencija ovdje se definira kao sposobnost informacijskog sustava da prihvata znanje iz okoline – ekspertna, korisnička, iz literature itd.

Koncept Eksterne inteligencije, tj. sposobnosti SUPER-a da prihvata znanje iz okoline u raznim oblicima (kalkulacije prema slobodno zadatim, ad hoc formulama, slobodno financijsko modeliranje, upravljanje „event driven“ aktivnostima itd) primjenjuje se u više podsustava SUPER-a, u raznim situacijama i velikom broju opcija.

Sve sto je u svezi (interne i eksterne) inteligencije, integralni je dio SUPER software, kako u pogledu software (menu-a, izvrsnog koda itd), tako i u dijelu baze podataka.

Za dobro projektirane informacijske sustave, inteligencija informacijskog sustava je: � Neodvojiva je osobina svakog, pa i najmanjeg

elementa IS, jako isprepletena sa svakodnevnim funkcioniranjem IS

� Direktno proporcionalna: � inteligenciji i znanju projektanta i razvojnog tima

informacijskog sustava, ... � ... te resursima koji su uloženi u projektiranje i

razvoj IS. Pri tome, za korištenje inteligencije IS, uvjet bez koga se ne može su agilni korisnici, istinski zainteresirani za poboljšanje rada organizacije.

Lošije rješenje za realizaciju inteligentnih IS, ali mogu će - IS projektiran i razvijen sa neadekvatnom inteligencijom, može se, u nekoj mjeri, popraviti dodatnim software, koji bi dopunio inteligenciju IS. Meñutim, ne može se nadomjestiti surogatima tipa Data Mining, Data Warehousing, OLAP itd – potreban je potpuno drugačiji pristup, ali o tome u nekom drugom radu.

Kao ilustracija, gore opisanog, poželjnog pristupa projektiranju inteligentnih integralnih IS, u ovom radu se iznosi konkretan slučaj optimizacije proizvodnje, sa prikazom: � toka rješavanja problema, � korištenih komponenti informacijskog sustava, � te timskog učešća stručnjaka za pojedine poslovne

oblasti.

S tim u svezi, u daljem tekstu se prikazuje: � Kratak opis Podsustava za optimizaciju u SUPER

software � Izbor reprezentanata proizvodnog programa � Izračun koeficijenata za funkciju kriterija � Definiranje ograničenja proizvodnih kapaciteta

� Izračun optimalnog programa za 1-vu varijantu � Plan kapaciteta za 1-vu varijantu � Stvarno iskorištenje kapaciteta u tvornici � Analiza rezultata za 1-vu varijantu

� 2-ga varijanta modela optimizacije � Izračun optimalnog programa za 2-gu varijantu � Plan kapaciteta za 2-gu varijantu � Analiza 2-ge varijante i zaključci � Rezultati i zaključci.

2. KRATAK OPIS PODSUSTAVA ZA OPTIMIZACIJU U SUPER-U

Podsustav (Sl. 1) se temelji na poznatoj Simplex metodi linearnog programiranja, sa svrhom:

Slika 1.: SUPER - Podsustav za optimizaciju proizvodnje


� Izračunavanje minimuma ili maksimuma zadane funkcije kriterija, za zadana ograničenja.

� Analiza osjetljivosti, tj. utjecaja raznih hipotetičkih varijacija ograničenja i koeficijenata funkcije kriterija na vrijednost max ili min funkcije kriterija i stupanj iskorištenja ograničenja.

U slučaju koji se ovdje opisuje, podsustav se koristi za odreñivanje optimalnog programa proizvodnje, tj. takvog koji donosi najveću dobit, najveće iskorištenje kapaciteta i sl. Ovo je korisno utvrditi u svakom tipu proizvodnje, a najčešće se koristi u procesnoj industriji (prerada nafte, kemijska industrija itd) i poljoprivredi.

Optimizacija se izvodi, na slijedeći način: � Korisnik prvo utvrdi listu reprezentativnih, tj. svih

tipičnih proizvoda. Dakle, u model za optimizaciju ne unose se svi proizvodi (iako je i to moguće). Razlog za ovo je, što obično postoji mnogo varijacija sličnih proizvoda i nepotrebno je sve ove varijacije unositi u model.

Zatim treba utvrditi: � listu svih proizvodnih radnih mjesta, koja učestvuju u

proizvodnji reprezentativnih proizvoda � raspoložive kapacitete proizvodnih mjesta, u periodu

za koji se želi odrediti optimalni program, u ovom slučaju za 1 godinu.

Za jedinicu količine svakog reprezentativnog proizvoda treba utvrditi: � doprinos tzv. funkciji kriterija (u ovom slučaju

dobit/jed. mjere proizvoda) ... � ... te koliko troši kapaciteta pojedinih radnih mjesta,

Matematički model optimizacije proizvodnog programa je slijedeći: Funkcija kriterija: X1x D1 + X2xD2 + ...... + Xn x Dn � max Ograni čenja proizvodnih kapaciteta: X1 x T11 + X2 x T12 + X3 x T13 + ....... + Xn x T1m < K1 X1 x T21 + X2 x T22 + X3 x T23 +....... + Xn x T2m < K2 .......................................................................................... .......................................................................................... X1 x T1n + X2 x T2n + X3 x T3n ....... + Xn x Tnm < Km Pri tome je:

Xi – optimalna količina i-tog reprezentanta u proizvodnom programu

Di – dobit po jedinici i-tog reprezentanta n – broj reprezentativnih proizvoda Tij – vrijeme obrade i-tog proizvoda na j-om radnom

mjestu Ki – godišnji kapacitet i-tog radnog mjesta (radnih sati) m - broj relevantnih radnih mjesta .

Mogu se zadati i različita druge vrste ograničenja, npr.: � kolika je maksimalno moguća ... � ... i/ili minimalno obvezatna količina

svakog proizvoda, � odnosi izmeñu količina nekih

proizvoda itd.

Na osnovu gore navedenih podataka, SUPER utvrñuje: � optimalni program , tj. koje

proizvode i u kojoj količini treba proizvoditi da bi se ostvario najbolji rezultat (max ili min funkcije kriterija)

� koji proizvodi ne doprinose ili slabo doprinose funkciji kriterija, te ih treba izbaciti iz proizvodnog programa.

� uska grla u proizvodnji , tj. koja radna mjesta su ograničenja za ostvarenje veće proizvodnje

� viškove proizvodnih kapaciteta .

3. IZBOR REPREZENTANATA PROIZVODNOG PROGRAMA

Proizvodni program poduzeća, za koje se optimizacija radila, sadrži preko 2.000 različitih proizvoda. Odjel za razvoj proizvoda dobio je zadatak da odredi reprezentante proizvodnog programa – svaki reprezentant je tipičan proizvod, tehnološki sličan većem broju drugih proizvoda, dakle predstavnik grupe proizvoda.

Za ovo, Odjel razvoja poslužio se postojećim klasifikacijskim sustavom, te podsustavom SUPER-a za Grupnu tehnologiju i konstrukciju, temeljnog koncepta za realizaciju tzv. CIM koncepta (Computer Integrated Manufacturing), odn. računalom integrirane proizvodnje.

S tim u svezi, SUPER nudi slijedeće mogućnost analize tehnoloških procesa, kojom se na osnovu normativa izrade proizvoda utvrñuje: � grupe tehnološki sličnih proizvoda, tj. proizvoda koji

se obrañuju na istom ili sličnom skupu radnih mjesta,

� grupe strojeva, odnosno radnih mjesta koje su tehnološki povezane u proizvodnji tehnološki sličnih proizvoda,

� koji proizvodi se obrañuju po stvarnim ili hipotetičkim grupama.

Ovaj podsustav SUPER-a omogućuju izradu standardnih, tipskih tehnologija za odreñene vrste proizvoda, izradu boljih i ekonomičnijih alata, optimalno grupiranje radnih mjesta u proizvodnji, tj. formiranje proizvodnih odjela, optimizaciju unutarnjeg transporta itd.

Na osnovu ovog podsustava, Odjel razvoja odredio je 13 proizvoda kao reprezentante kompletne proizvodnje.

4. IZRAČUN KOEFICIJENATA ZA FUNKCIJU KRITERIJA

Standardni pristup za izračun doprinosa funkciji kriterija, koji se obično navodi u literaturi - razlika izmeñu prodajne cijene i direktnih troškova proizvodnje – ocijenjen je kao neadekvatan, te je primijenjena formula, po kojoj konkretna tvornica redovno analizira profitabilnost po proizvodima, kupcima, klasama itd.

Za ovo je korišten Podsustav za nabavu i prodaju SUPER software, u kome se, kao i u drugim dijelovima SUPER-a, koristi naš koncept Eksterne inteligencije. U ovom slučaju, izračun koeficijenata za funkciju kriterija vrši se na osnovu tzv strukturne i izvrsnih formula koje zadaje korisnik, kao sto slijedi:

Strukturna formula za izračun dobiti za reprezentativne proizvode: MAR: fak,SNI,CZA,PRE,BON,ZR,PRO,UK,

Elem. cijene Izvrsna formula Opis

fak "fak= standardna fakturna cijena

SNI $fak= sniženje na fakt. cijenu CZA !CZA= cijena zaliha PRE >ZAPRM*23,51= troškovi prijevoza BON fak*<BONUS/100= bonus kupcu ZR fak*<ZREG/100= dodatni bonus PRO 0,049*(fak+SNI-BON+ZR)= provizija prodavatelju UK fak+SNI-(CZA+PRE+BON+PRO)= dobitak po jmj

proizvoda


Ovakve formule korisnik potpuno slobodno oblikuje, u SUPER se unose po odreñenim pravilima, a onda se kalkulacija izvodi bez dodatnog programiranja, na slijedeći način: � SUPER prvo kontrolira sintaksu strukturne formule,

u kojoj su navedeni svi elementi kalkulacije ... � ... a zatim svaki element izračunava po izvršnoj

formuli za taj element, prema sintaksi koju zahtjeva SUPER, a prema kojoj SUPER u bazi podataka nalazi odgovarajuće vrijednosti i obavlja računanja.

Ovako izračunata dobit/jmj, za svaki reprezentativni proizvod, omogućuje formiranje funkcije kriterija u modelu za optimizaciju proizvodnog programa (Sl. 2).

Iz Sl. 2 vidljivo je da 13-ti reprezentant neće ući u optimalni program, jer je dobit za ovaj proizvod negativna. Pa ipak, ovaj reprezentant ostaje dio modela, radi kasnijih varijanti i analiza.

5. ODREðIVANJE KOEFICIJENATA ZA OGRANIČENJA PROIZVODNIH KAPACITETA

Izvršeno je tako, da je Odjel razvoja proizvoda, iz normativa rada za reprezentativne proizvode, u podsustavu Strukturne veze, odredio vrijeme obrade svakog od reprezentativnih proizvoda, na svakom od relevantnih radnih mjesta, uzevši te podatke iz rekapitulacije normativa rada za kompletne sastavnice reprezentativnih proizvoda.

6. DEFINIRANJE OGRANIČENJA PROIZVODNIH KAPACITETA

S tim u svezi, Odjel za razvoj proizvoda i Tehnička priprema proizvodnje uradili su slijedeće: � Utvrdili 79 relevantnih proizvodnih radnih

mjesta, a ostale zanemarili, jer relativno malo učestvuju u proizvodnji.

� Zatim, za relevantna radna mjesta, iz registra radnih mjesta u bazi podataka, za svako r. mjesto utvrdili su:

� broj jedinica svakog pojedinog radnog mjesta i ...

� ... koeficijent izvršenja norme. � ... te u koliko smjena rade.

� Na osnovu ovih podataka, te broja radnih dana u godini (bez vikenda, praznika i godišnjeg odmora), za svako radno mjesto izračunat je raspoloživi kapacitet (norma sati) za godinu dana.

Ovako izračunati raspoloživi kapacitet za 79 radnih mjesta, predstavlja 79 ograničenja kapaciteta u modelu za optimizaciju proizvodnog programa. Na taj način, kompletirana je 1-va varijanta modela za optimizaciju proizvodnog programa (funkcija kriterija i ograničenja).

6.1 Izračun 1-ve varijante optimalnog programa

1-va varijanta modela optimizacije obrañena je u podsustavu za Optimizacija proizvodnje i dobiveni su slijedeći rezultati (Sl. 3).

Orga. : 2 XXXXXXXXXXXXXXXXXXXXXXXX ABC ANALIZA VRIJEDNOSTI DOBITI ZA PERIOD : 01.01.10 - 31.12.10 =================================================== ======================================= Šifra N A Z I V Jmj Dobit/jmj Kum vrijed. Kum % --------------------------------------------------- --------------------------------------- 1. 10862 Tisch Multi XL Kernbuche lac 160x90+3x50 St k 61,78 138.082,81 21,03 2. 6543 Stuhl Leon Buche nat. PU Sun braun St k 9,00 261.785,28 39,88 3. 9136 Stuhl Rudi Buche nat.Elek.003 beige St k 4,63 385.053,76 58,66 4. 14415 Stuhl Tommy Buche nat.Elek.003 beige St k 12,44 457.155,89 69,64 5. 17067 Stuhl Chris Eiche nat. Elek. 370 d.braun St k 4,49 515.118,24 78,47 6. 3355 Stuhl Two Buche kolonial Puerto 935 St k 5,99 559.708,92 85,26 7. 2367 Sessel Omega Elek. 901 schwarz n/schw St k 7,91 603.271,14 91,90 8. 11983 Stuhl Santos Buche nat. Elek. 370 d.bra. St k 18,24 640.131,36 97,51 9. 17642 Tisch T66 Kernbuche lac 160x90+2x40 cm St k 22,39 669.217,09 101,94 10. 21980 Stuhl Ivonne Buche nat.Galant beige 794 St k 0,72 686.351,71 104,55 11. 17632 Tisch T6 Kernbuche lac 160x90 cm St k 13,12 702.040,29 106,94 12. 9195 Tisch Turin XL Boot.Kern-lac 160x90+2x50 ko m 110,21 712.731,04 108,57 13. 5873 Tisch Emanuela XL Buche nat.125x80+40cm St k -17,55 656.453,01 100,00

Slika 2: Dobit/jmj - Koeficijenti za funkciju kriterija

REZULTATI OPTIMIZACIJE MODELA: VARIJANTA 1 BROJ OGRANIČENJA : 79 BROJ PROMJENLJIVIH : 13 MAKSIMUM FUNKCIJE : 5,916.488.20 OPTIMALNI PROGRAM ---------------------------------------------- RBr. Opis promjenjive Vrijednost promjenjive ---- ----------------------------------------- 1. 10862 Tisch Multi XL 421 2. 6543 Stuhl Leon Buch 9.623 3. 9136 Stuhl Rudi Buch 24.293 4. 14415 Stuhl Tommy Bu 172.660 5. 17067 Stuhl Chris Ei 0 6. 3355 Stuhl Two Buche 0 7. 2367 Sessel Omega El 26.028 8. 11983 Stuhl Santos B 54.144 9. 17642 Tisch T66 Kern 18.082 10. 21980 Stuhl Ivonne B 0 11. 17632 Tisch T6 Kernb 0 12. 9195 Tisch Turin XL 17.649 13. 5873 Tisch Emanuela 0

STANJE OGRANIČENJA ----------------------------------------------------------------------------------------------- (1) (2) (2)/(1) RBr. Opis ogranič. Postavljeno ogranič. Postignuto ogranič. % Sve ----------------------------------------------------------------------------------------------- 1. 24-1 G.R. Krojenje 451200.00 451200.00 100.00 + 2. 24-2 P.R. Krojenje p 225600.00 73430.23 32.55 3. 24-5 G.R. Šivanje 3609600.00 3552446.25 98.42 4. 11-1 G.R. Sklapanje 902400.00 299323.78 33.17 5. 11-3 G.R. Montaža 3384000.00 1181258.50 34.91 ........................................................................................................... ........................................................................................................... 75. 18-1 G.R. Pakov. sto 676800.00 676800.00 100.00 + 76. 18-2 G.R. Pakov. nog 676800.00 1685.35 0.25 77. 19-1 G.R. Bigovanje 225600.00 149640.28 66.33 78. 19-2 P.R. Bigovanje 225600.00 53661.34 23.79 79. 53-9 G.R. Linija drv 676800.00 676800.00 100.00 + -----------------------------------------------------------------------------------------------

Slika 3: Rezultati izračuna 1-ve varijante optimalnog programa


Zanimljivo, treba napomenuti, da je stvarno postignuta dobit tvornice u prethodnoj godini bila približno ista kao što bi bila sa optimalnim programom proizvodnje po varijanti 1, ali, kao što će se vidjeti u daljem tekstu, sa dvostruko više utrošenih radnih sati.

6.2 Plan kapaciteta za 1-vu varijantu

Da bi se utvrdilo koliko je potrebno proizvodnih sati rada za optimalni proizvodni program, za 1-vu varijantu, unesen je u plan proizvodnje, u podsustavu SUPER-a Planiranje proizvodnje, te su izračunati potrebni kapaciteti po pojedinim radnim mjestima – norma sati,

prema normativima rada pohranjenim u Podsustavu SUPER-a Strukturne veze (sastavnice organizacije, proizvoda, projekta, objekata i ureñaja itd). Izračunato je da je za optimalni proizvodni program po 1-voj varijanti potrebno ukupno cca 373.900 proizvodnih sati.

6.3 Stvarno iskorištenje kapaciteta u tvornici

Da bi se efekti optimizacije mogli procijeniti, potrebno je planske proizvodne kapacitete za 1-vu varijantu optimalnog programa, usporediti sa učincima koji se stvarno postižu u tvornici. Za ovu procjenu postupili smo na slijedeći način:

********************* SVI DANI **** ***************** Orga.: 2 XXXXXXXXXXXXXXXXXXXXXXXXX SUPER, 07.0 1.11. Str.: 1 HIJERARHIJSKA STRUKTURA KORIŠTENJA RADNOG VREMENA U PERIODU 01.11.10 - 30.11.10 =================================================== ============================= % od Hijer. nivo Šifra N A Z I V Priznati sati ukup. ------------ ----- -------------------------------- ----- ----------------- ----- 1.......... 2 XXXXXXXXXXXXXXXXXXXXXXXXXX PRO Proizvodni rad 65.811,76 73,5 PRP Proizvodni radnici praznik 6.998,00 7,8 OPR Opravke i ponavljanja u proizvod nji 6.594,09 7,4 DOR Dorada robe dobavlja ča 2.048,79 2,3 PRB Proizvodni radnici bolovanje 1.936,00 2,2 PRE Prekrajanje rekl.ili škarta u pr oizvo 1.717,32 1,9 STE Dopuna vrem. zbog sitnih serija i št. 864,48 1,0 SOR Sort.i slaganje elemenat(razno)i kon. 729,87 0,8 TRA Transport 528,83 0,6 REK Prerada reklamacija iz skl.35 479,80 0,5 CIS Čiš ćenje odjeljenja i mašina 337,18 0,4 IST Istovar i utovar robe 383,29 0,4 IZS Izmjene u sast. i nedostatak nor mat.r 290,26 0,3 PRG Proizvodni radnici godišnji 294,00 0,3 POD Proizvodni radnici pla ćeno odsustvo 160,00 0,2 POP Popravka paleta 181,16 0,2 UZO Rad na uzorcima 128,34 0,1 BRP Rad sa bravarima i bravarski pos lovi 12,00 0,0 KON Kontrola stolica i stolova 13,51 0,0 ----- -------------------------------- ----- ----------------- ----- UKUPNO: 2 XXXXXXXXXXXXXXXXXXXX 89.558,78 100,0 Ukupno provedeni sati: 73.288,00 ******************* SAMO RADNI DANI *** *************** Orga.: 2 XXXXXXXXXXXXXXXXXXX SUPER, 07.01.1 1. Str.: 1 HIJERARHIJSKA STRUKTURA KORIŠTENJA RADNOG VREMENA U PERIODU 01.11.10 - 30.11.10 =================================================== ============================= % od Hijer. nivo Šifra N A Z I V Priznati sati ukup. ------------ ----- -------------------------------- ----- ----------------- ----- 1.......... 2 XXXXXXXXXXXXXXXXXXXXXX PRO Proizvodni rad 51.406,64 71,3 PRP Proizvodni radnici praznik 6.998,00 9,7 OPR Opravke i ponavljanja u proizvod nji 5.228,33 7,2 PRB Proizvodni radnici bolovanje 1.936,00 2,7 DOR Dorada robe dobavlja ča 1.598,12 2,2 PRE Prekrajanje rekl.ili škarta u pr oizvo 1.311,98 1,8 STE Dopuna vrem. zbog sitnih serija i št. 714,55 1,0 SOR Sort.i slaganje elemenat(razno)i kon. 575,51 0,8 REK Prerada reklamacija iz skl.35 413,30 0,6 TRA Transport 417,99 0,6 IST Istovar i utovar robe 309,12 0,4 PRG Proizvodni radnici godišnji 294,00 0,4 CIS Čiš ćenje odjeljenja i mašina 250,93 0,3 IZS Izmjene u sast. i nedostatak nor mat.r 220,86 0,3 POD Proizvodni radnici pla ćeno odsustvo 160,00 0,2 POP Popravka paleta 137,83 0,2 ----- -------------------------------- ----- ----------------- ----- UKUPNO: 2 XXXXXXXXXXXXXXXXXXXX 72.140,44 99,9 Ukupno provedeni sati: 73.288,00

Slika 4. Stvarno iskorištenje proizvodnih kapaciteta tvornice


Koristeći podsustav SUPER-a Praćenje proizvodnje, za 11-ti mjesec prethodne godine, koji je ocijenjen kao tipičan, dolazimo do toga da je procijenjeni stvarni kapacitet tvornice:

65.811 x 11 = 723.921 norma sati (računato da je 1 mjesec godišnji odmor).

Napomena: Na Sl. 4, u izvješću o stvarnom korištenju kapaciteta, proizvodni rad je za 1 mjesec 65.811 sati.

6.4 Analiza rezultata za 1-vu varijantu optimalnog programa proizvodnje

Za 1-vu varijantu optimalnog programa proizvodnje, treba uočiti slijedeće: � 5 od 13 (38%) reprezentativnih proizvoda ne ulazi u

optimalni program proizvodnje. Za ove proizvode bi, u cilju povećanja profitabilnosti tih proizvoda, te zadržavanje širine proizvodnog programa trebalo:

� Ispitati mogućnost povećanja prodajne cijene ... � ... i/ili analizirati konstrukciju i tehnologiju izrade

proizvoda, u cilju smanjenja troškova. � 8 radnih mjesta su iskorištena 100%, a još 3 su

iskorištena 95% i više. To su uska grla proizvodnje, pa treba ispitati mogućnosti i posljedice eventualnog povećanja kapaciteta na tim radnim mjestima.

� Ukupna postignuta dobit optimalnog programa je približno ista stvarno postignutoj dobiti. Meñutim, ukupni plan kapaciteta potrebnih za proizvodnju optimalnog programa godišnje proizvodnje, postiže se za približno isti broj sati koji se ostvare za 6 mjeseci. (65.811 x 11=723.921 : 373.900h), dakle za cca 2 puta manje proizvodnih sati. Dakle, dobit bi se mogla udvostru čiti ako bi prodaja plasirala optimalni program proizvodnje.

7. 2-GA VARIJANTA MODELA OPTIMIZACIJE

Razmatrajući modalitete kako bi se, i u kojoj mjeri, povećao kapacitet 11 radnih mjesta, koja su po 1-oj varijanti uska grla, došlo se do zaključka da je najadekvatnije to učiniti tako, da ova radna mjesta rade u 3 smjene, umjesto u 2 smjene, kao do sada. Na taj način, bez ikakvih investicija, kapacitet tih radnih mjesta povećao bi se za 50%.

S tim u svezi, u matematičkom modelu za optimiranje proizvodnog programa za 2-gu varijantu, trebalo je samo povećati ograničenje kapaciteta za tih 11 mjesta za 50%.

7.1 Izračun optimalnog programa za 2-u varijantu

REZULTATI OPTIMIZACIJE MODELA : VARIJANTA 2 ================================= ============ BROJ OGRANIČENJA : 79 BROJ PROMJENLJIVIH : 13 MAKSIMUM FUNKCIJE : 7,848.492 OPTIMALNI PROGRAM ---------------------------------- -------------- RBr. Opis promjenjive Vrijedno st promjenjive ---- -------------------- -------- -------------- 1. 10862 Tisch Multi XL 13 2. 6543 Stuhl Leon Buch 0 3. 9136 Stuhl Rudi Buch 0 4. 14415 Stuhl Tommy Bu 179.506 5. 17067 Stuhl Chris Ei 0 6. 3355 Stuhl Two Buche 0 7. 2367 Sessel Omega El 78.469 8. 11983 Stuhl Santos B 81.216 9. 17642 Tisch T66 Kern 25.044 10. 21980 Stuhl Ivonne B 0 11. 17632 Tisch T6 Kernb 0 12. 9195 Tisch Turin XL 26.783 13. 5873 Tisch Emanuela 0 ---------------------------------- -------------- STANJE OGRANI ČENJA --------------------------------------------------- ----------------------------- (1) (2) (2)/(1) RBr. Opis ograni čenja Postavljeno ograni č. Postignuto ograni č. % Sve ---- -------------------- -------------------- ---- ---------------- -------- --- 1. 24-1 G.R. Krojenje 676800.00 488958.03 72.25 2. 24-2 P.R. Krojenje p 225600.00 104886.26 46.49 3. 24-5 G.R. Šivanje 5414400.00 3717577.00 68.66 4. 11-1 G.R. Sklapanje 902400.00 902400.00 100.00 + 5. 11-3 G.R. Montaža 3384000.00 1077037.25 31.83 ................................................ .......................... ................................................ .......................... 73. 16-1 G.R. Montaža st 1692000.00 1538789.25 90.94 74. 16-3 G.R. Sto za oki 1128000.00 82.44 0.01 75. 18-1 G.R. Pakov. sto 1015200.00 972084.75 95.75 76. 18-2 G.R. Pakov. nog 676800.00 54.96 0.01 77. 19-1 G.R. Bigovanje 225600.00 208253.27 92.31 78. 19-2 P.R. Bigovanje 225600.00 77236.72 34.24 79. 53-9 G.R. Linija drv 1015200.00 1015200.00 100.00 + --------------------------------------------------- -----------------------------


7.2 Plan kapaciteta za 2-gu varijantu

Kao i za 1-vu varijantu, optimalni proizvodni program, za 2-gu varijantu, unesen je u plan proizvodnje, u podsustavu SUPER-a Planiranje proizvodnje, te su izračunati potrebni kapaciteti po pojedinim radnim mjestima – norma sati, prema normativima rada pohranjenim u Podsustavu SUPER-a Strukturne veze (sastavnice organizacije, proizvoda, projekta, objekata i ureñaja itd).

Izračunato je da je za optimalni proizvodni program po 2-oj varijanti potrebno ukupno cca

489.500 proizvodnih sati, dok je za 1-vu varijantu trebalo 373.900 h, dakle povećanje je 115.600 h, odn. 31%.

Za drugu varijantu povećanje potrebnog broja sati je uslijedilo manje zbog uvoñenja 3-će smjene za kritična radna mjesta, a više zato jer je postignuto bolje iskorištenje ostalih radnih mjesta, tj. onih koja nisu bila uska grla.

7.3 Analiza 2-ge varijante u odnosu na 1-vu varijantu

2-ga varijanta (kritična radna mjesta rade u 3 smjene): 1-va varijanta

1-va varijanta

2-ga varijanta (2)/(1)

Ukupna dobit 5,916.488 7,848.492 1,32 Potrebni proizvodni sati

373.779 489.265 1,31

Godišnji fond sati

715.000 =65.000 x 11

735.000 =715.000 + 11x2.000

Reprezentanti izbačeni iz optimalnog programa proizvodnje (šifre proizvoda)

17067 3355

21980 17632

5873

17067 6543 3355 9136

21980 17632

5873

Potrebni (h) po tehnologiji, za optimalni program proizvodnje

373.978 489.265 1,31

Kriti čna radna mjesta - uska grla Proizvodnje

9-20 10-9 10-49 18-1 53-9 7-34 24-1 24-5 25-1 25-3 7-36

9-20 11-1 10-9 10-49 18-1 53-9 7-34

8. REZULTATI I ZAKLJU ČCI

� Utvrñeni su reprezentanti proizvodnje: • koji najbolje odgovaraju proizvodno-prodajnim

uvjetima tvornice, odn. dobivene su smjernice koje proizvode treba forsirati i do koje mjere,

• koji ne ulaze u optimalni program proizvodnje, odn. za koje treba ispitati: � mogućnost povećanja prodajne cijene i/ili � revizije tehnologije proizvodnje, kako bi se

snizili troškovi proizvodnje, odnosno povećala profitabilnost ovih proizvoda ...

� ... ili ih treba izbaciti iz proizvodnog programa.

� Utvrñena su uska grla i viškovi kapaciteta na relevantnim radnim mjestima, za obje varijante optimalnog programa, sto daje osnovu za usmjeravanje investicijske politike i organizacije proizvodnje.

� Uvoñenjem 3-će smjene za 11 r. mjesta (od ukupno 79), koja su uska grla, bez dodatnih investicija, odn. 2-om varijantom u odnosu na 1-vu varijantu optimalnog programa proizvodnje, postiže se povećanje:

1. dobiti za 32% 2. iskorištenja kapaciteta za 31%.

Dakle, povećanje profitabilnosti, koje se postiže 1-om i 2-om varijantom približno je jednako, mjereno u odnosu na utrošene proizvodne sate. Po 2-goj varijanti, postiže se bolje iskorištenje proizvodne opreme, ali po cijenu sužavanja proizvodnog programa (izbačeno je 7 reprezentanata iz optimalnog programa), što ne odgovara odjelu Prodaje. Zbog toga, koja od ovih varijanti i u kojoj mjeri će se stvarno primjenjivati, odlučiti će se uzimajući u obzir i druge faktore - mogućnosti i potrebe prodaje, raspoloživost proizvodnog i skladišnog prostora itd.

� Ako bi prodaja uspjela plasirati optimalni proizvodni program, po bilo kojoj od 2 varijante, moguće je, bez ikakvih investicija u novu opremu, ostvariti dvostruko veću ukupnu dobit, od dobiti ostvarene u prethodnoj godini.

9. REZIME POSTUPKA

Iz izloženog se vidi, za optimizaciju proizvodnog programa: � Bilo je neophodno učešće korisnika za analize,

procjene i utvrñivanje: � Reprezentativnih proizvoda � Relevantnih proizvodnih radnih mjesta � Koeficijenata funkcije kriterija (dobit/jmj proizvoda) i

... � Utrošci vremena/jmj proizvoda, za svaki

reprezentativni proizvod i relevantno radno mjesto.

� Ograničenje kapaciteta za svako relevantno radno mjesto

� Modaliteta povećanja proizvodnih kapaciteta � Potencijalnih efekata varijanti optimizacije.

� Korišteni su podsustavi SUPER software ovim redoslijedom:

� Strukturne veze (sastavnice proizvoda) � Grupna tehnologija i konstrukcija � Optimizacija proizvodnje

� Prodaja � Planiranje proizvodnje � Praćenje proizvodnje.

Sama optimizacija, odn. izračun svake varijante trajao je vrlo kratko - za unos parametara, tj. formiranje modela za 1-vu varijantu u računalu, trebalo je cca 1 sat, a izračun rezultata trajao je svega 2-3 sekunde. Za 2-gu varijantu, za korekciju parametara trebalo je 2 minute, a izračun rezultata opet 2-3 sekunde.

U preostalom dijelu posla učestvovalo je 5 (rukovodnih) ljudi, sa angažmanom od po više sati, u toku cca mjesec dana. Dakle, najveći dio posla obavljen je kroz analize i procjene korisnika SUPER-a, uz korištenje 6 podsustava SUPER software, od kojih 5 koriste se za svakodnevne, potrebe poslovanja.


Podaci o autoru:

Prof. dr. Dragan Kova č SUPER-KING d.o.o. Prisavlje 12 10000 Zagreb tel/fax: ++385-1-619-6869 e-mail: [email protected] Obrazovanje: dr. sc. elektrotehničkih znanosti, mr. ekonomskih znanosti, postdiplomska specijalizacija “Analiza procesa i kontrola kvaliteta”, dipl. ing. strojarstva (Energetski odsjek). Radno iskustvo: Sada: direktor SUPER – KING d.o.o. za informatički inženjering, Zagreb Ranije: � Istraživanje, razvoj i proizvodnja visokonaponske rasklopne opreme � Projektiranje i izgradnja kompleksnih industrijskih objekata � Projektiranje, razvoj i implementacija informacijskih sustava u više desetina organizacija. � Izvanredni profesor i šef Katedre za informacijske sustave, Elektrotehnički fakultet Univerziteta u Sarajevu � Gostujući predavač na Univerzitetima Zagreb, Maribor, Mostar � Voditelj 7 znanstveno-istraživačkih projekata � Objavio cca 60 radova na raznim konferencijama i publikacijama. Education: Phd. In Computer science, Msc in Economics, Post diploma specialization in Quality Control, Bsc in Mechanical Engineering. Work expirience: Currently: SUPER-KING, firm for information engineering, director Before: - Research, development and production of high voltage electrical equipment - Design&development of industrial objects - Design, development and implementation of business information systems - University professor&head of Cathedre for Information systems - Various research projects


PRIMJENA POSLOVNE INTELIGENCIJE U OSIGURANJU

IMPLEMENTATION BUSINESS INTELLIGENCE IN INSURANCE

mr.sc. Boris Draženovi ć, Martina Draženovi ć

SAŽETAK:

U današnjem poslovnom svijetu upravljanje ljudima, poslovno planiranje i odlučivanje preduvjet su uspješnog poslovanja. Pristup pravoj informaciji u pravo vrijeme pridonosi optimizaciji utroška vremena i ljudskih resursa, te omogućava usredotočenost na donošenje kvalitetnih i pravovremenih poslovnih odluka. U praksi različite organizacijske cjeline tvrtke imaju zajedničku potrebu raspolaganja pravim informacijama na pravom mjestu u pravo vrijeme. Zadovoljavanje informacijskih potreba svih tih cjelina moguće je ostvariti primjenom integriranih sustava skladišta podataka (Data Warehouse - DW) i poslovne inteligencije (Business Intelligence System - BI).

U HELIOS VIG osiguranju provedbom projekta uspostave Data Warehouse sustava (DW) kojim je Odjel IT u 2010. godini, vlastitim snagama, ponudio i realizirao rješenje za kvalitetnijim praćenjem ostvarenih rezultata prodaje i naplate potraživanja, te distribucije tih podataka svim relevantnim sudionicima poslovanja (Upravi, Prodaji, Aktuarijatu, Kontrolingu, Financijama, državnim mjerodavnim institucijama) završena je prva faza konsolidacije informatičkog sustava u tvrtci.

Slijedio je logičan nastavak praćenja poslova osiguranja tj. generiranje prikladnih dinamičkih izvještaja (excel pivot tablice, sustav pisanih izvješća, te grafička prezentacija podataka). Od strane nalogodavca (Uprave) dano je do znanja kako se traženi rezultat mora realizirati bez posebnih dodatnih financijskih sredstava, tj. isključivo vlastitim snagama.

U provedbi te druge faze razvoja i konsolidacije vlastitog informacijskog sustava ustanovili smo kako se u našim poslovnim procesima pojavljuju odluke za koje je potrebna misaona obrada da bi dobile svoj konačan i svrsishodan oblik. Pojavila se potreba i za donošenjem odluka koje se temelje na ranije donesenim odlukama i promišljanjima koje je moguće procesno artikulirati. Zaključili smo kako je za tvrtku bitno da se generiranje takvih standardnih odluka realizira kroz informacijski sustav. Na taj način raste razina znanja cijele organizacije i postavlja se temelj za daljnji razvoj, dajući ljudima dovoljno vremena za donošenje nestandardnih odluka ili pak onih s kojima se susreću prvi put.

Kao jedna od mogućnosti BI sustava, sposobnost organizacije da automatizira i prepusti standardne operativne postupke na brigu računalnom sustavu, osigurava se oslobañanje dodatnih ljudskih resursa od svakodnevnih poslova koji se, uz razvoj odgovarajućeg sustava, uniformiraju i definiraju skupom pravila i procedura s točno utvrñenim redoslijedom procesa te njihovih ulaza i izlaza. Informacije o odvijanju procesa transparentne su i uvijek dostupne diljem organizacije.

Razvoj jednog ovakvog sustava ostavlja sve više vremena i resursa za obavljanje osnovne poslovne djelatnosti (Core Businessa).

Sustav BI koji je trebalo izgraditi mora se temeljiti isključivo na potrebama korisnika dok njegov rezultat rada mora predstavljati optimalno rješenje potrebno korisniku - rješenje u koje se može pouzdati u svakom trenutku tijekom cijelog životnog vijeka sustava.

Mogućnosti razvojnog alata kojeg trenutno koristimo u svakodnevnom radu u HELIOS VIG dozvoljavaju nam razvoj logičke i prezentacijske komponente sustava kao nadomjestak za kupnju gotovih BI alata trenutno raspoloživih na tržištu.

Kompletan posao razvoja, implementacije i edukacije odrañen je primjenom adekvatne projektne metodologije, dok vremenski rokovi i troškovi provedbe projekta nisu značajnije narušeni.

Na kraju, dobili smo vlastiti produkt za praćenje poslovanja 'skrojen po mjeri' naših potreba uz bitnu uštedu financijskih sredstava, te s znatnim uporabnim vrijednostima za njegove korisnike.

ABSTRACT:

In today's business world, people management, business planning and decision making are the prerequisite for a successful business. Access right information at the right time contributes to the optimization of expenditure of time and human resources, and to focus on making high-quality and timely business decisions. In practice, the various organizational units of a common need to dispose of the right information at the right place at the right time. Meeting the information needs of all these units is possible using the integrated system of data warehouse (Data Warehouse - DW) and BI (Business Intelligence System - BI).

The HELIOS VIG Insurance project implementation was establish the Data Warehouse System (DW) with the IT Department in 2010. year, our own forces, offered and implemented a solution for better monitoring of results achieved sales and debt collection, and distribution of these data to all relevant participants in business (Management, Sales, Aktuaristic, Controlling, Finance, the State competent institutions) completed the first phase of consolidation of an information system company.

He followed a logical continuation of monitoring activities to ensure that adequate generation of dynamic reports (Excel pivot tables, the system of written reports and graphic presentations of data). By the principal (the Board) is given to the knowledge of how search results should be realized without any additional funding, only its own forces.


In implementing the second phase of development and consolidation of its own information system, we found that in our business processes occur for decisions that require thought-processing to obtain a definitive and meaningful form. There was a need for making decisions based on the earlier adopted decisions and considerations that can articulate the process. We concluded that the company is essential to generate these standard-making is realized through an information system. In this way increases the level of knowledge throughout organization and sets the foundation for further development, giving people enough time to make non-standard decisions, or those with whom they meet for the first time.

As one of the options BI system, the organization's ability to automate and gave the standard operating procedures in the care of a computer system, ensuring the release of additional human resources from everyday affairs, with the development of an appropriate system, uniformed and defines a set of rules and procedures laid down by exactly the order process and their inputs and outputs. Information about the process is transparent and always available throughout the organization.

The development of such a system leaves them more time and resources to conduct basic business activities (core business).

BI system that is supposed to build must be based exclusively on the needs of users, while the result of his work must constitute an optimal solution to be - a solution in which they can realy on at any time during the lifetime of the system.

Possibilities of development tools that are currently used in day to day work in the HELIOS VIG allow us the development of logic and presentation components of the system as a substitute for the purchase of finished BI tools currently available on the market.

Complete job development, implementation and training is done by applying appropriate design methodology, and timing and costs of the project is not significantly disturbed. Finally, we got our own product for monitoring business 'custom tailored' to the essential needs of our savings funds, and with considerable use-values for its users.

1. UVOD

Na početku, kako bismo bolje razumjeli okolnosti koje su bile povod uspostavi Data Warehouse sustava razvijenog pretprošle godine vlastitim snagama, pojasnimo temeljne odrednice vezane uz poslovanje HELIOS VIG osiguranja.

U tu svrhu naveo bih nekoliko odrednica kao što su: � Društvo je osnovano 1991. godine � u travnju 2008. godine Wiener Stadtische

Versicherung AG VIENNA INSURANCE GROUP (VIG) iz Beča postaje većinskim vlasnikom Osiguranja Helios. Time HELIOS VIG postaje članom obitelji koja, trenutno, djeluje u 24 države Europe sa ukupno 49 osiguravajućih kuća

� radi na tržišnim osnovama � trenutno ima cca 420 stalno zaposlenih � poslovnu aktivnost provodi u preko 50

poslovnica/prodajnih ureda diljem Hrvatske � redovito podmiruje sve svoje financijske obveze � svake godine na tržište isporučuje odreñeni broj

novih proizvoda/usluga iz područja osiguranja.

Slika 1. Rasprostranjenost Vienna Insurance Group u

Europi

U svom poslovanju HELIOS VIG klijentima pruža čitav niz osiguravateljskih usluga kao što su: � životna osiguranja

� doživotna osiguranja � osiguranje kućanstva i ostale imovine � osiguranje motornih vozila (obvezno i kasko) � rentno osiguranje � putna osiguranja � osiguranja brodica i � osiguranje industrije.

Na slikama 1. i 2. prikazana je prostorna rasprostranjenost Vienna Insurance Group u Europi, te popis tvrtki kćeri za svaku od država u kojima VIG poslovno djeluje.

2. DEFINIRANJE PROJEKTNOG ZADATKA

U prethodnom koraku (pred dvije godine) zahtjev Uprave, kao naručioca projekta, bio je definiran na slijedeći način:

U tvrtci postoji niz heterogenih produkcijskih informatičkih sustava putem koji se obavlja djelatnost Društva. Potrebno je, uporabom prikladne projektne metodologije, osmisliti i realizirati efikasan, točan, brz i jeftin informacijski sustav za izvještavanje o poslovanju Društva.

Uzevši u obzir financijsku situaciju u Društvu i ponudu adekvatnih gotovih rješenja na tržištu potrebno je, odlukom Uprave kao naručioca, odustati od kupnje gotovog rješenja i realizirati razvoj i implementaciju originalnog rješenja vlastitim snagama. Nositelj razvoja mora biti Odjel informacijskih tehnologija (Odjel IT) u suradnji sa svim drugim odjelima u tvrtci.

Uzevši u obzir sve navedene okolnosti koje su tada bile aktualne odlučili smo se za razvoj vlastitog DW sustava kao temeljnu potporu u praćenju rada Društva i kao polaznu osnovu za donošenje poslovnih odluka.

Sada smo bili u situaciji gdje se, temeljem pozitivnih iskustava u primjeni našeg DW rješenja, od Odjela IT zatražila provedba nadogradnje tog sustava adekvatnom komponentom poslovne inteligencije (Business Inteligence – BI).

Naime, ispostavilo se kako rukovodne strukture svih razina previše vremena 'troše' na izvoñenje zaključaka iz ponekad vrlo složenih izvješća sa znatnim količinama podataka. Naravno, i ovog puta realizaciju projekta potrebno je realizirati vlastitim snagama uz prihvatljive troškove i vremenske okvire.


Odmah na početku projekta bili smo svjesni kako je uvoñenje BI sustava projekt kojemu nema kraja. Kako konkurencija postaje agresivnija, okolina nestabilnija i budućnost neizvjesnija, zahtjevi pred sustavima analize i prognoze postaju sve

složeniji. BI sustav trebao bi biti potpora u analizi, planiranju (budgeting), tj. kratkoročnih poslovnih odluka ali i u funkciji strategije.

Isto tako, BI sustav kakav je nama potreban ne postoji kao gotov proizvod na tržištu. Postoje proizvoñači koji nude tehnološke platforme i znanja za implementaciju. Nema rješenja s police. Razlog tome jest činjenica da modeli odlučivanja jesu slični, ali strategija, segmentacija tržišta i proizvoda, procesi i veze meñu njima su različite. Praktično, svaki je BI sustav u konačnosti originalno rješenje za potrebe onoga tko se njime koristi.

U suradnji sa naručiocem projekta definirali smo tablicu konzumenata budućeg DW/BI sustava i njihova prava. Ta struktura i pripadna prava prikazani su u tablici:

Postavilo se vrlo interesantno pitanje: Tko koristi BI sustav?

BI sustav je izvorno trebao biti namijenjen decision makerima, odnosno ljudima koji donose poslovne odluke. Meñutim, u suvremenim poduzećima odluke donose 'svi'. Ne moraju i ne mogu svi odlučivati, ali mogu svi predlagati. Da bi to napravili na najbolji mogući način potrebno im je svima pomoći suvremenim informacijskim tehnologijama.

Ključ razvoja sofisticiranog i funkcionalnog sustava poslovne inteligencije primjenjivog u ulozi potpore CRM

sustavima započinje nastojanjima da se u potpunosti shvati i razumije poslovni problem koji treba riješiti te realističnim utvrñivanjem koji su podaci u tu svrhu potrebni i s kojima se raspolaže. Na temelju toga moguće je razviti cjelovito rješenje, tj. sustav tzv. poslovne inteligencije u zatvorenoj petlji. Takav će sustav biti sposoban: � obavljati analizu klijenata � zasnivati tu analizu na informacijama stvorenima

segmentacijom klijenata i tržišta � analizirati uspješnost provedbe tekućih marketinških

aktivnosti � modelirati različite načine predviñanja budućih

dogañaja i ponašanja klijenata.

Glavni cilj projekta je upotrebom Klijentske inteligencije koja je neophodna podrška tvrtki u ostvarivanju glavnog cilja u poslovanju s klijentima – povećanje zadovoljstva klijenata proizvodima i uslugama, a time i njihove lojalnosti našoj tvrtki. Posebno bi bilo dobro ukoliko bi se u novi sustav uspjeli integrirati mjerenje rezultata poslovanja uravnoteženim usporedbenim tablicama rezultata poslovanja (Balanced Scorecard), te iskazivanje i predočavanje (vizualizacija) poslovnih dogañaja i rezultata poslovanja pomoću poslovne kontrolne ploče (Business Dashboards).

3. ŠTO JE TO POSLOVNA INTELIGENCIJA

Pojam Poslovna Inteligencija (eng. Business Intelligence – BI) prvi je upotrebio 1989. godine istraživač Gartner grupe Howard Dresner da bi opisao set koncepata i

Slika 2.Popis tvrtki kćeri za svaku od država u kojima VIG poslovno djeluje

konzument podataka pravo korištenja poslovnih podataka oznaka ranga

Uprava svi podaci A0

Direktori regija/prodajnih kanala svi podaci koji se odnose na njihovu regiju A1

Direktori poslovnica svi podaci koji se odnose na njihovu poslovnicu A2

Voditelji prodajnih ureda svi podaci koji se odnose na njihov prodajni ured A3

Voditelji odjela svi podaci koji se odnose na njihov odjel kojim rukovode A4

Samostalni referenti svi podaci koji se odnose na njihovu domenu rada A5

Zastupnici u prodaji svi podaci koji se odnose na njihov portfelj A6

Osoblje u administraciji svi podaci koji se odnose na njihovu domenu rada A7

Državne institucije svi podaci koji se odnose na njihovu društvenu funkciju B0 Tabela 1.


metoda za poboljšanje procesa odlučivanja baziranog na podacima. Do početka informatičkog doba krajem 20-tog stoljeća, menadžeri i njihovi suradnici u kompanijama i organizacijama su morali prikupljati informacije iz ne-automatiziranih izvora.

Poslovne odluke su se donosile najčešće na temelju intuicije menadžera. Sa razvojem računalne tehnologije i njenom širokom primjenom, menadžerima su postale dostupne ogromne količine podataka, ali zbog nedostataka

Komunikacijske infrastrukture ti podaci nisu bili dostupni u realnom vremenu. Podaci su analizirani vrlo dugo, pa rezultati analiza nisu bili adekvatni za kratkoročna planiranja. Dodatno, razvoj interneta takoñer je omogućio menadžerima svakodnevno dostupne ogromne količine podataka praktično u realnom vremenu.

Poslovna inteligencija je skup metodologija i softverskih alata koji omogućavaju korištenje podataka iz skladišta podataka (Dana Warehouse) i njihovo pretvaranje u informaciju potrebnu za donošenje poslovnih odluka.

Poslovna inteligencija obuhvaća: � Tehnike prikupljanja podataka (Extracting

Transformation Loading – ETL), � Skladištenje podataka (dana Warehouse - DW), � Sintezu podataka i analizu podataka (On Line

Analytical Processing - OLAP), � Prezentaciju podataka korisniku informacija.

Dodatno, postoje još i: � Ekspertni sustavi � Neuronske mreže, te � Internetska infrastruktura i e-dimenzija upravljanja

znanjem.

Takoñer, potrebno je još pojasniti i koncept odstupanja od ideala rada u stvarnom vremenu.

Prije pojašnjenja svake navedene stavke u slijedećoj tablici donosimo, za bolje razumijevanje poslovne inteligencije, kratki pregled ključnih pojmova:

3.1 ETL procesi

Slika 3, ETL procesi

pojam što podrazumijeva alati

DATA -transakcijske baze podataka (to su skupovi poslovnih podataka) -priručne tablice podataka

aplikativni software

ETL PROCES

To je skup procesa koji imaju za cilj: -zahvatiti (izuzeti) sve relevantne podatke iz jednog ili više transakcijskih sustava u skladište podataka (Extract) -preoblikovati ili transformirati izuzete podatke, usklañivanje podataka i uklanjanje 'pogrešnih' podataka (Transform) -učitati preoblikovane podatke u jedinstvenu novu bazu podataka (Load)

-batch procedure -on-line procedure (transformacija tih podataka čini i do 75% vremena cijelog ETL procesa)

INFORMATION -analiza podataka -modeliranje podataka

specifični programski alati

KNOWLEDGE

Pomoću znanja pohranjenog u računalne relacije generirati izvješća: -Ad hoc izvješća -posebna izvješća -dubinska izvješća (drill-down i drill-through)

-reporting -OLAP -Data Maining

Tabela 3.

opis ključnih pojmova za definiranje BI

Hrvatski Engleski kratica definicija/opis

Poslovna inteligencija

Business Inteligence

BI

Korištenje kolektivnog znanja organizacije sa ciljem postizanja konkurentske prednosti. To je pojam koji objedinjava DW, DM, OLAP i ostale pripadajuće metodologije.

Sustav potpore donošenju odluka

Decision Support System

DSS Posebna klasa računalnih informacijskih sustava koja pomaže u donošenju poslovnih i organizacijskih odluka

OLAP OLAP OLAP

On-line analitičko procesiranje. To je višedimenzionalna analiza podataka za podršku u odlučivanju. Obuhvaća analizu poslovnih informacija ac-hoc upita do predviñanja, modeliranja i simulacija.

Kopanje po podacima Data Maining DM Analiza na prvi pogled neprimjetnih veza izmeñu podataka

pomoću sofisticiranih statističkih procedura

Skladište podataka Data Warehouse DW To je kopija transakcijskih podataka posebno strukturiranih za upite i izvještavanje.

Baza podataka Data Base DB Skup transakcijskih podataka koji opisuju poslovne dogañaje. Tabela 2.


3.2 Skladište podataka

Definicija

Skladište podataka (eng. Data Warehouse) kao specifična vrsta baza podataka razvila se početkom 90-tih godina prošlog stoljeća. Glavni razlog koji je inicirao razvoj skladišta podataka bila je nemogućnost postojećih informatičkih sustava da udovolje sve većim zahtjevima za obradom velikih količina informacija i njihovom analizom.

Najčešće se u uporabi susreće troslojna arhitektura prikazana na slijedećoj slici:

Kao vanjski izvori mogu poslužiti: internet, razne priručne tablice i sl.

Pod operativnim se podacima podrazumijeva uporaba transakcijskih podataka na trenutno aktivnim produkcijskim bazama podataka.

Kod izuzimanja povijesnih podataka u postupak izdvajanja (ekstrakcije) uzimaju se podaci iz sustava za pohranu podataka u kojima se nalaze arhivirani podaci iz prethodnih obračunskih perioda.

Primjećujemo kako je skladište podataka u stvari sastavljeno od niza lokalnih spremišta podataka (Data Marts) koji su povezani u jedan sustav (jednu bazu podataka). Data mart spremišta podatke izuzete (ekstrahirane) iz izvora podataka (vanjski, operativni i povijesni) agregiraju i sažimaju prema kriterijima koje diktiraju njihove lokalne aplikacije tj. uzimaju one podatke koji im trebaju i po potrebi njih sintetiziraju. Ovdje se kreatori sustava mogu maksimalno rukovoditi potrebama naručitelja sustava, tj. svim njegovim poslovnim specifičnostima. Tu je u stvari sadržana sva moguća 'originalnost' svakoga od takvih sustava (za onoga za koga se dizajnira).

Modeli skladišta podataka

Data mart je podskup datawarehouse-a koji sadrži agregirane (sumirane) podatke na odreñenim nivoima hijerarhije. Data Mart je oblik skladišta podataka koji je namijenjen poslovnim dijelovima unutar same organizacije. Time se omogućava još efikasnije sagledavanje stvarnog stanja na način da se uklanja potreba za agregiranjem prilikom izvršavanja upita ili analiza od strane krajnjih korisnika. Tako se postižu mnogo bolje performanse, a redundancija podataka se izbjegava u najvećoj mogućoj mjeri.

Razine analize podataka u skladištima podataka

Razlikujemo tri osnovna nivoa: � generiranje stati čnih izvještaja

Ukoliko iz skladišta podataka trebamo samo izvještaj u tabličnom ili grafičkom formatu o postojećim podacima, dovoljan alat su generatori izvještaja (npr. Microsoft Crystal Reports ili Oracle

arhitektura karakteristike pojašnjenje napomena

s jednim zajedničkim skladištem podataka Izvori podataka

+ Data Warehouse

dvoslojna

s većim brojem nezavisnih lokalnih spremišta podataka Izvori podataka

+ Data marts

troslojna s jednim skladištem i većim brojem spremišta

Izvori podataka +

Data Warehouse +

Data marts

najviše u uporabi

Tabela 5. Arhitektura skladišta podataka

Podaci pohranjeni u: Temeljne karakteristike

Baza podataka -skup svih matičnih podataka i konstanti -skup svih transakcijskih poslovnih podataka -mora biti koncipirana tako da omogućava što veću operativnost poslovanja (brzinu i lakoću rada)

Skladište podataka

-tu se nalaze neki podaci iz baza podataka za koje se vjeruje da su relevantni za poslovne procese koji su njih generirali -podaci u skladištu su trajni i vežu se uz vrijeme nastajanja -cilj skladišta podataka nije operativnost poslovanja, nego stvoriti što bogatiji izvor informacija za različita izvješća, te dugoročne i kratkoročne analize i predviñanja

Tabela 4. Razlika izmeñu baze podataka i skladišta podataka

Slika 4.


Reports), koji jednostavno iz baze prikazuju podatke filtirirane, sortirane ili sumirane po odreñenim kriterijima.

� OLAP (On-line analytical processing) Složenije analitičke obrade podataka temeljen na multidimenzijskoj analizi baza podataka ('gledanje' podataka kroz veći broj filtera, odnosno dimenzija). OLAP omogućava obavljanje vrlo brzih analiza, sadrži i mogućnost vrlo robusne sposobnosti računanja.

Za prikaz podataka OLAP koristi najčešće trodimenzionalne kocke (cubes) i tablice. � rudarenje (kopanje) podataka (Data Mining)

Najsloženiji je dio obrade podataka koji podrazumijeva sofisticirane metode za traženje skrivenih zakonitosti meñu podacima (segmentirati tržište po nekom kriteriju, otkriti profil tipičnog klijenta, sklonosti kupnje proizvoda i predviñanje reakcije potrošača i sl.) Data Maining može biti dio DW-a (ukoliko ga posjedujemo), ali se može primijeniti i direktno na pojedinoj transakcijskoj bazi podataka.

3.3 OLAP alati

Sa stanovišta informatičke infrastrukture, sustav poslovne inteligencije započinje s izgradnjom skladišta podataka kao jednom centralnom bazom podataka u koju se slijevaju svi podaci nastali u poduzeću i(li) podaci nabavljeni izvan poduzeća.

Navedeni podaci prethodno prolaze kroz procese ekstrakcije, transformacije i punjenja, nakon čega su spremni za analize. Danas postoji čitav niz mogućnosti koje su na raspolaganju za eksploataciju i vizualizaciju podataka. Osnovni način je automatsko kreiranje i distribucija izvještaja na svim razinama odlučivanja, a najrašireniji način za sada predstavljaju multidimenzijske analize ili model OLAP alata. S obzirom da su u ranijim poglavljima opisane karakteristike ETL procesa, koncept skladištenja podataka i rudarenje podataka, u ovom dijelu dat je prikaz OLAP alata kao važne komponente sustava koji predstavlja poslovnu inteligenciju.

Puni naziv navedene skupine proizvoda proizlazi iz engleskih riječi On-Line Analytical Processing, što se uobičajeno prevodi kao "online analitička obrada". Prema "The OLAP Report: Glossary" skraćenica OLAP podrazumijeva kategoriju aplikacija i tehnologije namijenjenu za skupljanje, upravljanje, obradu i prezentaciju multidimenzijskih podataka namijenjenih analizama za potrebe upravljanja.

Karakteristika je OLAP proizvoda da se meñusobno razlikuju mnogo više od meñusobne razlike relacijskih baza podataka, programskih jezika, tekst procesora itd. Stoga je bitno da pri vrednovanju ovih alata u cilju odabira najpovoljnije solucije sudjeluju i odlučuju zajedno korisnici i IT stručnjaci.

Sam model OLAP alata zasniva se na sustavu multidimenzijske analize, pri čemu se podaci mogu istovremeno promatrati kroz veći broj dimenzija. Pri tom je uvodno bitno napomenuti da korisnici tih alata ne trebaju biti posebno obučeni niti obrazovani za obavljanje analitičkih poslova. Zbog lagane razumljivosti navedenog modela mogu ga

brzo primijeniti u svom radu. Tako proračunske karakteristike OLAP alata dopuštaju korisniku pisanje jednostavnih formula koje će se primjenjivati duž nekoliko dimenzija, a pritom je potrebno napisati tek nekoliko jednostavnih programskih instrukcija.

Karakteristika OLAP alata je velika brzina rada što omogućava njegovim korisnicima, najčešće stručnjacima i menadžerima, postavljanje upita i dobivanja odgovora u najkraćem mogućem vremenu, praktički trenutno, što nije slučaj kod drugih SW alata.

U pravilu su tako modelirani da se najveći broj odgovora dobije unutar pet sekundi, za jednostavnije analize ne više od sekunda, a u složenijim slučajevima ponekad je potrebno više od nekoliko minuta.

Daljnja je karakteristika ovih alata sposobnost analiziranja velikog broja dimenzija, pri čemu se u praksi taj broj kod kvalitetnih OLAP alata i u zahtjevnim analizama kreće na deset ili čak i više dimenzija. Budući da to nadilazi spoznajne mogućnosti prosječnog čovjeka, može se reći da navedeni alati omogućuju proširenje ljudske inteligencije.

Spektar mogućnosti koje obuhvaćaju OLAP alati vrlo je širok, počevši od jednostavnog pretraživanja, preko proračuna do sofisticiranih analiza kao što su vremenske serije i kompleksno modeliranje. Time oni obuhvaćaju kompletan slijed koji započinje podacima, nastavlja se informacijama i završava poslovnom inteligencijom.

Na slici 5. prikazana je karakteristična OLAP arhitektura koju sačinjava OLAP poslužitelj smješten izmeñu korisnika i skladišta, odnosno spremišta podataka s online vezom.

3.4 Prezentacija podataka

Prikazanom integracijom moguće je ostvariti unaprjeñenje, a time i korist za poduzeće jer korisnici

Slika 5.


mogu pristupati svim navedenim alatima na unificirani način. Oni više nisu ograničeni samo na korištenje onih alata na koje su navikli i koje znaju koristiti u okviru svoje organizacijske jedinice, već im sada stoji na raspolaganju zajedničko sučelje prema svim alatima poslovne inteligencije iz svih organizacijskih jedinica tvrtke, što znači mogućnost pristupa svim raspoloživim podacima tvrtke, a bez posebnog uvježbavanja.

S druge strane, omogućeno je integrirano praćenje uporabe, odnosno praćenje tko od zaposlenika i koje službe poduzeća, kako često i intenzivno i za koje svrhe koriste alate i informacije poslovne inteligencije. Na taj način moguće je otkriti dobre i loše strane poslovne inteligencije te provoñenje standardizacije onih uporaba koje su se pokazale korisnima i kvalitetnima (najčešće korištene).

Nadalje, ugradnjom poslovne inteligencije u korporacijski portal, omogućeno je zaposlenicima kreiranje izvještaja prilagoñenih njihovim specifičnim potrebama, a naročito ad hoc pristup podacima, onda kad to nalaže trenutna situacija. Time dolazi ne do personalizacije samih alata poslovne inteligencije, već do rezultata njihove primjene. Rezultat takvog pristupa je unaprjeñenje izvješćivanja jer je omogućeno generiranje izvješća neovisno o tome pomoću kojeg su alata proizvedeni sastavni dijelovi izvješća, kao i integraciju strukturiranih i nestrukturiranih podataka, što možda predstavlja i najveću korist od primjene koncepta poslovne inteligencije integrirane na razini tvrtke.

Time se omogućava vodstvu tvrtke da se usredotoči na same poslovne procese bez nepotrebnog opterećenja nebitnim problemima. Ovakav koncept poslovne inteligencije integrirane na razini poduzeća i ugrañene u korporacijski portal

omogućava personalizaciju informacija prema posebnim zahtjevima korisnika i potpuno iskorištenje svih mogućnosti koje pruža suvremena informacijsko-komunikacijska tehnologija.

3.5 Ekspertni sustavi

Sljedeći korak u razvoju informacijskog sustava predstavljaju ekspertni sustavi. Oni za razliku od baze podataka kojom se koriste transakcijski sustavi i bazom modela koju koristi sustav za podršku odlučivanju, posjeduju bazu znanja i metode za nadograñivanje informacija koje omogućuju predviñanje i odgovor na pitanja tipa "što ako", kao i elemente komunikacije s ekspertom za neko područje. Ovi sustavi predstavljaju

najvišu evolucijsku fazu informacijskih sustava i predstavljaju najvrednije proizvode koji služe za potporu poslovnom upravljanju.

Ekspertni sustavi nisu zamjena za OLAP sustave, već predstavljaju nadogradnju i dopunu prethodnih faza informacijskih sustava.

Za bolje razumijevanje, komponente tipičnog informacijskog sustava poduzeća prikazane su na slici 6:

3.6 Neuronske mreže

Primjena neuronskih mreža, odnosno nelinearnih modela predviñanja interesantna je jer omogućava modeliranje velikih i kompleksnih problema u kojima može biti stotine varijabli koje imaju mnogo interakcija. Postojeće biološke neuronske mreže su, razumljivo, neusporedivo kompleksnije u odnosu na matematički model koji se koristi u praksi.

U matematičkom modelu neuronske mreže osnovna jedinica je dizajnirana po uzoru na biološki neuron. Jedinice kombiniraju ulaze u jedinstveni rezultat (najčešće funkcija sumiranja), koji zatim biva preusmjeren u funkciju transformacije koja kalkulira izlaznu vrijednost i najčešće poprima vrijednost izmeñu 0 i 1. Kombinacijska i transferna funkcija zajedno čine aktivacijsku funkciju neurona.

Osnovni princip učenja neuronske mreže predstavljaju veze izmeñu eksperimentalnih uzoraka. Uzorci se pridružuju sebi samima (klasteriranje) ili se dva različita tipa uzoraka pridružuju jedan drugome. Temeljna ideja je predviñanje budućih dogañaja što je i osnovna ideja regresijskih modela. Meñutim ovi sustavi imaju puno širi spektar primjene od regresijske analize. Bitno je naznačiti da ne postoji jedinstveni model neuronske mreže koji bi se primjenjivao na sve vrste problema. Karakteristika svakog od dosad razvijenog modela je da ima odreñene prednosti kod primjene u nekom specifičnom području.

Neuronske mreže razlikuju se od mnogih statističkih metoda na više načina. Prvenstveno, neuronske mreže imaju više parametara od tipičnih statističkih modela. Prednost neuronskih mreža je ta da se mogu lagano implementirati i provoditi u ogromnom broju paralelnih kompjutora pri čemu svaki čvor istodobno provodi svoju vlastitu kalkulaciju.

Neuronske mreže predstavljaju snažan alat, naročito za prognoziranje trendova i predviñanje na temelju povijesnih podataka. One služe za davanje odgovora na

Slika 6.


pitanja kao što je na primjer: Ako se cijena artikla X smanji za odreñeni postotak, za koliko će se povećati potražnja za tim artiklom. Meñutim treba naglasiti da neuronske mreže nije lako interpretirati, te da one zahtijevaju sveobuhvatan trening za osposobljavanje osim za slučajeve rješavanja "malih" problema.

3.7 Internetska infrastruktura i e-dimenzija upravljanja znanjem

Internet je danas nezaobilazna činjenica u svim segmentima poslovanja. Razvojem internetske infrastrukture stvaraju se nove dimenzije koje znatno utječu na poslovanje suvremenih kompanija. Glavne prednosti Interneta kao globalne svjetske komunikacijske mreže sastoje se u svladavanju prostornih zapreka, ubrzavanju komunikacijskih procesa i rzom i efikasnom opskrbljivanju relevantnim znanjem, bilo stručnim ili općenito.

Razvojem informacijske tehnologije općenito, pa tako i interneta, dolazi do afirmacije kvalitativnih, neopipljivih parametara kao što su ideje, inovacije, intelektualni kapital i znanje te povezanost s kupcima odnosno korisnicima usluga kao i njihovo zadovoljstvo kvalitetom proizvoda ili usluge. Razvoj informacijske tehnologije i u njenom okviru interneta ojačao je potrebu za upravljanje znanjem.

Prednosti koje daje upotreba elektroničkih tehnologija, kao što su primjerice intranet i internet očitavaju se u puno lakšem i jednostavnijem dijeljenju znanja unutar i izvan kompanije. Danas ta tehnologija otvara sredstva koja omogućavaju sakupljanje i skladištenje znanja i stvaranje novih znanja neophodnih za razvoj poslovanja.

Tehnologija još uvijek ne može zamijeniti vrijednost i potrebu izravne tzv. "face-to-face" komunikacije, barem ne kad je u pitanju dijeljenje iskustvenog znanja, ali može uspješno asistirati u posredovanju i olakšavanju kreiranja mreže temeljene na znanju ljudi. Ova tehnologija, posebice internetska infrastruktura (web stranice i e-mail) ima naročitu vrijednost za one kompanije koje posluju na udaljenim i različitim geografskim lokalitetima i gdje je onemogućen izravan kontakt i komunikacija izmeñu tražitelja znanja i onih koji ga mogu dati, pa ona ima i ulogu posredovanja.

Nadalje, razvoj internetske infrastrukture podloga je za razvoj globalnog tržišta znanja na kojem se susreću oni koji znanje nude i oni koji kupuju znanje. Informacije danas postaju sve dostupnije, pa se povećava i utjecaj pojedinaca na poslovanje kompanija. Znanje jednog čovjeka može imati snažan utjecaj u poduzetništvu koje se oslanja na znanje. Taj je proces nadopunjen i internetom. Donedavno su velike organizacije održavale svoju moć menadžmentom informacija, u okviru i izvan svojih granica, a danas to više nije moguće. Danas vodeći stručnjaci za intelektualni kapital navode kako budućnost počiva na razmjeni znanja, jednako kao i na dijeljenju znanja.

Velika se vrijednost nalazi u razvoju tržišnih mehanizama npr. internetskih burzi, koje stvaraju učinkovita tržišta znanja. Ona omogućavaju "kupcima i prodavačima" znanja razmjenu svoje robe po cijenama utvrñenima na temelju karakteristika navedenih tržišta.

Prema predviñanjima navedena će tržišta postati trećom generacijom burza i aukcija za recepte znanja. Prve su se burze, ustanovljene prije više stotina godina, bavile razmjenom sirovina. Zatim, pred stotinjak godina slijedi razvoj financijskih burzi, a danas smo svjedoci nastajanja treće generacije burza - burza znanja.

Ovdje dolazi do iskušavanja koncepta aukcijske razmjene znanja. Na takvoj burzi korisnici mogu kupiti i prodati svoje znanje i iskustvo putem računalne mreže. Ovdje dolazi do izražaja mogućnost mreže triju sveobuhvatnih fenomena: sveobuhvatni pristup informacijama koji nudi internet, sofisticiranu dinamiku aukcijske tehnologije i tržišnu procjenu intelektualnog kapitala.

Nadalje, predviñanja su kako će internetske burze započeti generirati transakcijske prihode u vrijednosti od više milijardi dolara godišnje kao i da će menadžment i razmjena znanja putem interneta stvoriti novi internetski sektor sa iznimno značajnim financijskim pokazateljima.

Na kraju, interesantno je dodati kako, za razliku od drugih roba koje se razmjenjuju na burzama, prednost i karakteristika znanja jest da je ono obnovljiv izvor te da se ne troši, već naprotiv njegovom uporabom vrijednost mu raste. Internet je pak sredstvo koje pruža uslugu lagane i sveobuhvatne razmjene znanja i oslobañanje vrijednosti i potencijala ljudskih mozgova.

3.8 Odstupanje od ideala rada u stvarnom vremenu

U prethodnim je odjeljcima već više puta spomenuto kako operativna poslovna inteligencija teži dosizanju ideala rada u stvarnom vremenu. No, u današnjim uvjetima poslovanja i na današnjem stupnju razvitka informacijske tehnologije, u praksi je taj ideal gotovo nemoguće ostvariti. Naime, u vremenskom kontinuumu izmeñu zbivanja nekog dogañaja i poduzimanja informirane akcije neminovno dolazi do kašnjenja barem u nekom od tri segmenta, odnosno komponente: 1. do kašnjenja podataka (engl. Data Latency) 2. do kašnjenja analize (engl. Analysis Latency) i 3. do kašnjenja odluke/akcije (engl. Decision/Action

Latency).

Kašnjenje podataka definira se kao vrijeme potrebno za prikupljanje „sirovih“ (izvornih) podataka, njihovu pripremu za analizu i pohranjivanje na mjestu na kojemu mogu biti zahvaćeni kada se krene s njihovom analizom. Važne funkcionalnosti pritom su sljedeće: � profiliranje podataka � pročišćavanje podataka � provjera vjerodostojnosti (validacija) podataka � unošenje (punjenje) podataka u odgovarajući

repozitorij � ekstrakcija podataka iz repozitorija u kojemu su

smješteni � preobrazba (transformacija) podataka � povezivanje (integracija) podataka � isporuka podataka aplikaciji ili korisniku.

Kašnjenje analize je vrijeme potrebno za pristupanje podacima, njihovu analizu, preobrazbu podataka u informacije, primjenu poslovnih pravila i pravila za slučaj izuzetaka, te za generiranje izvješća ili upozorenja odnosno alarma, ako je to neophodno. Analizu može provoditi sama aplikacija poslovne inteligencije ili to pak može biti zadatak korisnika, tako da i aplikacija i čovjek mogu biti uzrokom ili „krivcem“ za kašnjenje analize.

Kašnjenjem odluke/akcije smatra se vrijeme potrebno za prijam izvješća, upozorenja ili alarma, njihovo izučavanje, ispitivanje i/ili tumačenje, donošenje odluke o tome što je neophodno ili uputno učiniti, tj. koju – ako i koju – i kakvu akciju u konkretnom slučaju poduzeti oslanjajući se na poznavanje obilježja poslovanja i poslovnih procesa, te, konačno, za poduzimanje same akcije.


4. PRISTUP REALIZACIJI SUSTAVA

4.1 Ciljevi projekta

� U skladu s novom politikom tvrtke, a to je stvaranje pouzdanog partnera našim klijentima, snažan rast na tržištu, te odlučnost pri realizaciji ciljeva odlučili smo se na implementaciju DWH/BI-a s ciljem poboljšanja postojećih performansi poslovanja.

� Treba omogućiti efikasan i cjenovno prihvatljiv način da se iz različitih transakcijskih sustava podaci očiste i strukturiraju kako bi postali pogodni za razne analize kao i za izradu izvješća za vanjske i interne korisnike.

� Traži se uspostava mogućnosti efikasnog upravljanja i pravovremena reakcija u sprečavanju nastanka poslovnih dogañaja izvan zadanih okvira funkcioniranja tvrtke.

� U konačnici ovaj sustav definitivno treba omogućiti dugoročnu sigurnost poslovanja i mogućnost uvoñenja bržih i jednostavnijih poslovnih analiza i poslovnog planiranja.

� Korištenjem DW/BI metodologije izgradnje sustava treba, takoñer, uspostaviti i jedinstvene tablice i jedinstveno imenovanje, nadzor korištenja, praćenje ostvarenja ciljeva kroz kontrolu upravljivog dijela poslovnog procesa u odnosu na poslovne dogañaje

4.2 Obuhvat projekta

Mora biti u skladu sa ranije navedenim ciljevima projekta. U našem konkretnom slučaju to znači kako se isti treba odnositi na dva glavna aspekta:

Izvještavanje : � Statutarno � Menadžersko

Poslovna područja: � Financijski izvještaji � Izvještaji za FINU � Statistički izvještaji - HANFA � Managerski izvještaji � Kontroling � Štete � Prodaja � Tarifa � Ljudski resursi � Aktuari � Marketing.

Iz navedenog vidljivo je kako svi relevantni sudionici naših poslovnih procesa moraju biti uključeni u novi sustav bilo kao 'davatelji' informacija i pravila poslovanja i(li) kao 'primatelji' rezultata obrade podataka. Pri tome se može i treba definirati nivoe dostupa informacijama što je prikazano u tablici konzumenata podataka i rangu prava njihova korištenja prikazanoj u točci 2. (Definiranje projektnog zadatka).

4.3 Izbor alata za realizaciju sustava (dogradnje BI komponente na postoje ću DW komponentu)

Za početak izvršili smo uvid u trenutnu situaciju vezano na svjetskom tržištu 'gotovih' rješenja.

Kako se alat za generiranje baza podataka i pripadne programske potpore kojim se koristimo u svakodnevnom radu Odjela IT nalazi u rangu Oracle produkata zaključili smo kako isti u potpunosti može poslužiti u zadovoljavajućoj mjeri i u skladu sa našim potrebama. Stoga smo definirali slijedeći spektar alata potrebnih za realizaciju (nadogradnju) našeg sustava: � baza podataka i generator aplikacija: Progress ver.

10.2B (2010.) � izrada ETL procedura: Progress ver. 10.2B, SAP

Extractor, Oracle extractor, MS SQL Query reports � izrada BI komponente: Progress ver. 10.2B,

Progress Ultra Command Reporter.

4.4 Odabir projektne metodologije

Kao i u projektu uspostave DW sustava i sada smo se odlučili za PMI projektnu metodologiju. Dodatan je razlog tome činjenica da istu dobro poznajemo i već smo je koristili u nekim našim projektima.Time smo uštedjeli na vremenu i troškovima nužnim za savladavanje neke nove projektne metodologije koja bi, na posljetku, dala slične ili potpuno iste rezultate.

Slika 8.

Slika 7.


5. REALIZACIJA

5.1 Izvori poslovnih podataka

Izvori poslovnih podataka u našoj tvrtci nalaze se, iz povijesnih razloga, u heterogenom okružju baza podataka. Raznovrsnost tih izvora, platformi na kojima oni rade kao i fizičke lokacije gdje se isti nalaze donosimo u tablici 6.

5.2 Uspostava DW sustava

Iz tablice prikazane u prethodnoj točci proizlazi struktura izvora podataka za naš Data Warehouse sustav. Prema zahtjevu naručitelja projekta (Uprave) svi relevantni

izvori podataka za praćenje poslovanja morali su biti uključeni u 'punjenje' istog. Način kako smo realizirali naš DW sustav detaljno je opisan u radu koji je bio prezentiran na prošlogodišnjoj CASE konferenciji.

5.3 Implementacija BI komponente

Temelji se na ugradnji komponenata navedenih u tablici 7.

5.4 Provjera ispravnosti rada (validacija) sustava

Iznimno bitno za prihvaćanje DW/BI sustava od strane rukovodstva i djelatnika tvrtke predstavljalo je uspješno definiranje i provedba provjere ispravnosti rada istog. Točna informacija u pravom trenutku, bez obzira na to tko nju je zatražio, preduvjet je za donošenje odluke kako je DW/BI sustav prihvatljiv i od sada pa na dalje meritoran izvor podataka za operativo i strateško upravljanje tvrtkom.

Validaciju rezultata rada sustava podijelili smo na kontrolu funkcioniranja i provjeru točnosti podataka koju trebaju provesti glavni konzumenti sustava + osoblje Odjela IT (zbog provjere tehničko-tehnoloških karakteristika).

5.5 Optimizacija sustava

Optimizaciju našeg DW/BI sustava provodimo permanentno od njegove uspostave. Isto se realizira na nekoliko načina: � svakodnevna suradnja sa svim korisnicima DW/BI

sustava � promatranje konkurencije (razgovorima sa

konkurencijom, proučavanje članaka i internet stranica)

� uvid u mogućnosti profesionalnih alata za BI koje crpimo iz najnovijih podataka objavljenih na web

� stranicama raznih proizvoñača BI komponenata (na domaćem i inozemnom tržištu).

Tabela 6.

Slika 9.


5.6 Edukacija korisnika sustava

Edukacija korisnika sustava provodi se: � na sastancima Uprave, Prodaje i prodajnih timova � materijali su objavljeni na intranet stranicama tvrtke i

dostupni su svim zaposlenima � dodatno se odgovara na upite korisnika pristiglih

elektroničkom poštom.

5.7 Budu će dorade sustava

Najčešće zamjerke naših korisnika odnose se na nemogućnost lakog pristupa našem DW/BI portalu putem web stranica tvrtke. Naime, za sada, aktivnosti se odvijaju isključivo u client-server okruženju. Odjel IT preuzeo je obvezu realizacije pristupa u sustav putem internet portala do kraja lipnja 2011. godine.

Druga grupa zahtjeva odnosi se na definiranje i implementaciju alarmnih alata i sustava ranog obavještavanja. Pod time se podrazumijeva nadogradnja BI sustava logikom dojave vezano uz praćenje tokova gotovog novca u tvrtci i kvalitetnijem sustavu detektiranja neplaćenih izlaznih računa.

Dodatno, stalni su zahtjevi za doradom sustava zbog: � promjena u zakonskoj regulativi i � zahtjevima za poslovnim izvješćima i analizama od

strane vlasnika tvrtke iz Austrije.

Takvi se zahtjevi, zbog okolnosti u kojima su se pojavili, odmah realiziraju.

6. PRIMJERI RADA DW/BI SUSTAVA

6.1 primjeri unosnih ekrana za BI (prozora za generiranje upita, izvješ ća i analiza)

konzument podataka što provjerava zaključak

Uprava provjera seta temeljnih podataka nužnih za upravljanje tvrtkom (usporedba sa financijama, računovodstvom i aktuarima)

zadovoljava, traži se pogreška od max. 0,01%

Direktori regija/prodajnih kanala

svi podaci koji se odnose na njihovu regiju/prodajni kanal (osnovni podaci za svakog od zastupnika, poslovanje svake poslovnice, izvršenje plana prodaje, usporedba sa ostalim regijama/prodajnim kanalima)

zadovoljava, traže mogućnost da svaki zastupnik može putem web sučelja 'vidjeti' svoje podatke

Direktori poslovnica Voditelji prodajnih ureda

osnovni podaci za svakog od zastupnika, poslovanje poslovnice/prodajnog ureda, izvršenje plana prodaje

zadovoljava, traži mogućnost web pristupa podacima

Voditelji odjela

Samostalni referenti

svi podaci koji se odnose na njihovu domenu rada (matični podaci, transakcijski podaci, analize i pregledi, rang liste)

zadovoljava, traže dodatni set izvješća i analiza

Zastupnici u prodaji Praćenje njihova portfelja, skadencari, nagradni bodovi, izvršenje plana prodaje, dugovanja klijenata, stornacije polica

zadovoljava, traži mogućnost web pristupa podacima

Osoblje u administraciji

provjera točnosti matičnih podataka, transakcijskih podataka u Call centru, Štetama, ljudskim resursima i prodajnoj mreži, provjere po zahtjevu klijenata

zadovoljava

Djelatnici Odjela IT

provjera tehničko-tehnoloških karakteristika rada sustava (brzina rada pojedinih komponenti, situacije oporavka zbog 'pada' sustava, sigurnost pristupa podacima, pravo pristupa podacima ovisno o funkciji u poslovnim procesima tvrtke, fizička veličina baza podataka, nadogradnja BI komponente, provjera rada ETL procedura)

zadovoljava, traže da se odobri dnevni režim 'punjenja' DW/BI sustava (sada se to provodi jednom tjedno u dane vikenda)

Tabela 8.

temeljne komponente na što se odnosi produkt/glavni konzumenti

ugradnja IF-THEN relacija Implementacija relacija obrade podataka uvjetovanih poslovnim razlozima

Standardna poslovna izvješća za potrebe tvrtke

ugradnja naprednih statističkih metoda

Implementacija BSC metode, ABC metode ili neke slične metode u svrhu generiranja statističkih izvješća

Obvezna izvješća za potrebe državne regulatorne agencije

implementacija naprednih pretraživanja i zaključivanja iz Odjela aktuaristike

Implementacija specifičnih manipulacija podacima u svrhu izrade specifičnih izvješća iz aktuaristike

izvješće MROŽ, ripis dobiti, definiranje novih proizvoda za svakodnevnu uporabu u Aktuarijatu

ad hoc upiti i analize Brzi upiti za nestandardne situacije Izvješća i analize za potrebe Kontrolinga

implementacija specifičnosti i pravila koja vrijede u osiguravateljnoj industriji

Mogućnost generiranja izvješća specifičnih za ovu vrstu financijske industrije

poslovna izvješća za potrebe: --HANFA-e -Uprave HVIG -Uprave VIG -poreznu upravu

Alarmni alati i sustavi ranog obavještavanja * u pripremi

neuronske mreže * u pripremi

Tabela 7.


a) za kumulativni pregled rezultata prodajnih aktivnosti

b) za pregled ostvarenja prodaje po grupama i vrstama osiguranja

c) za 'brzi' prikaz ostvarenja prodaje po prodajnim kanalima

(*) Prikazani podaci ne odgovaraju stvarnom stanju, već su dati samo u

prezentacijske svrhe


d) za prikaz ostvarenih rezultata prodaje u organizacijskim jedinicama (ukupno ili za pojedinu org. jedinicu)

e) za detaljni uvid u strukturu zastupnika u prodajnoj mreži

f) za pregled podsjetnika i opomena lošim platišama


g) za pregled prodajnog portfelja

h) za brzi uvid u analitiku premijskog dnevnika


i) za uvid i prijavu štetnog dogañaja

j) za uskladbu podataka o klijentima u svim produkcijskim bazama podataka


k) za dinamičke preglede kod najsloženijih vrsta upita

odabir vrste odabir baze(a) podataka pohrana dinamičkog pregleda dinamičkog pregleda i data set(ov)a u njima za buduća (ponovna) korištenja

mogučnost sortiranja prikaz odabranih prikaz odabranih podataka po nekom tablica podataka polja u tablicama od polja iz baze(a) podataka podataka

6.2 izvješ ća (excell izvješća, grafička izvješća, porezi, razni doprinosi, ukupno prodanih polica, storniranih polica,

usporedba prethodna godina – tekuća godina, alarmiranje i proaktivno obavještavanje, izvještavanje državnih institucija i udruga (HANFA, HUO, MUP)

(*) Prikazani podaci ne odgovaraju stvarnom stanju, već su dati samo u prezentacijske svrhe


6.3 statistika i analize (najprodavaniji cjenici, vrste osiguranja, prodajni kanali, rang liste prodavača po različitim kriterijima, ....)





6.4 prijedlozi odluka (odluke o nagradama prodavača, o raskidu ugovora o radu, rang lista direktora poslovnica, dobri i loši 'proizvodi',

a) prijedlog za nagradu najboljim prodavačima osiguranja (na temelju broja nagradnih bodova ostvarenih za prodajne rezultate)

b) prijedlog za raskid ugovora o zastupanju: Sustavu je postavljen zahtjev za generiranjem liste zastupnika u prodaji koji imaju izvršenje dodijeljenih njim ugovorenih osobnih planova prodaje sa izvršenjem istih manje od 8% u promatranom periodu. Generiranje navedene liste provedeno je na slijedeći način: � Obuhvat podataka iz svih produkcijskih baza

podataka obavila je DW komponenta � Uzimanje u obzir pravila rada (prodaje) i načina

praćenja ostvarenih prodajnih rezultata obavila je BI komponenta.

U konačnosti dobivena je slijedeća lista koja je Upravi poslužila kao prijedlog za donošenje konačne odluke:

7. ZAKLJU ČAK

Provedbom projekta Nadogradnja postojećeg DW sustava na DW/BI sustav djelatnici Odjela IT opravdali su glavna očekivanja naručioca projekta koja ukratko možemo svesti na slijedeće:

� uvoñenjem DW/BI stvoreni su preduvjeti za još uspješnije poslovanje tvrtke

� bitno je povećana brzina i preciznost izrade poslovnih izvješća

� poboljšana je učinkovitost i funkcionalnost produkcijskih baza podataka

� povećana je produktivnosti djelatnika koji se koriste

DW/BI sustavom � točnost podataka u izvješćima kreće se u unaprijed

dogovorenoj toleranci � omogućen je uvid u trenutno stanje poslovnih

rezultata, pouzdanost i sigurnost primljene informacije

� brza i konfigurabilna izrada izvješća i analiza � povećana je mogućnost pravovremene reakcije na

poslovne dogañaje neprihvatljive za tvrtku � bolja je usmjerenost rukovodnih struktura na

postizanje zadanih ciljeva tvrtke.

Nesporno je kako je znanje postalo glavni ekonomski resurs poslovnih subjekata 21. stoljeća.

Upravo BI komponenta najviše pomaže u rješavanju upravljačkih problema. BI sustav je takav sustav koji čuva informacije i znanje o konkurenciji, kupcima, dobavljačima, procesima i vezama meñu procesima, te omogućava poslovno pregovaranje, argumentirani nastup prema kupcima i dobavljačima. Omogućava kvalitetnije operativno planiranje, bolje razumijevanje




vlastitih kupaca, dobavljača, promatranje konkurencije, pojedinih tržišnih segmenata i predviñanje budućih pojava, detaljno praćenje vlastite prodajne mreže.

U tom smislu naš je DW/BI sustav postao dio naše poslovne svakodnevnice i više nitko u tvrtci ne razmišlja da li ga koristiti ili ne. Upravo suprotno, gotovo dnevno u Odjel IT pristižu zahtjevi za dogradnjom BI komponente sa sve složenijim relacijama.

Korišteni izvori:

Knjige:

1 R. Kimball, R. Mertz: The Data Webhose Toolkit-Building the Web-Enabled Data Warehouse, J. Wiley 2000.

2 Katarina Ćurko: Skladište podataka – sustav za potporu odlučivanju, Ekonomski pregled 2001.

3 Grupa autora, Data Modeling techniques for Data Warehousing, e-book, IBM Redbooks, 2001.

4 M. Zekić-Sušac: Skladištenje podataka (Data Warehousing)

5 21 Edvinsson, Leif.:, "Korporacijska longituda - navigacija ekonomijom znanja, Differo, Zagreb, 2003.,

6 PMI, A Guide to the Project Management Body of Knowledge, Third Edition (PMBOK Guide), Newton Square ,

7 PE, Project Management Institue, 2004.

8 H. Kerzner, Project Management,: A System Approach to Planning, Sceduling & Controlling, Eighth Edition,

9 Kellett, A., "Integrated Business Intelligence", Butler Group, April 2003.

10 Hobken, NY: John Wiley & Sons, 2003.

11 Kimball Ralph and Ross Margy: The Data Warehouse Toolkit Second Edition, J. Wiley 2002.

12 Joe Gamczarski: Data Warehouse Implementation, VDM Verlag 2009.

13 Javorović, B., Bilandžić, M.: Poslovne informacije i business intelligence, Golden marketing – Tehnička knjiga, Zagreb 2007.

Internet:

14 Swoyer, Stephen. "PMML: Data Mining Tool for the Masses?". http://www.esj.business_intelligence", 25. 05. 2005.

15 Taylor, James. “Beyond BI: Turning Business Intelligence into Action”. http://www.fairisaac.com, 04/2005.

16 White, Colin. "Developing a BI Strategy for CRM/ERP Data”. http://www.tdwi.org, 08/2004. "Kimbal Group: Data Warehouse Training, Practical Technique", http://www.rkimbal. com/html/articles.html, 21.03.2004.

17 http://www.skladistenje.com/jedan.asp?ID=433, 14.05.2008.

Časopisi i članci

18 Klepac, G., Mršić, L., Poslovna inteligencija kroz poslovne slučajeve, Lider Press, Tim Press, Zagreb, 2006.

19 Panian, Ž., Klepac, G., Poslovna inteligencija, Masmedia, Zagreb, 2003.

20 ALFATEC Group: Projekti poslovne inteligencije

21 ALFATEC Group: Menadžment izvještajni sustav, Business Objects

Podaci o autoru:

Boris Draženovi ć, mr.sc. HELIOS Vienna Insurance Group d.d. Voditelj Odjela IT infrastrukture HR-Zagreb, Poljička 5 e-mail: [email protected] Roñen sam u Zagrebu 1958. godine. Diplomirao sam na Fakultetu strojarstva i brodogradnje Sveučilišta u Zagrebu, smjer Automatika, 1982. Magistrirao na istom fakultetu 1993., znanstveno područje Ekspertni sustavi i umjetna inteligencija. Nakon uspostave radnog odnosa, pa do danas obavljao sam slijedeće poslove:

• poslovi tehnološkog direktora u tvornici 'Gramip' u Dubravi kod Vrbovca (1982.-1984.) • direktor informatike u PCP Čazmatrans d.d. Čazma od 1989. do kraja 1999.

o Sudjelovao u uspostavi centralne računalne obrade podataka za sve lokacije poduzeća u RH o Uveo u svakodnevni rad 4GL alate i relacijske baze podataka o Osmislio, realizirao i uveo u svakodnevni rad ekspertni sustav za gospodarenje rezervnih dijelova za

cjelokupan vozni park poduzeća na svim lokacijama u Hrvatskoj. • početkom 2000. zapošljavam se u Financijskoj agenciji Zagreb (FINA)

o Sudionik sam nekoliko značajnih projekata u FINA-i (uvoñenje meñubankovnog platnog prometa – NKS, reforma sustava mirovinskog osiguranja – REGOS)

o Jedan sam od voditelja uvoñenja ECDL računalne diplome i testnih centara u Hrvatskoj o Sudjelujem u uspostavi Službe za voñenje projekata u FINA-i


o Od 2005. do 2008. godine bio sam voditelj projekta sreñivanja zemljišnih knjiga i katastra u Republici Hrvatskoj (ZIK)

o Voditelj projekta uspostave integralnog sustava kadrovske evidencije i obračuna plaća (FINA-KOP), te o Voditelj projekta uspostave SAP sustava u FINA-i (projekt FINA-SAP, 7 modula SAP-a).

• od listopada 2008. zapošljavam se u Osiguranju HELIOS Vienna Insurance Group na mjestu Voditelja Odjela informacijskih tehnologija

o Odradio sam uspostavu Odjela informatike u skladu sa pravilima rada multinacionalnih tvrtki o Početkom 2010. radim na uvoñenju SAP poslovnog sustava (moduli FI i CO) o Obavljam uvoñenje novog sustava obračuna plaća o Uspostavljam web prodaju neživotnih osiguranja o Bio sam voditelj projekta VIG-WAN (računalno komunikacijsko povezivanje svih kćeri firmi VIG-a u

Republici Hrvatskoj sa centralom u Beču) o Sudjelujem u projektu uspostave Data Centra za VIG u Republici Hrvatskoj o Početkom 2010. godine voditelj sam projekta uspostave vlastitog DW/BI sustava za potrebe svih vrsta

osiguranja u HELIOS VIG. Od ostalih aktivnosti mogu istaknuti:

• Bio sam osnivač i prvi predsjednik Udruge korisnika Progress razvojnih alata i baze podataka (HrPUG) pri Hrvatskom informatičkom zboru (HIZ)

• Bio sam osnivač i prvi predsjednik Udruge testnih centara u Republici Hrvatskoj za Europsku računalnu diplomu (HrECDL)

• Trenutno sam predsjednik Udruge korisnika SAP-a u Republici Hrvatskoj (HrUSKo) • Dugogodišni sam član Udruge za projektni menadžment (PMI Chapter Croatia) • Bio sam sudionik nekoliko meñunarodnih konferencija i skupova na temu upravljanja projektima • U dva navrata primio sam Plaketu informatika od strane Hrvatskog informatičkog zbora za osobiti razvoj u

informatičkoj djelatnosti u Hrvatskoj. I graduated on the Faculty of Mechanical Engineering, University of Zagreb, Department Automation, 1982. I finished Master of Science at the same university 1993rd, scientific field Expert systems and Artificial intelligence. After establishment of working relationships until today I performed the following tasks: - business of technology director at the factory 'GRAMIP' in Dubrava near Vrbovec (1982nd-1984th) - Director of Informatics PCP Čazmatrans Čazma d.d since 1989. to the end of 1999. year - early 2000. year employment in Financial Agency in Zagreb (FINA). I am participant of several significant projects in the FINA (the introduction of interbank payments - project NKS, reform the pension system - project REGOS). I am one of the leaders of the introduction of ECDL Computer Driving Licence in Croatia. Participate in establishing services for project management at FINA. Since 2005. to 2008. I was the project manager for putting the land registry and cadastre in Croatia (project ZIK), the project manager to establish integral system of personnel records and payroll (project FINA-KOP), and the project manager for establish a SAP system in the FINA (project FINA-SAP). - from October 2008. be employed in the insurance HELIOS Vienna Insurance Group, on position head of the Department of Information Technology - I was the founder and first president of the Association of Users Progress development tools and databases (HrPUG) at the Croatian Information Technology Society (CITS) - I was the founder and first president of test centers in the Republic of Croatia for European Computer Driving Licence (ECDL) - currently I am president of SAP users in the Republic of Croatia (HrUSKO) - long year i am a member of the Association for Project Management (PMI Chapter Croatia) - I was a participant of several international conferences and meetings related to project management. Martina Draženovi ć, prof. e-mail: [email protected] Diplomirala, prva u generaciji, filozofiju i informacijske znanosti na Filozofskom fakultetu Sveučilišta u Zagrebu 2008. godine Polaznik poslijediplomskog doktorskog studija informacijskih znanosti (Filozofski fakultet u Zagrebu) od 2009. godine Dosadašnje radno iskustvo: • AON d.o.o. agencija za posredovanje u osiguranju • Osnovna škola K.Š.Gjalski, Zabok (profesorica informatike) • Srednja škola Ivan Švear, Ivanić Grad (profesorica informatike i matematike) • Osnovna škola J. Bana Jelačića, Podsused (profesorica informatike) Od ostalih aktivnosti mogu istaknuti: • predložena za Rektorovu nagradu za rad na sinergiji tehnološkog i humanističkog u području istraživanja umjetnih neuronskih mreža (prijedlog Odsjeka za informacijske znanosti s Filozofskog fakulteta u Zagrebu) 2008. • prezentacija rada na Simpoziju filozofije na Filozofskom fakultetu u Zagrebu (Kultura medija) 2005. • prezentacija rada na Simpoziju filozofije na Filozofskom fakultetu u Zagrebu (Čovjek-tjelesno ili duhovno biće) 2006. Dodatne aktivnosti (suradnja na projektima): • Istraživanje umjetne inteligencije i njenog utjecaja na svijet • Istraživanje organizacije znanja • Istraživanje odreñenih grana psihologije


HIJERARHIJSKI PRIKAZ SHEME BAZE PODATAKA KAO TEMELJ ZA PRETRAŽIVANJE, RUDARENJE I OLAP

HIERARCHICAL VIEW OF DATABASE SCHEMA AS A BASIS FOR SEARCHING, MINING AND OLAP

mr.sc. Marin Kaluža, Dino Abazovi ć

SAŽETAK:

Poduzeća često posjeduju programska rješenja koja im služe kao ICT podrška u obavljanju svakodnevnih poslovnih aktivnosti – informacijski sustav (IS). IS obavlja poslove skladištenja podataka i njihovo korištenje u smislu standardiziranog izvještavanja. Promatrajući transakcijsku razinu, IS podržava sve potrebne vrste ažuriranja (skladištenja) podatkovnog sadržaja. Korisnik nekada želi nestandardizirane informacije iz svog poslovnog sustava. Implementacija analitičkih aktivnosti na sustav (OLAP), zahtjeva umijeće čitanja sheme baze podataka i poznavanje postupaka čitanja podataka (SQL).

Kako korisnik „gleda“ na podatke u svom sustavu? Moguće je korisniku ponuditi standardizirani pogled na sve podatke iz baze podataka njegovog IS-a.

Standardizacija prikaza podatkovnog sadržaja olakšava razumijevanje odnosa meñu podacima i postupke pretraživanja podatkovnog sadržaja, stvaranjem ad-hoc upita.

Pokazat će se postupak transformacije relacijskog modela u hijerarhijsko stablo temeljeno na osnovnim pojavama (dokumentima) u sustavu.

ABSTRACT:

Companies usually have software solutions as ICT support, when conducting everyday business activities - information system (IS). An IS performs data storage, and use in terms of standardized reporting. On the transactional level, the IS supports all update and storage types of data content. The user sometimes wants non-standardized information from his IS. Implementation of analytical activities (OLAP), requires knowledge of reading the database schema and knowledge of data reading methods (SQL).

How the user "looks" on data in his system? It is possible to provide a standardized view of all data in a database.

The standardization of data content view, facilitates understanding of the relationship between data, nd facilitates data searching activities, by creating ad-hoc queries.

The transformation process of the relational model will be shown. A relational model can be transformed in hierarchical structure based on the basic properties (the documents) in the system.

1. UVOD

ICT podrška u poslovnom sustavu najčešće podrazumijeva korištenje integralnog programskog rješenja u svakodnevnim poslovnim aktivnostima. Programsko rješenje koje je potpuno prilagoñeno poslovnom sustavu predstavlja dio njegovog informacijskog sustava (IS). Programsko rješenje je usklañeno sa procesnom logikom za obavljanje nekog poslovnog dogañaja. Svaki podsustav sastoji se od odreñene količine paralelnih procesa i serijskih podprocesa. Pisajući procesi dobivaju odreñene podatke i skladište ih. Čitajući procesi čitaju podatkovni sadržaj i u odreñenoj (definiranoj) formi distribuiraju podatke primatelju. Sukladno tomu IS posjeduje programsko rješenje koje može čitati podatkovni sadržaj u smislu pregleda ili izvješća, ili ažurirati ga u smislu formi za unos izmjenu i brisanje.

Napredniji korisnici IS-a žele više informacija iz podataka koje skladište IS-om. Kako programsko rješenje treba biti usklañeno sa procesima poslovnog sustava, tako je isto moguće i podatke poslovnog sustava pokazati na razumljiviji način korisniku. To mu treba omogućiti lakši

„ad-hoc“ uvid u podatkovni sadržaj. Korisniku je to potrebno, da bi mogao lakše: � dohvatiti elementarne podatke o nekoj pojavi,

grupirati, pobrojati i sl � analizirati vrijednosti elementarnih podataka i

ustanoviti nove meñu zavisnosti podataka, stvoriti novu informaciju

� pripremati podatke za analizu, izvršavati statističke obrade

Radom će se pokazati kako je moguće prezentirati podatkovni sadržaj korisniku na dovoljno jednostavan način. Pokazat će se algoritam kako transformirati prikaz relacijskog modela podataka u stablastu strukturu koristeći vrijednosti nekih konstruktora u relacijskoj bazi podataka.

2. POTREBE ZA TRANSFORMACIJOM POGLEDA

Shema baze podataka je skup meta podataka koji opisuju strukturu baze podataka. Odnosi se na raspored kojim su podaci organizirani kroz tablice i njihove veze


[5]. U pogledu razumijevanja sustava, takve strukture nisu pogodne za krajnje korisnike za pretraživanje ili analiziranje. Najveći nedostatak takvog prikaza je linearnost prezentirana kroz skup meta podatka. Takva linearnost ne sadrži nikakve dodatne informacije o tijekovima čitajućih procesa. Hijerarhijski prikaz sheme baze bitno pojednostavljuje razumijevanje sustava, jer relacijsku bazu (u minimalno 3NF+BCNF) prikazuje u razumljivijoj – stablastoj formi. Takva stablasta forma pruža dodatne informacije o shemi. Isto tako uvelike olakšava pretraživanje baze podataka i tumačenje sheme prilikom dobivanja dodatnih informacija iz sustava.

Pretraživanje baze podataka odnosi se na dobivanje željenih informacija iz baze podataka definiranjem pojmova ili izraza koji su sastavni dijelovi upita pretraživanja [8]. Upit omogućuje korisniku da izravno pretražuje poslovnu bazu podataka, te tako pronañe npr. potreban proizvod, uslugu, ili drugu potrebnu informaciju. Pretraživanje je prvi korak prema dobivanju tražene informacije i na kraju realizacije posla. Da bi pretraživanje bilo što učinkovitije i brže potrebno je što kvalitetnije definirati upit. Samo definiranje i kreiranje takvih upita u praksi često može biti vrlo komplicirano i iziskuje veliku količinu vremena. Brže i kvalitetnije definiranje upita dolazi iz samog razumijevanja sheme baze podatka. Hijerarhijskim prikazom sheme baze podataka sustav možemo tumačiti jednostavnije i efikasnije.

Rudarenje podataka ili podatkovno rudarenje (engl. Data mining) je način sortiranja, organiziranja ili grupiranja velikog broja podataka i izvlačenje relevantnih informacija [4]. Metoda se naziva rudarenje podataka, jer se u velikim količinama podataka traže bitne informacije [3]. Hijerarhijski prikaz sheme uvodi iste prednosti kod rudarenja kao kod pretraživanja baze podataka.

OLAP ili mrežna analitička obrada je tehnologija koja se koristi za organiziranje velikih poslovnih baza podataka i pružanje podrške u poslovnom odlučivanju [7].

Korištenje hijerarhijskog prikaza sheme baze podatka u OLAP-u odnosi se na pripremu meta informacija iz relacijske baze. Takvi pripremljeni podaci mogu se koristiti za stvaranje dijelova skladišta podataka ili pogleda u relacijskoj bazi.

3. VRSTE VEZA U RELACIJSKOM MODELU

Relacijski model podataka posjeduje relacije koje su u nekoj meñusobnoj vezi. U modelu ne postoji niti jedna relacija koja ne sudjeluje u barem jednoj vezi [6]. Veze izmeñu relacija ostvaruju se putem ograničenja vanjskog ključa. Relacija koja ima vanjski ključ je na M strani veze u odnosu na relaciju na koju je taj vanjski ključ referenciran na 1 strani veze.

Slika 1. prikazuje primjer jednog mogućeg dijela modela podataka o studentima. Student treba imati barem 1 kolegij od mogućih ponuñenih kolegija. Student obavezno ima odreñeni status, ali može i ne mora imati mentora na svom diplomskom radu.

U relacijskom modelu razlikuju tri vrste veza koje se ostvaruju vanjskim ključevima:

I. Neuvjetovana veza II. Egzistencijalna veza

III. Identifikacijska veza

Neuvjetovana veza – predstavlja takvu vrstu veze u kojoj relacija koja je na M strani veze sadrži atribut(e) koji ima ograničenje na vrijednost putem vanjskog ključa (FK), ali pritom FK nema ograničenje na NULL vrijednost (not NULL). FK može i ne mora imati vrijednost. Ako je nema tada je, logično, vrijednost NULL. Ako FK ima vrijednost, tada je ona ograničena na set vrijednosti primarnog ključa povezane relacije na 1 strani veze. Na slici 1. vidljivo je da je takva relacija definirana vezom STUDENT - NASTAVNIK u smislu mentora studenta.

Egzistencijalna veza – predstavlja takvu vrstu veze u kojoj relacija koja je na M strani veze ima FK, i pritom FK ima NOT NULL ograničenje. Dakle, red u relaciji (pojava

Slika 1. Model podataka


iz objektivne stvarnosti), može postojati jedino ako FK ima vrijednost. Takav FK i veza vidljiva je na primjeru STUDENT – STATUS slike 1.

Identifikacijska veza – predstavlja takvu vrstu veze u kojoj relacija koja je na M strani veze ima FK, i pritom FK sudjeluje u primarnom ključu PK u relaciji. Vrijednost takvog FK-a takoñer ima not NULL ograničenje, jer niti jedan element PK ne smije imati null vrijednost. Identifikacijsku vezu možemo prepoznati u djelu slike 1.(STUDENT-KOLEGIJI STUDENTA - KOLEGIJI) gdje student mora imati dodijeljen barem jedan kolegiji ili ih može imati više.

Slika 2. dekomponirano pokazuje tri vrste veza: I. Neuvjetovana veza

II. Egzistencijalna veza III. Identifikacijska veza

Neuvjetovana veza. Student može i ne mora imati mentora na diplomskom radu. Neuvjetovana veza može i ne mora djelovati. Ako ne djeluje tada FK obavezno ima vrijednost NULL. Ako veza djeluje, tada FK ima vrijednost koja je obavezno aktivirana u referenciranoj relaciji i pripadnom referenciranom atributu(ima).

Egzistencijalna veza je specifična vrsta Neuvjetovane veze kojom je definirana obaveznost postojanja vrijednosti u FK. Nije dozvoljeno postojanje n-torke (pojave) u relaciji koja nema vrijednost u atributu koji je ograničen vanjskim ključem. Dakle, n-torka može postojati jedino ako postoji vrijednost u referenciranom atributu.

Identifikacijska veza je specifična vrsta Egzistencijalne veze. Referencirana vrijednost Egzistencijalne veze sada se nalazi u jedinstvenom identifikatoru relacije. Dakle, uz postojeća ograničenja FK i not NULL, dodaje se i ograničenje primarnog ključa PK ili drugog jedinstvenog identifikatora SK. Time Identifikacijska veza ima 3 vrste ograničenja: FK, not NULL i (PK i/ili SK).

Iz navedenog vidljivo je da je „najčvršća“ vrsta veze upravo Identifikacijska veza jer sadrži najveći broj meñusobno nezavisnih vrsta ograničenja.

Jedino identifikacijska veza ima dodatno semantičko značenje za relaciju na 1 strani veze (R1). Identifikacijskom vezom pokazuje se pripadnost slabije relacije na M strani veze (R2), relaciji na 1 strani veze (R1). S druge strane, identifikacijska veza iz R1 pokazuje mogućnost dodatnog višestrukog opisivanja R1 podacima koji se nalaze u R2. R1 se može promatrati kao roditelj relacija (RP), a R2 kao dijete relacija (RC). Odnos roditelj – dijete može se pokazati u stablastoj strukturi. Grane u stablu su roditelji RP, a podgrane su djeca RC.

Može postojati druga veza u relacijskom modulu u kojoj je RP već neki postojeći RC iz roditeljskog stabla. U tom slučaju u roditeljskom stablu postojeći RC postat će roditelj i imati svoje podgrane djece.

4. HIJERARHIJSKI PRIKAZ RELACIJSKOG MODELA

U prethodnom poglavlju pokazane su vrste veza i objašnjena je njihova „čvrstoća“ ovisno o broju nezavisnih vrsta ograničenja koja djeluju u svakoj vrsti veze. Pokazano je da će se za transformaciju pogleda na relacijski model u hijerarhijski oblik koristi samo identifikacijske veze.

Svaka relacija predstavlja spremište za odreñenu vrstu pojave iz objektivne stvarnosti. Pojave se mogu poistovjetiti sa dokumentima ili dijelovima dokumenta sustava.

Postoje jednostavni dokumenti i koriste jednu relaciju za spremanje relevantnih podataka. Isto tako, postoje složeni dokumenti kojima je potreban veći broj normaliziranih relacija za spremanje relevantnih podataka.

Složeni dokumenti imaju početnu, matičnu, jaku relaciju u koju se zapisuju različiti podaci koji na dokumentu imaju maksimalno jednu vrijednost. Neki složeni dokumenti imaju u nekim podacima više vrijednosti. Takvi „više vrijednosni“(VV) podaci zapisuju se u slabijim

Slika 2. Vrste veza


relacijama u odnosu na matičnu relaciju dokumenta. Moguće je da VV podaci na dokumentu, po nekoj svojoj pojedinačnoj pojavi, posjeduju svoje VV podatke. Takvi se podaci sada nalaze u dodatno oslabljenoj relaciji u odnosu na trenutnu već slabu relaciju.

Slika 3. prikazuje transformirani izgled relacijskog modela podataka.

Objašnjenje stabla: � Elementi stabla su relacije iz relacijskog modela. � Svaki element (neovisno o njegovoj razini u stablu)

može imati dva oblika: - List – element u stablu koji nema svoje

podelemente, - Grana – element u stablu koji ima svoje

podelemente. � Elementi grane su Identifikacijske veze iz Grane

prema elementu.

Na stablu postoji više temeljnih grana. Temeljne grane predstavljaju glavne pojave sustava. To su početne točke za promatranje stablaste strukture modela podataka.

Grana (G) može imati svoje elemente (E), ako relacija E ima identifikacijsku vezu prema relaciji G. To znači da E ima vanjski ključ (FK) prema G, i pritom taj FK sudjeluje u primarnom ključu u E.

Ako dokument posjeduje VV podatke u slabijoj relaciji, takva slabija relacija je u Identifikacijskoj vezi sa matičnom relacijom dokumenta.

Na temelju samo Identifikacijskih veza moguće je pokazati stablastu (hijerarhijsku) strukturu relacijskog modela.

Stablasta struktura se može sastojati od osnovnih grana koje predstavljaju matične (osnovne) podatke dokumenta, ili generalizirane (grupirane) nad dokumente. Pod grane svake glavne grane predstavljaju Identifikacijski vezane relacije.

5. ALGORITAM TRANSFORMACIJE RM U STABLO

Transformirani stablasti prikaz relacijskog modela moguće je izraditi prema slijedećem algoritmu: 1. Izraditi listu stvaranja (Create Order List - COL) 2. Linerano čitati sve relacije u COL-u

3. Postavljanje relacije u stablo 4. Povrat na korak 2 dok postoji relacija u COL-u koja

nije smještena u stablo

Korak 1

Relacija u bazi stvara se pomoću SQL naredbi. Prilikom stvaranja relacije stvaraju se i sva potrebna ograničenja na vrijednost. To znači da se stvaraju ograničenja primarnog i vanjskih ključeva. Smatra se da je relacija u potpunosti izgrañena na bazi podataka kada su izgrañeni svi njezini atributi i sva potrebna ograničenja na vrijednost atributa. Nije moguće potpuno izgraditi relaciju na bazi ako prethodno nisu izgrañene sve druge relacije koje su referencirane ograničenjima vanjskog ključa. Dakle, da bi se kreirala relacija i sva njezina ograničenja vanjskog ključa, obavezno je postojanje svih referenciranih relacija.

COL lista sortirana je po redoslijedu mogućeg formiranja relacija na bazi podataka.

Stvaranje COL liste, koraci: 1. Stvoriti listu svih relacija iz baze podataka – moguće

je prethodno izvršiti sortiranje liste po npr. abecedi. 2. Provjeriti da li odabrana relacija, kandidat za slijedeći

element u COL listi ima ograničenja vanjskog ključa. Ako da korak 3, inače korak 4

3. Provjeriti da li je relacija na koju pokazuje svaki vanjski ključ odabrane relacije, već postoji u COL listi. Ako ne relacija se u ovom prolasku preskače – korak 5, inače korak 4.

4. Postavljanje relacije na COL listu, izbacivanje iste relacije iz liste svih relacija.

5. Čitati slijedeću relaciju iz liste svih relacija. Ako trenutna relacija nije posljednja relacija na listi, ili je trenutna relacija posljednja na listi i lista svih relacija još nije prazna (postoji još neriješenih relacija u listi svih relacija), povrat na korak 2.

Redoslijed stvaranja relacija na bazi je takav da se najprije stvaraju „jake“ relacije (nemaju FK ograničenja) , pa sve „slabije“ i „slabije“ relacije. Redoslijed je uvjetovan FK ograničenjima.

Korak 3

Ovaj korak treba postaviti relaciju (element) u odgovarajuću granu ili stvoriti novu glavnu granu. Relacija može imati: � Jednu identifikacijsku vezu – relacija koja je u ER

Slika 3. Primjer stablastog prikaza relacijske baze podataka


modelu podataka predstavljena slabijim tipom entiteta

� Dvije identifikacijske veze – relacija koja je u ER modelu podataka poredstavljena agregiranim tipom entiteta

� Tri i više identifikacijskih veza – relacija koja je u ER modelu podataka predstavljena agregiranim tipom entiteta – ternarna veza.

Broj identifikacijskih veza u relaciji odreñuje na koliko će se pozicija u stablu postaviti ta relacija kao element stabla. Relacija postaje element E u grani G, na svakom G koji je referenciran identifikacijskom vezom iz E. Grane mogu biti na različitim razinama u stablu.

Objašnjeni algoritam može prikazati stablo svakog relacijskog modela koji je u 3NF + BCNF. Ako se algoritam transformacije provede na nenormaliziranim modelima podataka, stablo će biti manje duboko razgranato (imat će manji doseg), ali će pritom imati veći broj temeljnih grana – bit će široko razgranato (veći opseg).

6. PRIMJER STABLASTOG PRIKAZA RELACIJSKOG MODELA

Na slici 4. pokazana je stablasta struktura relacijskog modela podataka StudIS sustava, gdje je hijerarhija postavljena na temelju identifikacijskih 1 prema M veza. Vidi se da se podatkovni sustav sastoji od nekoliko temeljnih tipova pojava kao npr: AKGOD (Akademska godina), PRIJAVE (Prijave kandidata na natječaj, DVORANA (Dvorane visokog učilišta), KOLEGIJI (Kolegiji koji se izvode), STUDENTI (Studenti visokog učilišta), itd.

Temeljni tipovi pojava su osnovni podaci u poslovnom sustavu oko kojih se izvršava poslovna aktivnost. Svaka odvojena grana kao temeljna pojava sustava može biti

više ili manje složena (više ili manje razgranata). Stablo pokazuje koliko se detaljno odreñena temeljna pojava podatkovno opisuje.

Svaka temeljna pojava sadrži opisna svojstva u svojim atributima. Svaki atribut opisuje maksimalno jednu vrijednost, dakle odreñeno svojstvo temeljne pojave moguće je opisati pomoću samo jedne vrijednosti.

Niže grane u stablu povezane na temeljno svojstvo omogućuju dodatno, detaljnije opisivanje nekog svojstva pomoću više kontroliranih vrijednosti. Jedna osobina temeljne pojave može se detaljnije opisati pomoću više različitih, dodatno kategoriziranih, vrijednosti. Npr. iz stabla se vidi da se o temeljnoj pojavi GODSTUD (Godina studija) svojstvo AKGSCIJ (Cjenik studija) može opisati pomoću više vrijednosti. S druge strane vidi se da se svojstvo pojave ISPITI može višestruko opisati sa ISPDPRAK (Dvorana za praktični dio Ispita), ISPDPIS (Dvorana za pismeni dio ispita), ISPSTU (Studenti na ispitnom roku), ISPPROF (Nastavnici ispitivači ispitnog roka). Ili, podaci o pojavi STUDENTI detaljnije se opisuje sa svojstvima: ISPSTU (Izlazak na ispit); STUGOD (Studentove akademske godine studiranja); STGRSTU (Članstvo u grupi).

Neki elementi početnog stabla nisu finalni listovi, nego su grane i imaju svoje elemente. Takvi elementi još detaljnije opisuju novo podsvojstvo. Npr. STGKOL (Kolegiji studenta) prikazuje kolegije koje je student upisao u svaku akademsku godinu (STUGOD) svog studiranja.

Korisnik može brzo vidjeti o kojim temeljnim tipovima pojava ima podatke i u kojem smjeru se detaljizira odreñeno svojstvo temeljne pojavnosti stvarajući stablasti doseg pojave. Korisnik može brže locirati elementarni podatak koji mu je u nekom trenutku pretraživanja potreban. Moguće je stvoriti jasniju sliku o potencijalnim meñuzavisnostima izmeñu podataka.

Slika 4. Stablasti prikaz relacijske baze podataka StudIS sustava


7. ZAKLJU ČAK

Cilj postojanja IS-a nekog poslovnog sustava je ICT podrška osobama (korisnicima) koje obavljaju poslovne aktivnosti. Standardni prikazi podatkovnog sadržaja u obliku prozora sa tzv. data grid ili grid view objektima, ili prikaz u obliku izvješća, koji su danas sastavni dijelovi programskih rješenja, postaju nedostatni korisniku.

Pretraživanje podatkovnog sadržaja može dati nove informacije, koje su korisniku potrebne sa ciljem obavljanja što finije balansiranih poslovnih aktivnosti.

U podatkovnom sadržaju poslovnog sustava postoji i više skrivenih informacija koje su dosadašnjim programskim rješenjima bile nedostupne. Korisnik treba moći jednostavno, brzo i efikasno pretraživati svojstva temeljnih pojava svog poslovnog sustava.

Radom se pokazuje algoritam koji transformira standardni pogled na relacijski model (relacijsku bazu podataka) u oblik stablaste (hijerarhijske) strukture

temeljnih pojava i njezinih „viševrijednih“ svojstava (različito razgranatih elemenata). Algoritam je moguće provesti na shemi relacijske baze podataka poslovnog sustava.

Pokazanim algoritmom želi se omogućiti jednostavan, brz i efikasan pregled na dostupan podatkovni sadržaj i time olakšati proces kompleksnog čitanja i dubinskog analiziranja podatkovnog sadržaja, koje kasnije obavljaju Business Intelligence (BI) programska rješenja.

Algoritmom se olakšava proces pripreme podataka za detaljne, statističke analize koje se provode pomoću OLAP sustava.

Algoritam preuzima informacije iz trenutnog stanja relacijske baze podataka pa samim tim može poslužiti i razvojnim inženjerima u svrhu otkrivanja nedostataka u relacijskom modelu. Isto tako postoji mogućnost uporabe i u svrhu kreiranja dijagrama tijeka procesa ili stabla izbornika informacijskog sustava.

Literatura:

1 Books, LLC , Business Intelligence: Data Warehouse, Sas, Predictive Analytics, Resource-Based View, Competitive Intelligence, Context Analysis, General Books LLC, 2010

2 Gogolla M., An extended entity-relationship model: fundamentals and pragmatics, Springer, 1994

3 Olson D. L., Delen Dursun, Advanced data mining techniques, Springer, 2008.

4 Ruan D., Chen G., Kerre E. E., Wets G., Intelligent data mining: techniques and applications, Birkhäuser, 2005.

5 Singh S. K., Database Systems: Concepts, Design and Applications, Pearson Education India, 2009.

6 Teorey T. J., Lightstone S., Nadeau T., Jagadish H. V. , Database Modeling and Design: Logical Design, Elsevier Inc., 4th ed. 2005.

7 Vercellis C. , Business Intelligence: Data Mining and Optimization for Decision Making, John Wiley and Sons, 2009

Podaci o autorima:

mr.sc. Marin Kaluža Veleučilište u Rijeci Trpimirova 2/V, Rijeka e-mail: [email protected] Obrazovanje: 1999. Filozofski fakultet Sveučilišta u Rijeci – profesor pedagogije i informatike Poslijediplomski studij: 2001. upisan pri Fakultetu organizacije i informatike, Varaždin, Sveučilišta u Zagrebu – informacijske znanosti Doktorat znanosti: u tijeku je postupak stjecanja doktorata na Fakultetu organizacije i informatike, Varaždin Radno iskustvo: 2005. - danas predavač na Veleučilištu u Rijeci 2002. - 2005. Stručni suradnik na Veleučilištu u Rijeci 1998. - 2002. Mapro d.o.o., projektant i programer

Dino Abazovi ć Mapro d.o.o. Bože Vidasa 20, Rijeka


INTEGRACIJA WINDOWS PHONE7 APLIKACIJA S AZURE OBLAK OM PUTEM CSLA.NET POSLOVNE LOGIKE

INTEGRATION OF WINDOWS PHONE 7 APPLICATION WITH AZURE CLOUD USING CSLA.NET BUSINESS LOGIC

mag.inf. Zlatko Stapi ć, Matija Besednik, Ivan Curi ć, Kristijan Kralj, Kristina Samoš ćanec

SAŽETAK:

Funkcionalnost mobilnih aplikacija koje su namijenjene korisniku, kao i funkcionalnost poslovnih mobilnih aplikacija nove generacije u velikoj se mjeri temelji na korištenju resursa i servisa dostupnih na Internetu. Osobito je zanimljivo vidjeti kako je razvoj aplikacija koje su podržane oblakom (engl. cloud) takoñer sve više prisutan u perspektivi mobilnih aplikacija. Ipak, jedna specifična domena u ovom području ostaje značajno nedorañena, a riječ je o arhitekturalnom izdvajanju sloja poslovne logike, te primjeni takvog pristupa u spomenutoj integraciji. Ovaj rad, kao jedan od prvih u struci, prikazuje bitne elemente integracije Windows Phone 7 aplikacija sa oblakom primjenjujući izdvojeni sloj poslovne logike implementirane u CSLA.Net okviru.

ABSTRACT:

The functionalities of mobile applications that are intended to end users and mobile business applications of the new generation are largely based on the use of resources and services available on the Internet. It is particularly interesting to see how is the development of applications that are supported by a cloud also increasingly present in the perspective of mobile applications. However, a specific domain in this area remains a significantly unspecified and unexplored, and it is about the architectural separation of business logic layer aligned with mentioned integration. This work, as one of the first in the field, shows the essential elements of the integration of Windows Phone 7 applications and the cloud backend infrastructure using separated business logic implemented in the CSLA.Net framework.

1. UVOD

Pojavom pametnih telefona (engl. smartphone) i zamahom koji su doživjeli u posljednjih nekoliko godina, razvoj aplikacija za mobilne ureñaje je poprimio jednu posve novu dimenziju. Pametni telefoni su postali dostupni širokom broju korisnika čime se fokus svih vodećih proizvoñača aplikacija za mobilne ureñaje počeo pomicati od razvoja poslovnih aplikacija prema razvoju aplikacija namijenjenih običnim korisnicima i mladima. Aplikacije „zabavnog sadržaja“ kako ih često volimo zvati imaju naglasak na korisničkom sučelju i korisničkom doživljaju (engl. user experience) te posebno na stalnom osvježavanju sadržaja koje se najčešće realizira stalnom vezom prema Internetu.

Budući da s jedne strane, korisnici spomenutih aplikacija postaju sve zahtjevniji po pitanju kvalitete, performansi i funkcionalnosti istih, a s druge strane, korištenje pametnih telefona ne isključuje nego potiče razvoj i poslovnih aplikacija, s pravom možemo zaključiti da je već sada potrebno tražiti nove modele iskorištavanja mogućnosti koje nude pametni telefoni, ali i brzi pristup internetu.

Jedan od takvih modela je svakako i primjena računarstva u oblaku (engl. cloud computing) i razvoj mobilnih aplikacija podržanih ovom novom i prodornom tehnologijom.

Iako je primjena oblaka kao aplikacijskih sustava već u punom zamahu, izuzetno je zanimljivo primijetiti kako većina postojećih mobilnih aplikacija i aplikacija koje su integrirane u oblaku nema arhitekturalno izdvojen sloj poslovne logike, što naravno rezultira smanjenom modularnošću i fleksibilnošću dorade i održavanja istih.

Jedan od rijetkih okvira za razvoj arhitekturalno izdvojenog sloja poslovne logike od slojeva korisničkog sučelja i baze podataka je CSLA.Net okvir razvijen od [3]. Primjena „komponentno bazirane i scalabilne logičke arhitekture“ (engl. Component-based Scalable Logical Architecutre) znači primjenu razvojnog okvira koji pomaže razvoju snažnog i održivog sloja poslovne logike za različite programske proizvode, uključujući i mobilne aplikacije [3]. Ipak, pretraga istraživanja na temu primjene CSLA.Net okvira i infrastrukture oblaka u jednoj aplikaciji nije dala rezultata.

Stoga, ovaj rad prikazuje integraciju WP7 aplikacije i Azure oblaka, ali primjenom CSLA.Net poslovne logike. Sloj poslovne logike je dizajniran na način da iz oblaka iskoristi sve prednosti, uključujući znatne potrebne resurse za obradu nad složenim podatkovnim strukturama, te velikom količinom informacija. S druge strane, spomenuti sloj poslovne logike, podatke pakira i dostavlja aplikaciji na WP7 ureñaju u obliku prikladnom za jednostavan i brz prikaz.

Nakon uvodnog razmatranja, ovaj rad kratko predstavlja Windows Phone 7 platformu, prikazuje detaljno arhitekturu mobilne aplikacije sa izdvojenim slojem poslovne logike, diskutira o primjeni oblaka u razvoju mobilnih aplikacija, te uvodi čitatelja u osnovne koncepte CSLA.Net okvira.

Konačno, rad prikazuje bitne elemente integracije ovakvog sloja poslovne logike s jedne strane na WP7 Silverlight aplikaciju, a s druge strane na infrastrukturu web servisa smještenu u oblaku.


U zaključku autori sumiraju predstavljene koncepte te kratko diskutiraju o prednostima ali i nedostacima ovakve integracije.

Rad će svakako biti interesantan razvojnim inženjerima koji se intenzivno bave razvojem višeslojnih aplikacija, a osobito razvojem višeslojnih mobilnih aplikacija, budući da je poseban fokus dat upravo na kontekst razvoja za mobilne ureñaje.

2. WINDOWS PHONE 7

Windows Phone 7 je novi operacijski sustav za pametne mobilne ureñaje razvijen od strane Microsofta. Da bi proizvoñači mobilnih ureñaja mogli koristiti ovaj OS, Microsoft je u svrhu podizanja razine korisničkog iskustva specificirao i minimalne karakteristike koje svaki ureñaj mora imati [4]. Time je Microsoft lansirajući operacijski sustav WP7 na tržište, stvorio temelje za priključak razvoju aplikacija nove generacije. Naravno, riječ je o aplikacijama koje su prvenstveno namijenjene korisniku, a koje su kako brojna istraživanja pokazuju pojavom pametnih telefona postale izuzetno popularne. Brojne značajke Windows Phone 7 ureñaja, kao što su obavještavanje korisnika putem iniciranih obavijesti (engl. push notification), olakšana navigacija aplikacijom korištenjem panoramnih ili stupčanih stranica (engl. panorama & pivot page), podrška za Bing mape, pamćenje podataka u izoliranom spremniku aplikacije (engl. isolated storage) te posebni alat za dizajn sučelja (Microsoft Expression Blend), omogućuju stvaranje bogatog korisničkog iskustva.

2.1 Arhitektura WP7 aplikacije koja sadrži poslovnu logiku

Kako se operativni sustav Windows Phone 7 ureñaja temelji na Silverlight 3 platformi, tako pruža iznimno dobru podlogu za razvijanje aplikacije korištenjem višeslojne arhitekture (slika 1). Taj pristup nam omogućuje razdvajanje prezentacijskog dijela aplikacije (korisničko sučelje koje sadrži sve nabrojane WP7 značajke) i dijela odgovornog za poslovnu logiku aplikacije što je ključno kada želimo imati mogućnost nadograñivanja i prilagoñavanja korisničkog sučelja.

Sloj poslovne logike sadrži implementaciju poslovnih objekata korištenjem CSLA.NET razvojnog okvira koji implementira njegova svojstva i metode, validaciju i autorizacijska pravila i koristi CSLA WPF (engl. Windows Presentation Foundation) infrastrukturu koja komunicira sa WPF web servisom poslovne logike (engl. Business Logic Web Service). To znači da se dizajneri korisničkog sučelja (engl. UI developers) mogu fokusirati na kreiranje korisničkog sučelja koji će sadržavati bogato korisničko iskustvo povezujući objekte sučelja sa poslovnom logikom. Ostatak programiranja, dakle razvoj poslovne logike, je prepušten programerima.

Poslovna logika, oslanjajući se na CSLA razvojni okvir, obavlja poslove: � validacije korisničkog unosa, � kreiranje izvještaja o prekršenim pravilima sučelju

aplikacije, � autoriziranje korisnika da mogu pristupiti podacima, � komuniciranje sa servisom � ...

Ovakva arhitektura nam dopušta da gradimo visoko modularne sustave koji omogućavaju kreiranje dodataka (engl. plugins) za Windows Phone 7 aplikaciju. Ako Windows Phone 7 aplikacija koristi lokaciju kao jedan od elemenata, potrebno je u razvojno okruženje dodati

klasu koja će simulirati trenutnu lokaciju ureñaja i koja će biti samo tijekom razvoja. Tada se kao dodatak infrastrukturi koristi prilagoñena GPS klasa za objedinjavanje (engl. Global Positioning System Wrapper Class) i GPS simulator da bi simulirali kompleksno kretanje korisnika i scenarije korisničke interakcije. Naravno, ove zadnje dvije spomenute klase se koriste samo kod razvoja sustava, dok u samom produkcijskom okruženju podaci koje dobivamo od njih se zamjenjuju onim pravim, dobivenim od samog Windows Phone 7 ureñaja.

Slika 1. Arhitektura WP7 aplikacije integrirane s CSLA

poslovnom logikom

2.2 Povezanost WP7 i oblaka

Krajem siječnja 2011. godine Microsoft Research su izdali alat za razvoj softvera (engl. SDK – Software Development Kit) pod nazivom „Windows Phone 7 + Cloud Services SDK“ koji će služiti za objedinjavanje dvije Microsoftove nove tehnologije: Windows Phone 7 i Windows Azure [6]. Konkretno, ovaj SDK omogućuje kreiranje Windows Phone 7 aplikacija koje koriste servise koji se pokreću na oblaku (engl. cloud). Na ovaj način mogu se razvijati aplikacije koje će biti proširene dodatnim servisima koji se obavljaju na oblaku, a WP7 ureñaj će postati dijelom terminal. Naime, pri izvršavanju aplikacije koja ima podršku oblaka, korisnik može slati složene upite servisima na oblaku. Ako u tu priču ubacimo i podršku za višezadaćnost (engl. multitasking), koja je najavljena kao jedna od ključnih funkcionalnosti u jednom od slijedećih izdanja WP7 OS-a, dolazimo do platforme koja će zaista u pozadini slati upite, dok korisnik pritom obavlja neke druge operacije. Na taj način, sve operacije obrade upita koje bi se odvijale na WP7 ureñaju i trošile procesorsku snagu i bateriju,


odvijaju se na oblaku, a korisniku se zatim prezentiraju rezultati dobiveni upitom.

Takoñer treba istaknuti da spomenuti SDK služi kao potpora Projektu Hawaii, studentske inicijative za istraživanje kako se servisi koji se zasnivaju na oblaku mogu koristiti da bi poboljšali iskustvo korištenja Windows Phone 7 ureñaja. Njihova trenutna platforma se sastoji od Windows Phone 7 pametnog mobilnog ureñaja i nekoliko servisa na oblaku, kao što su Windows Azure koji služi za proračune i pohranu podataka, Bing mape za servis s mapama i Windows Live ID za identifikaciju korisnika [5].

3. PRIMJENA OBLAKA

Sam pojam računalstvo u oblaku (engl. cloud computing) definirao je Nacionalni Institut za standarde i tehnologiju (NIST) [2]. Definiran je kao model koji omogućava pristup mreži na zahtjev korisnika, točnije pristup računalnim resursima poput pristupa serverima, aplikacijama i servisima. Sama riječ oblak se koristi kao metafora za Internet. Upotrebom oblaka smanjena je potreba za kupnjom novog sklopovlja i programa, a pristup Internetu je preduvjet jer se aplikacijama i dokumentima pristupa putem web preglednika.

Osim toga, NIST je definirao pet ključnih karakteristika računalstva u oblaku [2]: usluge na zahtjev korisnika, širok pristup mreži, udruživanje resursa, elastičnost i servisi koji se mogu mjeriti. Širok mrežni pristup znači da se mogućnosti koje su dostupne putem mreže mogu koristiti uporabom različitih platformi, a te se platforme odnose na prijenosna računala, mobilne ureñaje i slično. Sljedeća karakteristika, brza elastičnost koja označava korištenje usluga od strane klijenata kojemu korištenje tih usluga može izgledati kao da ne postoji nikakvo ograničenje. Ipak, korištene usluge su mjerljive o čemu govori sljedeća karakteristika, odnosno mjerljiva usluga. Klijent može koristiti usluge oblaka kada želi, a jedino što mu je potrebno jest pristup Internetu. Osim toga, resursi se udružuju kako bi se dinamički dodijelili ili uklonili prema zahtjevima korisnika.

Što se tiče računalstva u oblaku, razlikujemo implementacije oblaka i servisne modele oblaka. Oblak može biti implementiran na sljedeće načine [2]: � Privatni oblak – realizacija oblaka koji organizacija

ima za sebe. Može biti kupljen od treće strane ili ga organizacija može sama uspostaviti.

� Zajednički oblak – infrastruktura oblaka koju dijeli par organizacija, te koje imaju zajedničku misiju, viziju, sigurnosne zahtjeve, politiku i sl.

� Javni oblak – oblak koji je u posjedu organizacije koja se bavi prodajom usluga oblaka, te njega koristi šira javnost ili pak velika industrijska grupa

� Hibridni oblak – oblak koji je nastao kao posljedica združivanja dva ili više oblaka, bilo da se radi o privatnom, zajedničkom ili javnom oblaku.

Promatrajući danu definiciju oblaka, te karakteristike računalstva u oblaku, možemo zaključiti da su svi preduvjeti korištenja oblaka od strane aplikacija razvijenih za mobilne ureñaje ispunjeni. Takoñer, nije važno na koji način je oblak implementiran, budući da sve navedene implementacije podrazumijevaju pristup oblaku sa udaljenih računala, što svakako uključuje i mobilne ureñaje.

S druge strane, postoje različiti modeli pružanja usluga u oblaku. Tako prema [2] razlikujemo: � Softver kao servis (engl. SaaS – Software as a

Service)

� Platforma kao servis (engl. PaaS – Platform as a Service)

� Infrastruktura kao servis (engl. Iaas – Infrastructure as a Service)

Ako spomenute modele stavimo u kontekst mobilnih aplikacija, tada možemo zaključiti da već sada, bez posebnih i značajnih dorada, oblake možemo koristiti i na mobilnim ureñajima u obliku SaaS modela, za što je potrebno samo korištenje web preglednika sa odreñenim specifičnim mogućnostima. S druge strane, primjena oblaka u obliku PaaS i IaaS modela na mobilnim ureñajima još uvijek nije dovoljno zaživjela, a ovaj rad ima za cilj prikazati jedno od mogućih načina primjene oblaka na mobilnim ureñajima u obliku PaaS i IaaS modela.

Naravno, treba uzeti u obzir i činjenicu da je korištenje oblaka kao platforme ili infrastrukture uvjetovano i plaćanjem. Kada se usporede troškovi uporabe oblaka i troškovi proizašli iz korištenja vlastite infrastrukture možemo reći da su troškovi korištenja oblaka vrlo mali [7], što prikazuje i tablica 1. Iako postoji više organizacija koje pružaju usluge oblaka, mi ćemo prikazati cijene Microsoftovih usluga budući da smo se odlučili za usluge koje pruža Microsoft [7].

Tablica 1. Cijene Microsoftovih usluga računalstva u oblaku

Resurs Jedinica Cijena u kn Premještanje podataka na

poslužitelj GB 0,52

Premještanje podataka s poslužitelja

GB 0,73

Vrijeme CPU Sati rada CPU 0,65

Pohrana podataka GB mjesečno 0,78

Promatrajući ekonomski aspekt primjene oblaka u svijetu mobilnih aplikacija, te uzimajući u obzir i istraživanja provedena na ovu temu zaključujemo da postoji veliki broj poslovnih scenarija u kojima primjena oblaka umjesto vlastite infrastrukture znatno smanjuje troškove produkcije aplikacije, te ubrzavanja procesa prilagodbe mogućem velikom broju potencijalnih korisnika.

Zaključujući razmatranje o primjeni oblaka u kontekstu mobilnih aplikacija, navest ćemo da postoji velika opravdanost istog, te da na novim platformama kao što je WP7 još uvijek ima dosta nedorečenosti u načinu integracije aplikacija s oblakom, osobito u scenariju smještanja podataka i poslovne logike na oblak, a zadržavanja sloja korisničkog sučelja i same aplikacije na mobilnom ureñaju.

4. CSLA.NET OKVIR

CSLA.NET okvir služi lakšem i bržem razvoju poslovnog sloja aplikacije. Razlog razvoju ovakvog okvira leži u tome što Microsoft .NET sadrži obilje alata i tehnologija za izradu korisničkog sučelja te pristupa podacima, ali jako malo tehnologija za izradu ključnog sloja modularne ili distribuirane aplikacije: sloja poslovne logike.

Razvoj poslovnog okvira je iznimno skup i dugotrajan proces, te se pri izradi velikog broja aplikacija takva arhitektura izbjegava te se aplikacije razvijaju vezanjem izvora podataka direktno na kontrole korisničkog sučelja, ili na poslovni okvir iznimno male funkcionalnosti.


Takva arhitektura sustava pruža malo mogućnosti za ponovnu upotrebu koda te otežava daljnji razvoj i održavanje aplikacije. Još veći problemi javljaju se kod razvoja nove aplikacije, na drugačijoj platformi, gdje se poslovna pravila moraju nanovo implementirati.

CSLA.NET okvir pruža sljedeće funkcionalnosti koje je bez njega potrebno posebno implementirati [3]: � Validacijska pravila implementiraju se unutar samih

poslovnih objekata � Poslovni objekti automatski održavaju listu

prekršenih pravila � Poslovni objekti prate svoje stanje (da li su

mijenjani) � Autorizacijska pravila implementiraju se unutar

objekata te se definiraju na razini objekta i na razini atributa

� Ureñeni odnosi agregacije i kompozicije meñu objektima

� Mogućnost vraćanja stanja objekta uključujući objekte koje sadrži sam objekt čije se stanje vraća

� Jednostavan i apstraktan model za programera korisničkog sučelja

� Puna podrška za povezivanje podataka (engl. Data Binding) u WPF, Windows Forme, Web Forme, Silverlight i Windows Phone 7 sučelja

� Čitanje i spremanje podataka u izvor podataka � Vlastiti sustav autentifikacije

Bitno je napomenuti kako poslovni objekti razvijeni CSLA.NET okvirom zadovoljavaju osnovne koncepte objektno orijentiranog programiranja: apstrakciju, začahurivanje, višeobličnost te nasljeñivanje.

Jedan od najvećih problema kod razvoja suvremenih višeslojnih aplikacija je upravo problem razdvajanja prezentacijskog sloja i sloja poslovne logike. Naime, većinom je riječ o web aplikacijama ili o aplikacijama baziranim na servisno-orijentiranim arhitekturama (engl. SOA – Service Oriented Arhitecture), u kojima se podaci koje korisnik unosi obrañuju na udaljenom aplikacijskom serveru. Problem leži u tome što, kod suvremenih aplikacija, korisnici žele interaktivno sučelje koje će ih odmah izvijestiti o pogreškama u unosu ili prezentirati podatke vezane za njihov unos. Na primjer, kada se korisnik registrira za korištenje naših web stranica, želi vidjeti da li je korisničko ime koje je odabrao već zauzeto ili kada unese željenu lozinku, želi dobiti informaciju o tome koliko je lozinka jaka i da li zadovoljava sigurnosnu politiku našeg sustava (da li zadovoljava postavljene uvjete). Iz tog razloga provjeru korisničkog unosa je potrebno obaviti na strani korisnika. Nadalje, provjeravamo li te podatke isključivo na strani korisnika dobivamo veliki sigurnosni problem: ne možemo garantirati da su podaci koje je server zaprimio valjani te je provjeru valjanosti i vjerodostojnosti potrebno obaviti i na serverskoj strani.

CSLA.NET okvir taj problem rješava korištenjem koncepta mobilnih objekata. Isti objekt koristi se i u klijentskoj aplikaciji i na serveru. Naime, u komunikaciji izmeñu klijentske i serverske aplikacije objekti se serijaliziraju (binarno kodiraju) te se takvi šalju mrežom. Na taj način se uz prijenos samih podataka prenosi i ponašanje samog objekta, njegov globalni kontekst, te podaci o korisniku koji je uputio zahtjev. CSLA.NET okvir sadrži gotovu infrastrukturu za jednostavnu implementaciju i konfiguriranje servisa u .NET-u.

Najveća prednost CSLA.NET okvira leži u tome što je razvijen tako da podržava korištenje u kombinaciji sa generatorima koda. Za razne tipove objekata poslovnog okvira, te za njihova polja i metode, razvijeni su predlošci za generatore koda. Njihovim korištenjem drastično se

smanjuje količina vremena potrebnog za razvoj sloja poslovne logike.

4.1 Način integracije tehnologija

CSLA.NET okvir, uz osnovnu .NET biblioteku, sadrži i biblioteke za Silverlight, WPF i Windows Phone 7. Prostor imena (engl. namespace) jednak je bez obzira na platformu, odnosno biblioteku, koja se koristi kod razvoja poslovne logike. Time je dodatno olakšan razvoj jedinstvenog sloja poslovne logike za aplikacije koje koriste različite tehnologije. Naime, svaka od platformi (Silverlight, ASP.NET i Windows Phone 7) traži korištenje biblioteke prilagoñene toj platformi.

Taj problem rješava se tako da se za svaku platformu kreira biblioteka. Jedna od platformi se odabere kao izvorišna (najčešće .NET platforma) te se za nju generiraju same klase. U ostale biblioteke klase, odnosno datoteke,se dodaju kao veze.

Način implementacije nekih detalja te potrebna funkcionalnost objekta razlikuju se meñu platformama. Na primjer, dio koda za pristup bazi podataka nije potreban u klijentskim aplikacijama već je potreban na aplikacijskom serveru. Taj dio možemo riješiti korištenjem pretprocesorskih naredbi (na primjer #if ASP), ili pisanjem klasa kao djelomičnih (engl. partial) i odvajanjem specifičnosti u zasebne datoteke.

4.2 Specifi čnosti implementacije za Windows Phone 7 platformu

Prva osobina koju svaki poslovni objekt u Windows Phone 7 okruženju mora imati je javni (engl. public) konstruktor bez parametara. Razlog je korištenje refleksije (generičko pozivanje metoda i instanciranje objekata) kod implementacije CSLA.NET okvira. Naime, komunikacija sa serverom se odvija preko četiri osnovne metode CSLA.NET WcfPortal servisa: Create, Fetch, Update i Delete . To su jedine metode koje servis sadrži i generalizirane su za sve objekte koji su implementirani korištenjem CSLA.NET okvira, te se nalaze u poslovnom okviru. Kada se zaprimi zahtjev na serveru, ili odgovor servera u klijentskoj aplikaciji, potrebno je instancirati objekt odreñenog tipa koji je poslan u zahtjevu, odnosno odgovoru. To se obavlja refleksijom. Nažalost Silverlight ne podržava instanciranje objekata koji nemaju javni konstruktor bez parametara. Kako se Windows Phone 7 okruženje temelji na Silverlight-u, potrebno je implementirati javni konstruktor bez parametara te ga je preporučljivo „sakriti“ u editoru kako ga programer korisničkog sučelja ne bi mogao koristiti (za instanciranje objekata koristi se Create() metoda):

[System.ComponentModel.EditorBrowsable(System

.ComponentModel.EditorBrowsableState.Never)]

public MojaKlasa()

{

}

Komunikacija sa servisom u CSLA.NET okviru odvija se preko generičke klase DataPortal<T> koja je implementirana u CSLA.NET okviru. T označava tip poslovnog objekta s kojeg se šalje. Klasa DataPortal odgovorna je za komunikaciju sa WcfPortal servisom spomenutim ranije te se pozivom jedne od njenih metoda odvijaju sve potrebne radnje kako bi se objekt serijalizirao, poslao, deserijalizirao na serveru, pozvala


odgovarajuća metoda, te se na isti način poslao s rezultatom nazad klijentu.

Drugi uvjet koji poslovni objekti moraju zadovoljavati jest da se ranije spomenute metode pozivaju asinkrono. Naime, sinkroni poziv zaključava dretvu dok se ne zaprimi odgovor, dok se kod asinkronog poziva dretva nastavlja, a odgovor se obrañuje preko dogañaja (engl. event).

Budući da Silverlight, a posljedično i Windows Phone 7 platforma, ne podržava sinkrone pozive servisa, potrebno je implementirati asinkrone pozive servisa, to jest DataPortal metodu: -

Public static void GetMojaKlasa(Guid id,

EventHandler<DataPortalResult<MojaKlasa>> callback)

{

var dp = new DataPortal<MojaKlasa>();

dp.FetchCompleted += callback;

dp.BeginFetch(new SingleCriteria <MojaKlasa, Guid>(id));

}

Kao što je vidljivo u primjeru, instancira se DataPortal objekt za specifičnu klasu, EventHandler u parametru se poveže na odgovarajući event te se pozove odgovarajuća metoda parametrima koji su potrebni. Kod asinkronog poziva odgovarajuće metode, potrebno je obraditi odgovor servera:

MojaKlasa.GetMojaKlasa(Csla.ApplicationContex

t.User.Identity.Name, (o, e1) => {

if(e1.Error==null && e1.Object!=null)

{

mojaKlasa = e1.Object;

LbMojaLista.ItemsSource = locations;

}

});

U prethodnom primjeru dohvaćamo podatke za odreñenu klasu prema korisničkom imenu trenutno prijavljenog korisnika. Kao drugi parametar prosljeñujemo lambda izraz u kojem obrañujemo odgovor servera. Provjeravamo da li je upit bio uspješan i u slučaju da jest pridjeljujemo vrijednost rezultata varijabli mojaKlasa tipa MojaKlasa. Zadnji korak je prikazivanje podataka u objektu sučelja LbMojaLista.

Treći uvjet je da se atributi definiraju korištenjem interne strukture podataka CSLA.NET okvira za pohranu podataka, to jest bez korištenja privatnih polja za pohranu. Takav način implementacije atributa je povoljniji za korištenje generatora koda, te zbog ranije opisane refleksije u Silverlightu nije moguće implementirati atribute korištenjem privatnih polja.

Public static readonly PropertyInfo<string>

NameProperty=RegisterProperty<string>(c =>

c.Name, RelationshipTypes.None);

public string Name

{ get

{

Return GetProperty(NameProperty);

}

set {

SetProperty(NameProperty, value);

}

}

4.3 Specifi čnosti implementacije za Azure platformu

Kako je Azure oblak zapravo ASP.NET platforma, implementacija poslovnih objekata nema posebne uvjete već se koriste klasični načini implementacije poslovnih objekata korištenjem CSLA.NET okvira (naravno, kada se radi o integraciji sa Windows Phone 7 platformom, uzimaju se u obzir specifičnosti implementacije za Windows Phone 7 platformu).

Zbog razlika izmeñu ASP.NET i Silverlighta, pa tako i Windows Phone 7 platforme, CSLA.NET okvir sadrži dvije implementacije WcfPortal servisa: jednu za .NET i ASP.NET klijente, drugu za Silverlight i Windows Phone 7 klijente. Kako se radi o integraciji Azure oblaka sa Windows Phone 7 platformom, koristi se Silverlight verzija servisa.

Kako bi smo definirali koja klasa unutar CSLA.Net okvira predstavlja kôd servisa, konfigurirat ćemo WcfPortal.svc datoteku i podesiti servis na sljedeći način:

<%@ ServiceHost language=c# Debug="true" Service="Csla.Server.Hosts.Silverlight.WcfPortal"

CodeBehind="Csla.Server.Hosts.Silverlight.Wc

fPortal" %>

Isto tako, da bi smo konfigurirali krajnju točku našeg WCF servisa, u Web.config datoteci potrebno je napraviti sljedeće bitne promjene i definirati ponašanje web servisa, to jest definirati protokol komuniciranja klijenta i servisa:

1. U element behaviors dodajemo definiciju ponašanja servisa u nepredviñenim (engl. exception) situacijama:

<behavior name="WcfPortalBehavior"> <serviceMetadata httpGetEnabled=

"true"/>

<serviceDebug includeExceptionDetailInFaults=

"true"/>

</behavior>

2. U element services dodajemo definiciju protokola komuniciranja klijenta i servisa:

<service behaviorConfiguration= "WcfPortalBehavior" name=

"Csla.Server.Hosts.Silverlight.

WcfPortal">

<endpoint address="" binding=

"basicHttpBinding" contract=

"Csla.Server.Hosts.Silverlight. IWcfPortal">

<identity>

<dns value="localhost"/>

</identity>

</endpoint> <endpoint address="mex" binding=

"mexHttpBinding" contract=

"IMetadataExchange"/>

</service>

3. U slučaju da koristimo CSLA.Net sustav autentifikacije u element appSettings takoñer dodajemo odgovarajuću definiciju:

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

<add key="CslaAuthentication"

value="Csla" />

Bitno je primijetiti da je sučelje IWcfPortal (implementirano u samom CSLA.NET okviru) ugovor (engl. contract) za naš servis. Dok varijabla name označava ime klase koja pruža kôd u pozadini servisa.


5. ZAKLJU ČAK

Windows Phone 7 je više od samo nove inačice mobilnog operativnog sustava, riječ je o posve novoj platformi koja je fleksibilna, proširiva i s odličnim skupom razvojnih i dizajnerskih alata na raspolaganju. Povezivanje Windows Phone 7 aplikacija i servisa u oblaku je trenutno uobičajena praksa, štoviše takva integracija je i dio arhitekture Windows Phone 7 platforme, jer se iskorištavaju prednosti oblaka što daje aplikaciji bolje performanse i skalabilnost. Oblak se odlično uklapa u strategiju distribuirane platforme i ureñaja s jedne strane, no što se dogaña kada se tu „umiješa“ arhitekturalno izdvojen sloj poslovne logike?

Budući da CSLA implementira poslovnu logiku aplikacije, prednosti i nedostaci koji se odnose općenito na sloj poslovne logike mogu se primijeniti i ovdje. Kao najveću prednost izdvojili bi rasterećenje klijentskog sloja aplikacije, jer CSLA poslovna logika implementira sva poslovna pravila te pristup do baze podataka, te na programeru klijentskog sloja ostaje samo da poziva metode poslovne logike te se brine o kvalitetnom korisničkom sučelju. Ovakav model integracije i pristupa višeslojne aplikacije mogao bi se primijeniti na razvojne timove koji bi imali dizajnere zadužene za cjelokupni klijentski sloj, budući da su rasterećeni programiranja, te mogu iskoristiti sve prednosti Microsoft Expression Blend alata za dizajn korisničkog sučelja.

Poslovna logika može donijeti prednosti kod današnjeg načina upravljanja verzijama aplikacije. Promjena poslovne logike ne znači nužno i promjenu u klijentskom dijelu aplikacije, tako da se promjena poslovne logike može obaviti centralizirano, bez da korisnici aplikacije moraju ažurirati trenutnu verziju aplikacije na Windows Phone 7 ureñaju. Ukoliko s vremenom obrada aplikacije postane spora zbog količine podataka koja se razmjenjuje, može se povećati snaga središnjeg računala odnosno broj instanci Windows Azure oblaka.

To su prednosti koje pruža oblak tehnologija, koja može riješiti nedostatak velikog opterećenja centralnog poslužitelja, te uvelike smanjiti troškove održavanja.

Poslovna logika implementirana putem CSLA okvira postiže visoke rezultate u održavanju koda. Korištenjem alata Code Analysis unutar razvojnog okruženja Visual Studio 2010 dobivaju se izrazito visoki rezultati za održavanje koda CSLA poslovne logike, što potvrñuje kvalitetu samog koncepta [1].

Kao najveći nedostatak ovakve integracije nameće se složeni razvoj poslovne logike na čiji se razvoj mogu utrošiti veliki vremenski i ljudski resursi što naravno generira odreñene troškove. Naravno sve ovisi o namjeni aplikacije i njenoj kompleksnosti. Razvojni tim treba procijeniti dali ima smisla implementirati poslovnu logiku. Scenariji u kojima bi bilo korisno implementirati poslovnu logiku su aplikacije koje imaju zahtjevne izračune poput genetskih algoritama za izračunavanje optimalnih ruta, zatim aplikacije koje upravljaju interakcijom velikog broja korisnika, te ostalo. Današnje mobilne aplikacije su većinom jednostavne, no razvojem mobilnih platformi, sve većim mogućnostima pametnih telefona, te sve većim zahtjevima njihovih korisnika aplikacije će morati pružati nove mogućnosti, a tu je upravo prilika za iskorištenje mogućnosti CSLA poslovne logike.

Ovaj rad pokazuje da je poštivanjem odreñenih bitnih elemenata u pristupu integraciji oblaka i Silverlight Windows Phone 7 aplikacije, a koji su navedeni u ovom radu, moguće iskoristiti sve prednosti izdvajanja poslovne logike u poseban arhitekturalni sloj, koji sve zahtjevne i podatkovno intenzivne operacije izvršava u oblaku. Time se mobilni ureñaj oslobaña značajnog udjela obrade i pohrane podataka, a isti resursi se mogu iskoristiti u poboljšavanje korisničkog sučelja i podizanje razine korisničkog iskustva.

Literatura:

1 Besednik M., Primjena CSLA.NET okvira pri izradi aplikacija, Završni rad, Fakultet organizacije i informatike, Varaždin, 2010.

2 Grance T., Mell P.: The NIST Definition of Cloud Computing, 2011. Izvor: http://csrc.nist.gov/publications/drafts/800-145/Draft-SP-800-145_cloud-definition.pdf (učitano 28.4.2011.)

3 Lhotka, R.: Expert C# 2008 BusinessObjects, Apress, New York, 2009.

4 Microsoft Corp., Minimum Specs for Windows Phone 7, 2011. Izvor: http://www.windowsmobile7.com/minimum-specs-for-windows-phone-7 (učitano 29.4.2011.)

5 Microsoft Corp. Research, Project Hawaii, 2011. Izvor: http://research.microsoft.com/en-us/um/redmond/projects/hawaii/ (učitano:28.4.2011.)

6 Microsoft Corp. Research, Windows Phone 7 + Cloud Services SDK, 2011. Izvor: http://research.microsoft.com/en-us/downloads/0c54f42c-84b1-4ad5-a1b3-37008f3b6bff/default.aspx?tag=mantle_skin;content (učitano: 06.05.2011.)

7 Nacionalni CERT: CloudComputing, 2010. Izvor: http://www.cert.hr/sites/default/files/NCERT-PUBDOC-2010-03-293.pdf (učitano: 11.4.2011.)

Podaci o autorima:

Zlatko Stapi ć, mag. inf. tel: +385 42 390 853 fax: +385 42 213 413 e-mail: [email protected] Zlatko Stapić, mag. inf. je od 2006. godine asistent na Katedri za razvoj informacijskih sustava na Fakultetu organizacije i informatike u Varaždinu, te polaznik poslijediplomskog doktorskog studija Informacijske znanosti na istom fakultetu. Njegova nastavna aktivnost je prvenstveno usmjerena na kolegije koji se odnose na programsko inženjerstvo, analizu i razvoj programa, modeliranje poslovnih procesa i razvoj informacijskih sustava, te značajne napore ulaže u radu sa studentima za što je dobio i posebna priznanja.


Iz znanstvenog i stručnog rada treba izdvojiti višegodišnje voditeljstvo stručnih projekata razvoja programskih proizvoda i sudjelovanje na različitim stručnim i znanstvenim projektima iz područja razvoja, unapreñenja poslovnih procesa, projektnog menadžmenta i slično. U posljednje vrijeme se intenzivno bavi razvojem aplikacija za mobilne ureñaje, što je i predmet njegovog istraživanja u okviru doktorske disertacije, a osobito je vrijedno istaknuti da razvija za skoro sve platforme, uključujući izmeñu ostalog Android, Symbian te Windows Phone 7. Zlatkov detaljniji životopis, s popisom svih radova, projekata i nagrada, te drugih važnih podataka može se pronaći na njegovoj osobnoj web stranici, na http://www.foi.hr/djelatnici/zlatko.stapic. Zlatko Stapić is a young researcher and teaching assistant at the Faculty of Organization and Informatics working at the Information systems development department. His main areas of interests include classic and agile software engineering methodologies, software and information systems development, business processes modeling and others.

Matija Besednik, univ.bacc.inf

e-mail: [email protected]

Matija Besednik, univ.bacc.inf je 2010. godine završio sveučilišni preddiplomski studij Informacijski sustavi na Fakultetu organizacije i informatike u Varaždinu, te je polaznik diplomskog studija Informacijsko i programsko inženjerstvo na istom fakultetu. Njegove glavne aktivnosti su usmjerene na razvoj informacijskih sustava. Područje interesa je razvoj višeslojnih aplikacija s naglaskom na sloj poslovne logike koristeći CSLA.NET razvojni okvir.

Ivan Curi ć, univ.bacc.inf


Ivan Curić, univ.bacc.inf je 2010. godine završio sveučilišni preddiplomski studij Informacijski sustavi na Fakultetu organizacije i informatike u Varaždinu, te je polaznik diplomskog studija Informacijsko i programsko inženjerstvo na istom fakultetu. Njegove glavne aktivnosti su usmjerene na razvoj informacijskih sustava, te na razvoj web aplikacija za što je dobio i odreñena priznanja. Područja razvoja s kojima se intenzivno bavi su .NET platforma za razvoj mobilnih i web aplikacija u Silverlightu, te Java platforma za razvoj web aplikacija. Ivanov detaljan životopis može se pronaći na adresi http://tiny.cc/icuric-cv.

Kristijan Kralj, univ.bacc.inf


Kristijan Kralj, univ.bacc.inf je 2010. godine završio sveučilišni preddiplomski studij, smjer Poslovni sustavi na Fakultetu organizacije i informatike u Varaždinu, te je polaznik diplomskog studija Informacijsko i programsko inženjerstvo na istom fakultetu. Njegove glavne aktivnosti su usmjerene na modeliranje poslovnih procesa i razvoj desktop i web aplikacija. Područja razvoja s kojima se bavi su Microsoft .NET razvojno okruženje za razvoj mobilnih i desktop aplikacija te razvoj web aplikacija u PHP programskom jeziku. Kristijanov detaljni životopis može se pronaći na adresi http://tiny.cc/kkralj-cv.

Kristina Samoš ćanec, univ.bacc.inf


Kristina Samošćanec, univ.bacc.inf je završila sveučilišni preddiplomski studij Informacijski sustavi, na Fakultetu organizacije i informatike, 2010. godine u Varaždinu. Polaznica je prve godine diplomskog studija na Fakultetu organizacije i informatike u Varaždinu, smjer Informacijsko i programsko inženjerstvo. Interesi su joj usmjereni na sigurnost informacijskih sustava, web dizajn, te razvoj web aplikacija, kao i na Java i PHP platforme. Fakultet organizacije i informatike

Pavlinska 2

42000 Varaždin


INFORMATIKA IZ OBLAKA I BAZE PODATAKA – TRENDOVI I OČEKIVANJA

CLOUD COMPUTING AND DATABASES – TRENDS AND EXPECTATIONS

mr.sc. Damir Vuk

SAŽETAK:

Informatika je ovih godina sigurno na velikoj prekretnici. Nikad više podataka - nikad veća potreba za podacima. Sustavi za upravljanje bazama podataka donose nove često zbunjujuće pojmove kao: „Key-Value Store“, „Map-Reduce“, „BigTable“, … S druge strane, klasični RDBMS sustavi su postigli visoku razinu zrelosti. Danas svatko može besplatno instalirati vrlo napredni Open Source DBMS. I „veliki igrači“ takoñer nude besplatne verzije uz relativno malo ograničenja u upotrebi. Potrebe korisnika u vezi analitičkih aplikacija i skladišta podataka, ovi sustavi često mogu dobro i ekonomično pokriti. U kakvoj je to vezi sa trendovima koje donosi informatika iz oblaka?

ABSTRACT:

Nowadays IT is undergoing major changes. Never before so much data, while never a greater need for information. We are facing new often confusing DBMS - concepts: "Key-Value Store", "Map-Reduce", "Big Table", ... On the other hand, traditional RDBMS systems have achieved a high level of maturity. Today, anyone can install a free advanced Open Source DBMS. Also the "big players" offer free DBMS versions with relatively few restrictions on use. This can be a good and costs saving solution for analytic applications and data warehouses. How is all this related to the trends that brings cloud computing?

1. UVOD

Informatika je nekoliko puta doživjela dramatične promjene u smislu nove tehnologije i novih mogućnosti koji iz nje proizlaze, te nove prakse u njenoj primjeni. Te promjene su svaki puta donosile nove koncepte i nove paradigme zasnovane na njima. To je uvijek bilo popraćeno sa u neku ruku pomodnim nazivima (engl. buzzword) za te paradigme koji su uvijek trebali izraziti bit novosti u odnosu na dotadašnju praksu odnosno pristupe. Istina, ti pojmovi su u početku iako brzo prihvaćeni, tumačeni različito a ponekad i nedovoljno jasno. Na prvi pogled se čini da su takve promjene iznenadne. Meñutim, uvijek im prethodi više različitih tehnoloških ili znanstvenih inovacija/otkrića koja se meñusobno nadopunjuju i djeluju sinergijski, a ta sinergija u jednom trenutku svoje zrelosti donosi osjećaj revolucionarnih promjena. Pojava Interneta kao opće svjetske mreže sa svim svojim karakteristikama i servisima, predstavlja jednu takvu prijelomnu točku u kojoj je došla do izražaja sinergija više različitih koncepata, tehnologija, tržišnih mogućnosti/ potreba te ekonomskih, socijalnih, političkih okolnosti. Sve to je proteklom desetljeću dovelo do pojave koja je nazvana „Cloud Computing“ (CC).

Slična „tektonska“ promjena dogodila se osamdesetih godina prošlog stoljeća kroz pojavu osobnih računala kojima je prethodila ključna promjena – pojava mikroprocesora. Informatika nakon toga više nije bila ista. Umjesto skupih, glomaznih, mainframe-računala; jeftina, prilagodljiva i korisnički fokusirana računala postala su dostupna svakome. Mainframe – računala su uskoro počela gubiti na značaju, a osobna računala su otvorila put iznenañujuće brzom razvoju novih segmenta informatičkog tržišta kako hardverskog, tako aplikativno-softverskog. Ovo je predstavljalo impuls odnosno

pozitivnu povratnu vezu za još brži tehnološki razvoj. Ekonomija velikih razmjera se ovdje pokazala na djelu.

Čini se da je ova paralela izmeñu pojave „mikroprocesor – PC“ i pojave „Internet – CC“ vrlo ilustrativna i poučna. Proizvoñači mainframe i mini računala nisu ozbiljno shvatili „opasnost“ od PC. Danas smo svjedoci da su neki od njih nestali sa tržišta računala ili kao tvrtke propali, a neki značajno izgubili na značenju i tržišnom položaju. Npr. Digital druga tvrtka po prihodu u branši (iza IBM-a koji je bio prvi), poznata po vrhunskim mini-kompjutorima i po „potpunom ignoriranju PC“, bankrotirala je desetak godina nakon pojave PC. Univac koji je držao treće mjesto u branši, spojio se sa Boroughs-om u Unisys ali je unatoč toga izgubio značaj. Čak ni IBM kao tvorac PC, nije zadržao svoju vodeću poziciju.

S duge strane, pojavile su se nove zvijezde koje nisu do tada postojale. Microsoft koji nije prije postojao, preuzeo je vodeću poziciju, a Oracle je nastao kao tvrtka na realizaciji teorijske ideje relacijske baze podataka, te je u platformi zasnovanoj na PC-hardveru vidio svoju tržišnu šansu. Zanimljivo je da su tvrtke Microsoft i Oracle svoj tržišni položaj izgradile kao isključivo proizvoñači softvera što je predstavljalo potpuni zaokret u branši. PC hardver je produciran na posve drugačijem konceptu razvoja koji je uključivao modularnost, standardizaciju i specijalizaciju, što je otvorilo do tada nepostojeća tržišta dalekoistočnih proizvoñača PC komponenti.

Čini se da se povijest u ovom smislu ponavlja i u drugim branšama [6]. Tako npr., nije poznato da je u SAD ni jedan proizvoñač kočija postao proizvoñač automobila, a niti jedan proizvoñač parnih lokomotiva nije postao proizvoñač dizel lokomotiva, iako su kočije istisnuli automobili a parne lokomotive su zamijenjene dizel-lokomotivama. Što je tome uzrok? Vjerojatno


nesposobnost da se shvati značaj i šansa nove tehnološko-komercijalne paradigme.

2. INFORMATIKA IZ OBLAKA – STVARNOST KOJA DOLAZI

Upravo je takva situacija danas sa pojavom CC. Primijetimo da i ovdje Google kao vodeći igrač nova zvijezda IT tržišta. Najveća virtualna trgovina i ponuñač CC rješenja i usluga Amazon je takoñer novajlija. Zaključimo da svatko tko ne shvati promjene odnosno prilike i prijetnje koje CC donosi, te ako se tome ne prilagodi, može biti ozbiljno ugrožen. To vrijedi za proizvoñače IT proizvoda i usluga, ali i za korisnike. Prema tome, CC se ne smije ignorirati – on se mora ispravno shvatiti i na njega treba pravovremeno reagirati.

Pojam Cloud Computing se kod nas često prevodi kao „računarstvo iz oblaka“ a označava revolucionarnu paradigmu odnosno promjenu u pogledu mogućnosti, načina, oblika raspoloživosti, distribucije i primjene aplikacija. Budući da je pretežno u SAD pojam computing u neku ruku sinonim (ili barem najbliži) za pojam informatika koji se koristi kod nas, kao i u većini zemalja Europe, smatramo da je prikladniji prijevod „informatika iz oblaka“.

Danas postoji mnogo definicija što je to CC, a još više shvaćanja što taj pojam znači. Unatoč toga, potpuno je jasno da CC predstavlja dramatičnu promjenu. Stoga nije slučajno da Gartner u svom predviñanju deset najznačajnijih strateških tehnoloških trendova u 2011 godini [w3], stavlja na prvo mjesto sveprožimajuću (sveprisutnu) informatiku iz oblaka (Pervasive Cloud Computing).

Oduvijek je postojala težnja da kompjutorski resursi budu kao tržišno dostupna kvantificirana i valorizirana usluga (engl. utility), koja se može dobiti u količini intenzitetu na zahtjev a prema poznatoj cijeni za jedinicu upotrebe. Do pojave CC to je bila samo težnja koja nije nikada u cijelosti mogla biti realizirana.

Najveći problemi u informatičkoj praksi su proizlazili iz relativno visokog investicijskog rizika, po jednoj strani zbog velikih početnih investicijskih ulaganja, te po drugoj strani zbog dugotrajnosti razvojnog procesa odnosno zbog neizvjesnosti povrata uloženog. Ključna novost koju donosi/ omogućuje CC je mogućnost da se na Internetu angažiraju informatički resursi prema trenutnoj potrebi, uz plaćanje/troškove prema količini/vremenu angažiranih resursa. Pri tome je moguće na relativno jednostavan način povećati ili smanjiti angažirane resurse i troškove koji iz toga proizlaze. Resursi mogu biti privatni ili javni u zavisnosti od toga tko ih na tržištu može koristiti. To otvara vrata za pojavu novog, danas vrlo propulzivnog tržišta usluga iz oblaka, a po drugoj strani to je veliki doprinos ublažavanju navedenih problema.

Američki NIST (National Institute of Standards and Technology) definira pojam CC vrlo opširno, te pri tome zahtijeva da CC mora posjedovati slijedeće karakteristike: � Samoposluživanje resursima na zahtjev odnosno

prema potrebi i bez dugog perioda čekanja na promjenu obima i oblika usluge.

� Mrežni pristup resursima preko najrazličitijih vrsta platformi kao što su stolna računala, prijenosna računala, mobilni ureñaji itd.

� Vrlo brzu elastičnost odnosno mogućnost da se gotovo trenutno udovolji vršnim opterećenjima.

� Tarifiranje korištenja usluge - korisnik će platiti onu uslugu koju stvarno troši u odreñenom vremenu i količini.

U literaturi se govori o tri glavne razine informatike iz oblaka: IaaS – Infrastruktura kao usluga, PaaS – Platforma kao usluga, te SaaS – Softver kao usluga. U posljednje vrijeme se govori i o DaaS – baza podataka kao usluga (Database as a Service). Ideja koncepta DaaS je da se korisnicima baze bodataka osigura zaobilaženje velikih troškova sve kompleksnosti koje instalacija i održavanje baze podatka zahtijeva. DaaS nudi mogućnost da se pokrene i koristi vlastita baza po potrebi i prema principima CC odnosno: baza podataka kao usluga.

Prednosti korištenja DaaS mogu biti: � Jednostavnost upotrebe – ne treba voditi brigu o

serverima i ostaloj opremi potrebnoj za pokretanje i izvoñenje baze podataka; ne treba kupovati DBMS i servere.

� Funkcionalnost – u zavisnosti od dobavljača DaaS usluge moguće je odabrati onu funkcionalnost koja najbolje odgovara.

� Aplikacijska integracija – bazu podataka je moguće povezati sa drugim nadopunjujućim uslugama odnosno aplikacijama.

� Upravljanje i održavanje – zbog ekonomije razmjera održavanje i upravljanje bazom podataka koje može biti dio usluge će osigurati niske troškove upotrebe.

DaaS je logična posljedica tehnoloških mogućnosti CC kao i stvarnih potreba korisnika. Ne zaboravimo da je samo pokretanje nekih DBMS nepremostiva poteškoća za neke korisnike jer zahtijeva kako potrebno znanje/stručnjake, tako i velika ulaganja.

3. SUOČAVANJE S PROBLEMIMA U OBLAKU

U praksi CC nudi prilike, ali predstavlja i opasnosti/ probleme o kojima treba osobito voditi računa [1].

Raspoloživost usluge. To je jedan od najznačajnijih razloga za zabrinutost prilikom prelaska na CC. Neke su aplikacije manje osjetljive na privremeni ispad, dok druge nisu. Velike tvrtke si ne mogu dozvoliti da u odreñenim vremenskim razdobljima ne mogu ostvariti uslugu zbog ispada. Nedavni ispad Amazonovog CC servisa ili gubitak mail sadržaja na Google mailu, predstavlja ozbiljno upozorenje i potvrdu da se to može uvijek dogoditi. Alternativni resursi mogu biti na raspolaganju, ali što je sa podacima, pogotovo kod veće količine podataka. Nedostupnost podataka je jednaka nedostupnosti cijele usluge u većini slučajeva složenijih aplikacija. S tim problemom je u vezi osiguranje kontinuiteta usluge u slučaju bilo kakvih problema ponuñača usluge. Korisnik će biti sigurno jako ugrožen ako dobavljač usluge iz bilo kojih razloga prestane davati uslugu. Stoga bi bilo nužno osiguranje kontinuiteta. Cijena duljeg ispada ili trajni gubitak dobavljanja usluge, mogli bi biti prerizični za neke korisnike.

Ovisnost o dobavlja ču usluge. Dok je u klasičnom hardveru / softveru osiguran visok stupanj interoperabilnosti, CC se pretežno zasniva na zatvorenim rješenjima dobavljača CC - usluge. U klasičnim aplikacijama podaci se nalaze u dobro strukturiranim SQL bazama podataka što omogućuje prijelaz sa jednog DBMS-a na drugi, dok je CC daleko od takve usluge. Podaci i programi su često čvrsto povezani i teško prenosivi.


Povjerljivost i dostupnost podataka . Kod mnogih poslovnih podataka tajnost podataka je neizostavan zahtjev. Da li dobavljač usluge može osigurati potrebnu tajnost sadržaja podataka od presudnog je značaja za korisnika usluge. Povjerljivost u CC bi trebala biti na onoj razini na kojoj je u klasičnim aplikacijama odnosno podatkovnim centrima. U nekim zemljama postoje posebni zakoni koji ne dozvoljavaju smještaj odreñenih kategorija poslovnih podataka izvan matične tvrtke ili ne dozvoljavaju fizički smještaj podataka izvan zemlje ili pak zahtijevaju odreñene procedure spremanja i čuvanja podataka. To može biti problem kod CC. Neki su dobavljači CC usluge u tome fleksibilni tako da dozvoljavaju korisnicima izbor lokacije gdje će biti podaci smješteni. Primjer: Amazon.

Usko grlo kod prijenosa podataka . Današnje aplikacije su sve više podatkovno intenzivne, a u budućnosti će se taj trend nastaviti. Premještanje velikih količina podataka ne samo da košta značajan iznos, nego i može trajati nerazumno dugo – npr. danima ili tjednima. Propusnost mrežne opreme i komunikacijskih linija će rasti u budućnosti, ali danas može biti ozbiljan problem.

Nepredvidivost brzine izvo ñenja . Unatoč koncepta elastičnosti, CC usluga ne mora u svakom trenu udovoljavati zahtjevima. Opterećenje može imati nepredvidive vršne vrijednosti. Ako se u takvim situacijama zahtijeva usluga, ona neće moći biti pravovremeno izvršena.

Skalabilna eksterna memorija . Jedan od zahtjeva koji se stavlja pred CC je neograničena dostupnost kapaciteta. Budući da dobavljači CC-usluge imaju vlastita (različita) rješenja kako osigurati skalabilnost, onda tu mogu biti i velike razlike u mogućnostima realizacije.

Licenciranje. Zbog politike licenciranja softvera, dobavljači CC usluge nastoje koristiti Open-source softver. Naime vlasnički softver se obično licencira prema broju korisnika što je neprihvatljivo u konceptu skalabilnosti CC.

Kao što vidimo primjena CC ima ozbiljnih ograničenja, meñutim u budućnosti će pod pritiskom tržišta morati naći modele njihova rješenja.

4. OBLAK I BAZA PODATAKA

U svojim počecima CC se zasnivao na specifičnim konceptima spremišta podataka kao surogatu za DBMS. Google, Amazon, Facebook su primijenili vlastita nestandardna rješenja spremanja podataka, tzv. noSQL baze podataka. Pojam noSQL ne označava jedinstven koncept već samo zajednički naziv za niz različitih koncepata i rješenja spremanja podataka. U odnosu na klasične SQL baze podataka to je u velikoj mjeri retrogradni korak. Klasične relacijske/SQL baze su osigurale generičku sličnost odnosno interoperabilnost i ACID kompletnost, dok su se ova CC rješenja vratila u isključivu specifičnost stavljajući ACID zahtjeve u drugi, a skalabilnost u prvi plan.

Na odreñen način, to je dovelo do slične situacije u kojoj su se nalazile baze podataka početkom sedamdesetih godina prošloga stoljeća: svaki je proizvoñač imao svoj koncept , interoperabilnost je bila niska ili nikakva, nije postojao jedinstven teorijski model. ANSI/SPARC preporukom se pokušalo uvesti red u arhitekturu DBMS-a kroz koncept trorazinske sheme (konceptualna, eksterna, interna). Meñutim, stvarno unapreñenje je donio Coddov relacijski model i na njemu u početku djelomično, a kasnije više, zasnovana realizacija prvih

komercijalno raspoloživih relacijskih baza podataka. Iako današnje baze podataka nisu relacijski potpuno vjerne, one su zasnovane na zajedničkim relacijskim korijenima i usmjeravane SQL standardom.

U tom smislu su noSQL baze samo rudimentarni oblik baza podataka, zapravo stovarišta podataka (Datastore). Nedavno se pojavio pokušaj da se teorijski osmisli noSQL model. Erik Meijer i Gavin Bierman su predložili model pod nazivom: „Co-Relational Model of Data for Large Shared Data Banks“ [2].

Oni pokazuju da je taj model dual Coddovom relacijskom modelu podataka: „Suprotno uobičajenom shvaćanju, SQL i noSQL su samo dvije strane iste kovanice“. Pritom se pod „ko-relacijskim“ modelom podatka podrazumijeva model zasnovan na konceptu ključ-vrijednost (key-value), što je zapravo samo jedan od više koncepata u noSQL taboru. U modelu se pokušava povezati konceptualna sličnost koncepta ključ-vrijednost sa relacijskim konceptom primarni ključ-strani ključ. Ovdje se takoñer preporučuje coSQL kao jezik koji je dual SQL-u.

Zanimljivo je da oba autora djeluju u Microsoftu, pa se postavlja pitanje u kakvoj će vezi biti Microsoftov razvoj CC u odnosu na taj model. Sjetimo se da je Codd bio istraživač u IBM-u te da je koncept relacijske baze podataka u IBM-u prilično dugo ostao na razini istraživačkog projekta, te nije smatrano da treba na tom modelu razviti komercijalnu verziju DBMS-a.

5. OBLAK I SQL DBMS

Pogrešno bi bilo zaključiti da se SQL baze podataka i CC meñusobno isključuju. Mnoga rješenja, a osobito u „privatnim oblacima“ se baziraju na RDBMS-u. S druge strane, javni oblaci sa izuzetno visokim zahtjevima za skalabilnost i elastičnost koriste u pravilu noSQL modele.

Klasični DBMS nisu bili grañeni za takve zahtjeve. Kod njih skalabilnost mora biti unaprijed planirana i pripremljena, a elastičnost je mala. Zbog toga je kod pristaša novih modela nastao pojam noSQL koji je upravo trebao naglasiti različitosti i meñusobnu isključivost oba koncepta. Kasnije su neki proponenti noSQL modela pokušali „no“ u akronimu NoSQL interpretirati kao „ne samo“ (engl. not only), što bi trebalo značiti da bi oba modela mogla koegzistirati.

Michael Stonebraker , profesor na Sveučilištu Berkely California i jedan od najvećih autoriteta u razvoju RDBMS-a, voña projekta Ingres, a kasnije i Postgres RDBMS-a se suprotstavio tvrdnjama da su SQL baze nespojive sa ekstremnim zahtjevima skalabilnosti i elastičnosti [6]. On je prije nekoliko godina opet okupio tim stručnjaka i investitora i prošle godine izdao na tržište VoltDB RDBMS koji ispunjava zahtjeve koje CC traži, a istovremeno ne negira SQL i relacijski koncept podržavajući u potpunosti ACID zahtjeve.

Prema shvaćanju Stonebrakera, dosadašnji sustavi za upravljanje bazama podataka su prepuni nepotrebnih ograničenja i arhitektonski nisu prilagoñeni novim mogućnostima ali i zahtjevima. Zbog toga su im performanse značajno umanjene, što do pojave CC nije predstavljalo bitnu manu. Voñen tom idejom on je u konstrukciji VoltDB-a izbacio nepotrebna opterećenja i uveo nova arhitektonska rješenja. Kao rezultat je dobio impresivno povećanje performansi nekoliko desetaka puta u odnosu na najbolja komercijalno raspoloživa RDBMS rješenja.

VoltDB je ugodna novost na tržištu jer nudi inovativnu arhitekturu prilagoñenu novim potrebama a zadržava


kvalitetu dobro etabliranog OLTP-a [w7]. Druga njegova bitna značajka je izdanje u dvije verzije: komercijalna i open-source. Pri tome već open-source verzija nudi impresivne performanse.

Microsoft je za svoj DBMS SQL Server uključio proširenje pod nazivom SQL Server Data Services (SSDS). SSDS je prilično sličan Amazonovom SimpleDB-u, ali istovremeno i posjeduje mnoštvo različitosti.

Oracle je izdao tri komponente za korisnike CC: Oracle Database 11g, Oracle Fusion Middleware i Oracle Enterprise Manager. Oracle omogućuje upotrebu Amazonovog „Web Services Elastic Compute Cloud“. Značajno je da Oracle takoñer nudi pomoću Oracle Secure Backup komponente, mogućnost izrade enkriptiranih sigurnosnih kopija podataka u oblaku.

6. ANALITIČKA UPOTREBA PODATAKA IZ OBLAKA

Relacijski sustavi za upravljanje bazama podataka su prvenstveno izgrañeni za OLTP obradu podataka. Integracija podataka je jedan od bitnih problema u današnjoj primjeni IT. Problemi integracije nastaju zbog vremenske diskrepancije u razvoju baza podatka odnosno aplikacija na njima zasnovanih, kao i zbog različitosti izvora podataka. Tvrtke u idealnom slučaju trebaju jedinstveni pogled na cjelokupne podatke iz različitih poslovnih procesa i aplikacija. Skladišta podataka se pojavljuju kao pokušaj rješavanja problema integracije. Podaci u skladištu podataka se ne ažuriraju, oni imaju samo karakteristiku povijesnih fakata. Zbog toga su zahtjevi za skladišta podataka drugačiji od onih u OLTP-bazama podataka – podaci se u njima organiziraju u strukture pogodne za analitičke upite (OLAP). Logično je pitanje koliko je CC pogodan za skladišta podataka.

Signifikantna je činjenica da su već prije spomenutom Gartnerovom u predviñanju deset najznačajnijih strateških tehnoloških trendova u 2011 godini [w3], na treće mjesto stavljene „Analitike slijedeće generacije“ (Next Generation Analytics) koje će se bazirati na: � Sveopćoj umreženosti, � Snažnijim procesorima, � Sofisticiranim mobilnim aplikacijama, � Uključivanju socijalnih mreža u poslovnu

inteligenciju, � Unapreñenju načina pretraživanja podatka, � Upotrebi alata za povezivanje i analitički prikaz

podataka iz više izvora.

To znači da će CC značajno doprinijeti unapreñenju analitičke obrade podatka uključujući tu: poslovnu inteligenciju, rudarenje podataka i izvještavanje.

Primjer analitičke usluge iz oblaka je Vertica [w6]. Vertica Analytic Database for the Cloud omogućuje stvaranje analitičkih aplikacija u oblaku utemeljenih na Amazonovom EC2 i dostupna je za upotrebu tvrtkama svih veličina.

7. BAZE PODATAKA IZVAN OBLAKA

Iako je CC pojava koja neizostavno dolazi velikim koracima, to nikako ne znači da baze podataka izvan oblaka nemaju svoju perspektivu. Po jednoj strani tu su baze koje u vlasništvu IT tvrtki, čiju upotrebu treba kupiti licence. Tvrtke koje su investirale u vlastite podatkovne centre i razvoj aplikacija ili kupovinu ERP sustava, ne mogu preko noći prijeći na CC. Nadalje ograničenja i problemi koje sa sobom nosi CC će natjerati tvrtke da dobro razmisle prije nego što se odluče za prijelaz na CC.

Po drugoj strani, izbor open-source sustava za upravljanje bazama podataka je danas respektabilan u odnosu na komercijalno raspoložive. Bez obzira da li ih koristili za OLTP ili OLAP svrhu, moguće je naći odgovarajući izbor. Uz već prije spomenuti inovativni VoltDB , navest ćemo samo nekoliko najznačajnijih.

PostgreSQL je RDBMS u potpunosti open-source [w5], koji će po repertoaru osobina, SQL kompatibilnosti i performansama zadovoljiti i najzahtjevnije. Ovdje funkcionalnost ima svoju cijenu u zahtjevnijem održavanju.

Ingres je RDBMS čije osobine ju stavljaju rang dobrih kandidata za skladište podataka ali i za OLTP. Postoji u i komercijalnim verzijama.

MySQL je široko upotrebljavan i dobro poznat DBMS, koji zbog Oracle-ovog preuzimanja izaziva odreñeno podozrenje na budućnost njegovog razvoja. Od nedavno se pojavio open-source projekt pod nazivom Maria-DB koji na temeljima MySQL-a verzije 5.0 želi nastaviti razvoj.

Firebird RDBMS je primjer potpuno besplatnog open-source sustava za upravljanje bazom podataka koji je kod nas relativno slabo prisutan, a odlikuje se kvalitetom i praktično nikakvom administracijom [w2]. Ovo zadnje nam se čini vrlo bitnim u nizu aplikacija u manjim tvrtkam kao što je kod nas većinom slučaj. To ipak ne znači da baza ne može podnijeti veliko opterećenje poznate su instalacije sa više od 500 on-line korisnika.

8. ZAKLJU ČAK

Informatika iz oblaka dolazi kao dramatična promjena na IT horizontu. Dolazak je neizbježan, a posljedice su još uvijek nesagledive. Te činjenice se ne mogu i ne smiju ignorirati. Promjene treba shvatiti kao prilike, ali i kao prijetnje. Baze podataka su do sada počivale na relativno zreloj tehnologiji RDBMS-a. Baze u skoroj budućnosti će doživjeti promjene. Najvažnija je promjena mogućnost širokog izbora za specifične potrebe uz razumnu cijenu. Promjene se ne donose samo mogućnost novih tipova OLTP aplikacija, nego i analitičke aplikacije nove generacije zasnovane na oblaku. Open-sorce kao komplementaran koncept CC će unaprijediti i OLTP i OLAP aplikacije baza podataka u oblaku ali i izvan njega.

Literatura:

1 Armbrust M., A. Fox, R. Griffith, A.D. Joseph, R. Katz, A. Konvinsky, G. Lee, D. Patterson, A. Rabkin, I. Stoica and M Zaharia: Above the Clouds: A Berkeley Viev of Cloud Computing, Tecnical Report, UC Berkley Reliable Adaptive Distributed System Laboratory, University of California at Berkeley, 10-feb- 2009.

2 Meijer E,. and Bierman G: A Co-Relational Model of Data for Large Shared Data Banks. Comunication of the ACM, Vol54, No.4, april-2011, pp:49-58.

3 Seeger M: Key-Value stores: a practical overview, Medien Informatik, Stuttgart,2009


4 Singh T and PS Sandhu: Cloud Computing Databases: Latest Trends and Architectural Concepts, World Academy of Science, Engeneering and Technology, No.73, 2011

5 Stonebraker M, Madden S, Abadi D. J., Harizopoulos S., Hachem N, Helland P: The End of an Architectural Era (It’s Time for a Complete Rewrite). VLDB 2007

6 Watson R, Berthon P, L.F. Pitt and G M Zinkham: Electronic Commerce: The Strategic Perspective. 2007 , ISBN:9780030265334

Web izvori: w1. http://nosql-database.org/

w2. http://www.firebirdsql.org/

w3. http://www.gartner.com

w4. http://mariadb.org/

w5. http://www.postgresql.org/

w6. http://www.vertica.com/

w7. http://www.voltdb.com/

Podaci o autoru:

Mr.sc. Damir Vuk Visoka škola za menadžment u turizmu i informatici Trg. Lj. Patačića 3 33000 Virovitica Telefon 033 492 257 e-mail: [email protected] Mr.sc. Damir Vuk je viši predavač na Visokoj školi za menadžment u turizmu i informatici u Virovitici. Područja interesa su mu: konceptualno modeliranje, baze podataka, strateška primjena IT, inteligentni sustavi i algoritmi. Damir Vuk, MSc. Is a senior lecturer at the College of Tourism and Informatics in Virovitica. Areas of interest: conceptual modeling, databases, strategic application of IT, intelligent systems and algorithms.


CLOUD COMPUTING: ŠTO S BAZOM PODATAKA (U OBLACIMA)?

CLOUD COMPUTING: WHAT TO DO WITH THE DATABASE (IN THE CLOUDS)?

Vlatka Davidovi ć, Elvis Kukuljan, mr.sc. Ivan Pogar čić

SAŽETAK:

Za krajnjeg korisnika Cloud computing predstavlja mogućnost udomljavanja infrastrukture, podataka i aplikacija van okvira organizacije. U tom kontekstu se sve više istražuju mogućnosti kao i ograničenja koja cloud sa sobom donosi. Poslovne aplikacije korištene u cloudu promatraju se kao servisi koji se mogu naslanjati na baze podataka kao i na cjelokupnu infrastrukturu koja se takoñer nalazi negdje u cloudu. Podaci koje krajnji korisnik unosi, nalaze se „negdje“ u „nekoj“ bazi podataka. Ukoliko je baza definirana as-a-Service govorimo o Database-as-a-service (DaaS). Pitanje sigurnosti podataka za krajnjeg korisnika vrlo je osjetljivo, kao i pitanje povlačenja granica odgovornosti za vlasništvo nad podacima ili vlasništva nad bazom u slučaju bilo kakvih zahvata. Zbog opsluživanja velikog broja korisnika, pojavljuju se problemi skalabilnosti i performansi, te se sve više razmatraju objektne i NoSQL baze podataka, odnosno reducirani sustavi za upravljanje podacima. U ovom radu će se dati osvrt na probleme baza podataka u cloudu, kao neminovne dijelove aplikativnog poslovnog softvera, kako sa aspekta sigurnosti, tako i sa aspekta modela, a obzirom na sama svojstva clouda kao takvog. Ključne riječi: cloud, database-as-a-service, korisnik, sigurnost, model baze

ABSTRACT:

For end users cloud computing is the ability to accommodate the infrastructure, data and applications outside of its own organization. In this context, more research opportunities and limitations that cloud brings. Business applications used in the cloud can be observed as services that can draw on a database as well as the entire infrastructure which is also located somewhere in the cloud. The data show that the end user, are "somewhere" in "a"database. If the base is defined as-a-Service talking about Database-as-a-Service (Daas). The issue of data security for the end user is very sensitive, and the issue of withdrawal limits for ownership or ownership of the data base in the event of any intervention. Due to handling a large number of users, there are issues of scalability and performance, and is increasingly discussed and NoSQL object database, and reduced data management systems. This paper will give an overview of the problems of databases in the cloud, as inevitable parts of the business application software, both from the aspect of security, as well as from the aspect of the model, and considering the properties of Cloud itself.

1. UVOD

Briga oko sigurnosti podataka, te pristupa podacima u bazi, postaju nužan dio poslovanja kad se prijeñe na udomljavanje podataka u oblaku. Korisnik želi znati da su njegovi podaci u oblaku zaštićeni i dostupni. Pružatelj usluge postavlja pitanje kakvu uslugu treba ponuditi korisniku: na koji način smjestiti korisničke podatke u oblak, odnosno koju bazu koristiti a da odgovara skalabilnosti i distribuiranosti clouda, kako administrirati bazu, te kome dopustiti administriranje. Obje strane zanima tko je u konačnici odgovoran za podatke koji se nalaze u oblaku, a tko za bazu.

Trebalo bi s jedne strane definirati što Cloud computing znači za krajnjeg korisnika, koja su pravila, obaveze, prednosti, te eventualne opasnosti na koje krajnji korisnik može naići pri postavljanju osjetljivih podataka u oblak. S druge strane, teži se takoñer postavljanju jasnih pravila, obaveza i za pružatelja usluge koji se bez jasno definiranih granica mogu naći u neprilici da budu odgovorni ne samo za podatke, nego i za zakonski neregulirane situacije na još neistraženom terenu.

U radu se razmatraju problemi s kojima se korisnici mogu sresti prilikom smještanja podataka u oblak, te pitanje oblika baze s kojim se sreću isporučitelji usluge Database-as-a-service.

2. PODACI U OBLAKU

Cloud computing predstavlja globalni koncept koji kaže da krajnji korisnik može bilo gdje držati svoje podatke, može koristiti bilo koju aplikaciju unutar oblaka i može koristiti bilo koju infrastrukturu i platformu. Kod smještanja podataka u oblak, korisniku nije bitno gdje se ti podaci nalaze, dok god se poštuje: � privatnost podataka, � zaštita od neovlaštenog pristupa, � integritet podataka, � dostupnost, � brz pristup podacima, � ugovorni odnos koji će zakonski regulirati prava i

obaveze i korisnika i pružatelja usluge,

Dakle, osim odabira vrsta usluge koja se traži od oblaka odnosno od pružatelja usluge, kod smještanja svojih podataka u oblak treba analizirati i slijedeće faktore: � Sigurnost - kontrola pristupa podacima i poštovanje

standarda � Sigurnost - fizička sigurnost (i mrežni dio) � Latencija - koliko će udaljenost baze utjecati na

performanse � Standardi - kako se podaci pune u bazu te vade van � Zadržavnje podataka - kako “izvaditi” podatke u

slučaju raskida suradnje


Sigurnost pri kontroli pristupa podacima je jasan zahtjev. Kod baza podataka unutar organizacije zna se tko ima prava pristupa i pod kojim uvjetima. Kada je baza smještena izvan organizacija postaje teže znati tko ima pristup do podataka, te postaje važno kojih standarda sigurnosti podataka se vanjska organizacija pridržava.

Slično je i kod sigurnosti u fizičkom smislu, osim kod mrežnog dijela. Zahtjevi na fizičku sigurnost objekta su jasni i svi bi ih trebali poštovati, no problem nastaje kod fizičke zaštite mreže. Standardno se u mrežnom svijetu koriste DMZ zone, firewall-ovi, IDS sustavi i slično, da bi se osigurala naša mreža od neovlaštenog pristupa. Stavljanjem podataka u oblak dolazimo u situaciju da gotovo bilo tko, pa tako na primjer i naši konkurenti, mogu legalno zakupiti uslugu na istom fizičkom segmentu mreže, što otvara mogućnost pristupa odreñenom djelu naših podataka mimo naše volje.

Latencija može smetati manje ili više. Zavisno o tome gdje se nalaze naši podaci/baze u oblaku i lokaciji korisnika, korištenjem udaljene baze možemo čak i popraviti performanse odnosno odaziv naše aplikacije.

Korisnici mogu zahtijevati da se ne osjeti razlika u radu sa lokalnom bazom ili bazom negdje u oblaku.

Dostupnost podataka u bazi je vezan uz probleme da li korisnik cijelo vrijeme ima mrežni pristup, pri čemu se postavlja pitanje pristupa od strane korisnika, te pristupa prema bazi. Da li će se dogañati zaustavljanja baze radi održavanja, ili postoji način da se bilo kakvi prekidi izbjegnu.

Standardi za punjenje baza su naravno neophodni, da ne bi došli u priliku da moramo razvijati posebnu aplikaciju samo da bi prebacili podatke iz sadašnje baze u bazu u oblaku i obratno, što je pak vezano uz slijedeću točku.

Zadržavanje podataka, odnosno kako biti sigurni da su naši podaci “izvañeni” iz poslužitelja davatelja usluge u slučaju prekida suradnje? Ugovorni odnos bi trebao regulirati prava i obaveze obiju strana. Meñutim, kako možemo biti sigurni da će ugovor biti ispoštovan ako se pružatelj usluga nalazi na nekom drugom mjestu na svijetu?

Što napraviti ako zatražimo aplikativnu uslugu (SaaS) koji pružatelj usluga dogovara s nama, a s drugim pružateljem usluga dogovara uslugu smještanja naših podataka?

Trebalo bi jasno definirati gdje su granice odgovornosti nad podacima, nad bazom, nad aplikacijom, odnosno granice odgovornosti nad pojedinim uslugama.

3. SIGURNOST PODATAKA U OBLAKU

Evolucija Cloud computinga sve više ide u smjeru postavljanja jasno definiranih pravila za korisnike i pružatelje usluge. Obzirom da krajnjim korisnicima neće biti bitno gdje se podaci u cloudu nalaze, može se desiti da su podaci smješteni i u drugoj državi. Cloud "briše" granice izmeñu država, ostavljajući korisnike na nejasnom terenu – što u slučaju krañe podataka, zaključavanja podataka, da li su zakoni drugih država regulirani tako da spriječe neželjene dogañaje, ili su korisnici prepušteni sami sebi. Prepuštanje brige oko sigurnosti osjetljivih podataka provideru koji smješta te podatke unutar cloud platforme moralo bi biti jasno zakonski regulirano. Vlade mnogih zemalja iskazale su želju da upravljaju razvojem digitalizacije unutar njenih fizičkih granica, gdje bi glavno usmjerenje bio dogovor

sa pružateljima usluga oko smještanja servera koji rade s podacima u cloudu.

Tijekom 2010. i 2011. World Economic Forum je donio 8 akcijskih područja za pružatelja cloud usluga, kao i za vladine agencije, te analizirao pitanja krajnjih korisnika. Pitanja uključuju poteškoće korisnika u razumijevanju tko može pristupiti podacima koje oni stave u cloud, kako su ti podaci zaštićeni i kako korisnici mogu biti sigurni da su podaci obrisani onda kada bi to trebali biti.

Područja djelovanja uključuju: � poboljšanje transparentnosti o tome kako su servisi

podržani, tko je odgovoran za što, kako su podaci zaštićeni i koji zakonski sustav se primjenjuje – ovo je kritičan korak prema širim potrebama koje moraju osigurati povjerenje u cloud.

� daljnja istraživanja u smjeru razumijevanja i širenja svijesti o prednostima clouda uz razumijevanje rizika i trenutnih mogućnosti upravljanja rizicima – to će osigurati pomoć u donošenju odluka korisnicima i nadzoru

� olakšavanje interoperabilnosti sustava – omogućiti korisnicima da prilagode vlastita cloud rješenja izmeñu mnogih providera i olakšavanje portabilnosti podataka kako bi se korisnicima smanjio strah od zadržavanja podataka kod pružatelja usluge i strah uprave od nedostatka kompeticije.

� garancija dovoljne mrežne povezanosti kako bi korisnici koji povjeravaju podatke cloudu mogli biti sigurni da će po zahtjevu moći pristupiti podacima

Problemska pitanja: � Vlasništvo nad podacima – lokacija podataka i

zakoni, privatnost i pouzdanost, vlasništvo � Sigurnosna pitanja – interoperabilnost i portabilnost,

pouzdanost, obvezivanje na servis, zrelost � Pitanja poslovnog okruženja – autorizirani pristup,

integritet i dostupnost, gubitak podataka, uništavanje podataka. (WEF, 2011)

4. DATABASE-AS-A-SERVICE

S tehnološke strane, cloud computing je paradigma koja predstavlja okvir za udomljavanje različitih IT usluga van okvira organizacije. IT usluge se mogu smjestiti unutar osnovna 3 nivoa: � Infrastructure-as-a-Service (IaaS) koji osigurava

usluge na najnižem tehnološkom nivou – davanja procesorskih usluga, skladištenja podataka

� Platform-as-a-Service (PaaS) koji osigurava razvojne alate za izgradnju aplikacija

� Software-as-a-Service (SaaS) koji opisuje model korištenja aplikacija na zahtjev

Ovdje ulaze i usluge koje nude smještanje podataka u oblak.

Cloud Storage je model servisa u kojem se korisnicima omogućuje da spremaju svoje podatke u oblak kao da ih spremaju na bilo koji drugi ureñaj. Neki servisi koriste posebne alate ili web browser ali većina omogućava manipulaciju podacima kroz uobičajeni način u korisničkom OS-u.

DaaS odnosno Data-as-a-Service omogućava smještaj podataka u oblaku dok se za pristup koriste lokalne aplikacije. Za razliku od baza podataka, ovim podacima se ne pristupa preko uobičajenog sučelja kao što je npr SQL. Ova usluga je primjenjiva samo za osnovno baratanje i manipulaciju podacima. DaaS je usluga koja se postavlja izmeñu IaaS i PaaS


DBaaS - Database-as-a-Service je najkompleksnije i najmoćnije rješenje za rad i čuvanje podataka u oblaku. DBaaS nudi potpunu funkcionalnost koja se očekuje od moderne baze podataka, te je pristup moguć korištenjem API poziva. Upravljački sloj se nalazi u pozadini i brine se o nadgledanju baze te konfiguriranju iste da bi se postigla optimalna skalabilnost, visoka dostupnost i efektivna upotreba resursa oblaka.

DBaaS možemo gledati i kao podskup SaaS (Software-as-a-Service), koji pokriva pružanje softvera i hardvera za baze podataka kao servis ili uslugu.

Da bi neku uslugu mogli smatrati DBaaS-om mora zadovoljiti slijedeće uvjete: � Usluga mora biti dostupna na zahtjev, bez potrebe

za predinstalacijom softvera ili hardvera � Pružatelj usluge je odgovoran za održavanje baze

Pri odabiru koja će se usluga odabrati, treba uzeti u obzir potrebe i prirodu aplikacije koju korisnici koriste. Je li potreban samo udaljeni smještaj podataka, u kom slučaju može poslužiti i najjednostavniji Cloud storage ili se traže osobine koje daje baza podataka. Da li aplikacija traži ili će tražiti npr. transakcije.

Danas se sve više spominje termin Cloud Database. Taj termin bi se odnosio na baze koje su prilagoñene za smještaj podataka u oblak. Pitanje je kakav oblik baze i DBMS-a odgovara svojstvima clouda.

Baze u oblaku bi trebale odgovarati zahtjevima korisnika i svojstvima clouda.

Neke od osnovnih karakteristika koje bi trebale imati baze u cloudu, koje bi odgovarale korisnikovim zahtjevima i osobinama clouda kao takvog su: � visoka dostupnost � brzina � sigurnost i privatnost � pouzdanost � konzistentnost � skalabilnost � distribuiranost

Od posebne važnosti za korisnike je visoka dostupnost baze. Podaci u bazi trebali bi korisniku biti dostupni u svakom trenutku. Replikacija podataka bi trebala poboljšati pouzdanost, otpornost na greške i dostupnost. Radi povećanja brzine izvršavanja upita ostavljena je mogućnost da se uključi i svojstvo paralelnog izvršavanja.

Baza bi morala biti proširiva i lako nadogradiva - skalabilna. Dodavanje novih resursa bi trebalo poboljšavati performanse, što znači da ulaganja, nadograñivanja i izmjene ne bi smjeli remetiti rad baze. Takoñer bi trebalo sačuvati sigurnost i konzistentnost podataka.

Distribuiranost bi trebala poboljšati performanse baze i osigurati veću dostupnost podacima. Distribuirana baza je skup baza smještenih na više računala u mreži koje se obično prikazuju kao jedna baza. Distribuirani DBMS (DDBMS) je sustav za upravljanje distribuiranim bazama. Distribuirani DBMS je particioniran. Svaka particija se širi preko više čvorova, a korisnik na čvoru može izvoditi lokalne transakcije na particiji. Ukoliko jedan čvor izgubi vezu s ostalima, može se dopustiti funkcioniranje tog čvora, što se naziva "partition tolerance". Baza u tom slučaju normalno nastavlja raditi, jedino se javlja pitanje konzistentnosti podataka, obzirom da svi čvorovi ne "vide" iste podatke.

U razmatranju 2 tipa arhitekture distribuiranih baza – shared-nothing i shared-disk (Cloud Computing & Databases, 2008), autor smatra da je većina današnjih

arhitektura shared-nothing arhitektura. Ona se bazira na podjeli (particioniranju) podataka po serveru – svaki server zasebno bi bio odvojeno skladište podataka. Naime dodavanjem novog servera se ne poboljšavaju performanse (vremenski zbog puno servera koje se mora proći kod pristupa podatku. Predlaže shared-disk baze koje dopuštaju klasterima lservera da koriste jednu kolekciju podataka. Svi podaci su dostupni svim serverima, nema particioniranja podataka, zahtjeva se manje servera, jednostavnije održavanje, visoka dostupnost. Ovaj pristup dopušta skalabilnost koja bi odgovarala svojstvima clouda.

U tom slučaju se niti sve distribuirane baze se ne bi mogle razmatrati kao Cloud baze.

Trebalo bi se takoñer provjeriti koji su krajnji zahtjevi korisnika, jer je moguće da neće sve ove karakteristike koje se razmatraju biti bitne svim korisnicima. Najvjerojatnije će samu prirodu Cloud baza odrediti veličina i priroda informacijskih sustava koje će korisnik koristiti.

5. ODABIR BAZE U OBLAKU

Ovdje ćemo promotriti nekoliko vrsta baza koje bi se mogle razmatrati kao Cloud baze.

Relacijske baze podataka i RDBMS počivaju na transakcijama koje imaju ACID (atomicity, consistency, isolation, durability) svojstva. � Atomnost - transakcija je nedjeljiva, atomična i

izvodi se u komadu. � Dosljednost - svaka transakcija transformira bazu iz

jednog korektnog stanja u drugo korektno stanje. � Izolacija - transakcije se ne smiju sukobljavati i

jedna transakcija ne može vidjeti meñurezultate druge transakcije.

� Postojanost - potvrñena transakcija je trajno napravljena.

U relacijskim DBMS dosljednost je osigurana. Kada je transakcija potvrñena, svi naknadni zahtjevi biti će obaviješteni o toj transakciji i nitko neće vidjeti djelomične rezultate transakcije. DBMS uz transakcije koje imaju ACID svojstva, takoñer osigurava i kontrolu istovremenosti.

Relacijske baze podataka počivaju na strogim principima pa im je prednost: stabilnost i pouzdanost, otpornost na greške, strukturirani jezik za rad sa podacima. Meñutim, u oblaku, ukoliko je potrebno osigurati bazu koja mora biti brza, lako proširiva i nadogradiva, relacijske baze nailaze na problem.

Nedovoljna skalabilnost relacijskog DBMS-a bila je razlog pojave drugačijih mehanizama za upravljanje podacima: NoSQL baza podataka i MapReduce sustava.

Firme poput Google, Tweeter, Facebook, Amazon koje rade s ogromnom količinom podataka kreirale su vlastite tehnologije za spremanje i procesiranje velike količine podataka u cloudu, nastojeći istovremeno održati distribuiranost i skalabilnost baza. Navedene baze nisu relacijske, te ne podržavaju ACID svojstva. Amazon je razvio SimpleDB baziran na key-value principu (K-V baza), a Google BigTable baziranu na MapReduce okviru. Navedene baze, nazvane još i NoSQL baze podataka su zapravo čista spremišta podataka sa vrlo jednostavnim mehanizmima kontrole podataka i transakcija.

NoSQL baze razlikuju se od tradicionalnih relacijskih baza prvenstveno po tome kako rukuju dosljednošću podataka. NoSQL ima dvije opcije za čitanje:


� uvjetno dosljedno čitanje - moguće je da promjene nisu do kraja izvršene u danom trenutku

� dosljedno čitanje (promjene su napravljene i pročitane).

Prema CAP (Brewer's) teoremu kod distribuiranih shared-nothing DBMS moguće je imati samo 2 od 3 karakteristike: dosljednost (svi čvorovi u klasteru vide u istom trenutku točno iste podatke), dostupnost (greška na čvoru ne čini bazu neoperativnom), „partition tolerance“ (čvorovi i dalje mogu funkcionirati iako je komukacija izmeñu njih izgubljena).

NoSQL baze su se prema tom teoremu odrekle konzistentnosti.

K-V baze spremaju podatke u key-value formatu. Fleksibilnost K-V baze se očituje u jednostavnom dodavanju novih zapisa, te jednostavnoj izmjeni strukture tablica. Podaci se repliciraju na različitim čvorovima u slučaju k-v pohrane što osigurava visoku dostupnost podataka. Rad sa podacima u bazi se oslanja na aplikacijsku logiku pa se mora napisati poseban API za izmjenu ili kreiranje podataka. Transakcije su jednostavne (nema kompleksnih transakcija i relacija). Transakcijska semantika podržava: uvjetno kreiranje i brisanje – insert, replace i delete vrijednosti za jedan ili više atributa. Uvjetno kreiranje i brisanje se ovdje koriste za kontrolu istovremenosti kada različiti izvori istovremeno pišu u isti element.

Općenito, NoSQL baze su se pokazale pogodne za spremanje velike količine podataka u distribuiranim sustavima. Mogući nedostatak im je postojanje svojstava DBMS-a, no one svakako nalaze primjenu kod rada sa ogromnom količinom podataka.

Objektno orijentirane baze i OODBMS povezuje objektno orijentirane principe sa sustavom za upravljanje bazom podataka. OODBMS bi trebao moći spremati objekte koji skoro nemaju razlike u odnosu na objekte podržane programskim jezikom. Svaki objekt ima svoj OID (object identifier) koji se koristi za jedinstveno identificiranje odreñenog objekta. OID smješta reference na druge objekte u bazi, ali može uzrokovati problem referencijalnog integriteta ako se objekt izbriše dok drugi objekti još imaju referencu na njegov OID. Objektno orijentirani DBMS u odnosu na relacijski DBMS ima pojednostavljenu manipulaciju podacima, bržu navigaciju i nižu latenciju. Glavna prednost objektnih baza je što nema relacijskih neusklañenosti (impendance mismatch) pa je time i postignuta brzina. Relacijska neusklañenost se često sreće kada se u programu pisanom u oo programskom jeziku koristi relacijska baza. Tada se radi mapiranje objekata ili definicija klasa na neposredan način u tablice u bazi. Primarno svojstvo u oodbms je da se objektima u bazi pristupa transparentno, tako da

interakcija s stalnim objektima se ne razlikuje od interakcije s objektima u memoriji.

Objektno orijentirane baze se ponovo razmatraju u kontekstu rada u cloudu. Osnovna prednost im je brzina, te objektna orijentiranost i DBMS. Meñutim, postoji takoñer nedostatak skalabilnosti i standardiziranog upitnog jezika, te je baza ovisna o specifikaciji objektno orijentiranog jezika.

Sve navedene vrste baza se trenutno koriste u oblaku ili imaju potencijala za korištenje, pa je moguće da ćemo naići na upotrebu različitih tipova, ovisno o zahtjevima korisnika, kao i prirodi aplikacija koje budu koristili.

Prednost NoSQL baza je rad sa ogromnom količinom podataka, brzina i skalabilnost. Prednost relacijske baze je postojanje standarda koji bi olakšao prijenos podataka u slučaju migracija na drugi sustav, što je vrlo bitno za krajnjeg korisnika. Prednost objektnih baza je brzina i jednostavnost rada sa podacima.

6. ZAKLJU ČAK

Cloud computing je, iako baziran na starim principima udaljenog pristupa podacima, ipak uveo jedan nov način razmišljanja, gledan iz šireg konteksta.

Kod ponude usluga udomljavanja podataka, u krajnjem fokusu biti će korisnik kojem se treba osigurati privatnost podataka, zaštita od neovlaštenog pristupa, integritet podataka, dostupnost, brz pristup podacima, gdjegod se oni nalazili, te zakonska regulativa.

Ureñeni dogovori poput definiranja vlasništva nad podacima (lokacija podataka i zakoni, privatnost i pouzdanost, vlasništvo), sigurnosna pitanja (interoperabilnost i portabilnost, pouzdanost, obvezivanje na servis, zrelost ), te pitanja poslovnog okruženja (autorizirani pristup, integritet i dostupnost, gubitak podataka, uništavanje podataka) dati će dodatni poticaj razvoju oblaka.

Koja usluga spremanja podataka u oblak će se nuditi, ovisiti će o zahtjevima korisnika, kao i mogućnostima tehnologije. Pri tome će se birati neka od postojećih rješenja koje pružatelji usluga nude, ili će se najvjerojatnije naći i bolja rješenja, te se postojeći tipovi baza prilagoditi kako bi što više odgovarale zahtjevima korisnika.

U doglednoj budućnosti može se očekivati daljnji razvoj usluge Database-as-a-Service. Usluga bi se s obzirom na sigurnost i količinu podataka mogla nuditi u većim data centrima, bilo da je zakupljuju drugi osiguravatelji usluga ili korisnici direktno.

Literatura:

1 Hogan,M.: Cloud Computing & Databases, ScaleDB Inc., 2008.

2 World Economic Forum: Advancing Cloud Computing: what to do now?, WEF & Accenture, 2011

3 Manger,R.: Baze podataka, Sveučilište u Zagrebu,PMF, 2003.

4 Medak,D. : Baze podataka, Geodetski fakultet Sveučilišta u Zagrebu, 2008

5 http://www.infosysblogs.com/cloudcomputing/2010/05/k-v_store_vs_relational_database_in_cloud_context.html (pristupljeno 11.04.2011)

6 Torres,J.: Concurrency and Transaction Management in an Object Oriented Database, 2003.

7 http://nosqlpedia.com/wiki/Why_cloud_databases (pristupljeno 6.05.2011)

8 http://www.technologyevaluation.com/research/articles/cloud-assets-a-guide-for-smbs-part-1-21983/ (pristupljeno 15.04.2011)


9 http://www.odbms.org/blog/2010/09/object-database-technologies-and-data-management-in-the-cloud/ (pristupljeno 15.04.2011)

10 http://www.service-architecture.com/object-oriented-databases/articles/object-oriented_database_oodbms_definition.html (pristupljeno 2.05.2011)

Podaci o autorima:

Vlatka Davidovi ć Asistent e-mail: [email protected] Elvis Kukuljan Asistent e-mail: [email protected]

mr.sc. Ivan Pogar čić Head of Education Tel. +385 51 673 529 e-mail: [email protected] Ivan Pogarčić je viši predavač na Veleučilištu u Rijeci posljednje tri godine. Profesor je matematike i fizike i magistar informacijskih znanosti. U dvadesetogodišnjoj praksi je radio na izradi aplikativnih rješenja u području gospodarstva u domeni pošte i telekomunikacija (današnjem T-com-u). Autor je gospodarstvene aplikacije „MATPO“ koja je prodajom HT-a migrirana u SAP, službenu aplikaciju DT-a. Razvijajući aplikaciju je prireñivao i materijale za izobrazbu krajnjih korisnika čime je njegova uključenost u različite oblike eNastave datirana još iz tog perioda. Završio je eLearning Akademiju pri CARnet-u, smjer eLearning Management. Autor je i koautor četrdesetak radova objavljenih i prezentiranih na domaćim i meñunarodnim skupovima. Područje interesa: objektno orijentirane tehnologije, izgradnja informacijskih sustava, teorija odlučivanja, eAktivnosti. Ivan Pogarčić has worked as a senior lecturer at the Polytechnics of Rijeka for the past three years. He is a mathematics and physics professor and a master of information science. In his twenty-year long career he has developed ICT applications in the field of economy (post and telecommunications, today's T-com). He is the author of economic aplication „MATPO“ which was transferred to SAP, the official application of DT (Deutsche Telecom), after selling of HT (Hrvatski Telecom). While developing this application he was editing materials for educating end users, which makes his involvement in various forms of eTeaching dating from that period. He finished eLearning Academy at CARNet, course eLearning Management. He is the author and co-author of about forty papers published and presented at domestic and international conferences. Field of interest: object oriented technologies, development of information systems, decision support systems, eActivities Veleučilište u Rijeci Studij informatike, Poslovni odjel Trpimirova 2/V, 51000 Rijeka tel. 051/321-300 fax. 051/211-270, e-mail: [email protected] web: www.veleri.hr


WINDOWS AZURE – RAČUNALSTVO U OBLAKU NA MICROSOFT PLATFORMI

MICROSOFT CLOUD COMPUTING PLATFORM: WINDOWS AZURE

mag. ing. el., Tomislav Bronzin, Dobriša Adamec

SAŽETAK:

Ovo predavanje predstavlja sveobuhvatni uvod u Microsoft Windows Azure platformu, koja predstavlja svojevrsni novi Microsoft "globalni" operativni sustav i donosi niz novih koncepata, kako za razvoj aplikacija na njoj, tako i sa korisničke strane. Namjera autora je približiti čitav niz mogućnosti i servisa koje nudi Microsoft, svim zainteresiranim stranama, od arhitekata rješenja, razvojnim i sistemskim inženjerima, pa do onih koji donose poslovne odluke na temelju kojih se generiraju zahtjevi za realizaciju IT sustava. Ključne riječi: računalstvo u oblaku, Cloud Computing, Windows Azure, Microsoft, platforma, arhitektura

ABSTRACT:

This paper is an introduction in Microsoft Windows Azure platform, new “global” Microsoft operation system. Windows Azure brings a lot of new concepts both in application development and from the user side. Author’s intention is to explain a whole range of new possibilities and services that is offered by Microsoft to architects, developers, system engineers and business decision makers that generates request for implementation of IT systems. Keywords: Cloud Computing, Windows Azure, Microsoft, platform, architecture

1. UVOD

Sve veća globalizacija, te društvena i ekonomska povezanost ljudi s jedne strane, te umreženost računalnih resursa i stanje tehnologije s druge strane doveli su do promijene načina razmišljanja kada se radi o arhitekturi i dostupnosti informacijskih sustava. Iako je u početku ideja o računalstvu u oblaku dočekana s odreñenom dozom skeptičnosti, prvenstveno zbog faktora nepoznavanja o čemu se tu stvarno radi, gore spomenuta globalizacija društva i ekonomije (koja je dovela do svjetske gospodarske krize 2007-2009)* zahtijevali su značajno smanjenje troškova informatičke potpore, ali uz još naglašenije zahtjeve za većom dostupnosti, pouzdanosti i tzv. elastičnosti usluga koje IT pruža.

Iz tog razloga, računalstvo u oblaku je postalo danas dominantni način promišljanja arhitekture, bilo da se radi o tzv. javnom, privatnom ili hibridnom računalnom oblaku.

2. ŠTO JE TO RAČUNALSTVO U OBLAKU (CLOUD COMPUTING)?

Postoji čitav niz definicija što je to računalstvo u oblaku (gotovo svaki proizvoñač ima svoju), no možda jedna od najviše prihvaćenih i najraširenijih je tzv. radna definicija (koja se još uvijek prilagoñava) Nacionalnog instituta za standarde i tehnologije SAD-a† koja (u hrvatskom prijevodu) glasi ovako:

„Računalstvo u oblaku je model (plati koliko koristiš) koji, na zahtjev, omogućuje praktičan pristup, putem

* Global Issues, Global Financial Crisis: http://www.globalissues.org/article/768/global-financial-crisis † USA National Institute of Standards and Technology –NIST, www.nsit.gov

računalne mrežne, skupu konfigurabilnih računalnih resursa (mrežama, poslužiteljima, spremištima podataka, aplikacijama i ostalim uslugama) koje se mogu brzo pripremiti za upotrebu i staviti na raspolaganje, uz minimalan napor ili interakciju davatelja usluga“‡

Prema mišljenju autora, ta definicija dobro opisuje što je to računalstvo u oblaku i samu bit – IT resursi su na raspolaganju, dostupni su, možemo ih zakupiti kada nam trebaju i to sve skupa netko ne mora odraditi nego se automatski stavlja na raspolaganje.

3. EKONOMSKI I PRAKTI ČNI RAZLOZI ZAŠTO NAM TREBA RA ČUNALSTVO U OBLAKU?

3.1 Opis ulaganja u tradicionalne IT sustave

Kod tradicionalnih sustava (Slika 1) opterećenje se obično predviña kao pravac (iscrtano na grafu) koji pokazuje povećanje zahtjeva na resurse kako vrijeme teče. Kako bi zadovoljili potrebu za IT resursima, u tradicionalne sustave se rade ulaganja koja su više diskretne naravi, pa su na grafu prikazana kao stepenice, a koje nastaju, s jedne strane, iz razloga da se predvidi potreba za IT resursima i s druge strane iz činjenice da je potrebno neko vrijeme (proces) da se oprema nabavi, osobito u velikim kompanijama/ organizacijama.

Kao posljedica takve „nabave“ računalnih resursa dolazi do najmanje tri situacije kada je situacija, bilo što se tiče ulaganja ili raspoloživih IT resursa loša, zato što je kod tradicionalnih IT sustava:

‡ Radna definicija računalstva u oblaku US NSIT IT Laboratory: http://www.nist.gov/itl/cloud


1. Potrebno ve će inicijalno ulaganje u IT resurse, nego što nam stvarno u tom trenutku treba a. kako bi predvidjeli buduće opterećenje/zahtjeve

za IT resursima b. na grafu je slikovito to karakterizirano kao

„Nezadovoljan CFO“, odnosno poslovna funkcija koja se bavi financiranjem i kontrolingom – budući tu leži neiskorišteni kapital

2. Mogu ća je situacija kada nedostaje IT resursa a. zbog sporije dinamike nabave, odnosno veće

dinamike poslovanja može se desiti da u jednom trenutku zahtjevi korisnika za IT resursima budu veći od onih koji su trenutno dostupni i onda imamo nezadovoljne korisnike i izvršnog direktora

3. Kada prestane zahtjev za IT resursima – oni se n e mogu „vratiti“ i dalje ostaju kao trošak a. Ako se radi o sezonskim opterećenjima ili

jednostavno padu potrebe za IT resursima – oni ostaju i dalje alocirani i stvaraju troškove – kako amortizacije, tako i za održavanje – bez obzira što nam više ne trebaju

3.2 Opis ulaganja u IT sustave bazirane na računalnom oblaku

Kod IT sustava baziranih na računalnom oblaku (Slika 2)

imamo bolju situaciju kada promatramo potrebu za IT resursima tokom vremena: 1. Potrebno je nisko inicijalno ulaganje u IT resurse

a. radi se obično o tzv. postavljanju (setup) sustava u računalnom oblaku

b. zakupljujemo onoliko IT resursa koliko nam u tom trenutku trebaju

2. Kada nam treba više resursa, jednostavno ih dokupimo a. prema definiciji što je to računalstvo u oblaku –

resurse možemo kupiti i alocirati automatski, bez asistencije pružatelja usluge

3. Kada prestane potreba za odre ñenim dijelom IT resursa, jednostavno ih prestanemo koristiti a. prestankom korištenje – plaćamo manje, a samim

time smo i konkurentniji i „štedimo“ b. kada nam dodatni IT resursi zatrebaju, dostupni

su nam

4. TIPIČNI SCENARIJI ZA RAČUNALSTVO U OBLAKU

Cilj ovog odlomka je da navede 4 najčešće grupe prepoznatljivih scenarija korištenja IT resursa koja su idealna za implementaciju kroz računalstvo u oblaku.

Slika 1 Ulaganje i raspoloživi IT resursi kod tradicionalnih IT sustava

Slika 2 Kod računalstva u oblaku IT resursi su dostupni kada je to potrebno, a plaćamo ih koliko i kada ih koristimo


Naravno da sigurno postoje i neke druge grupe scenarija od kojih neke (možda) nisu pogodne za implementaciju kroz računalstvo u oblaku, barem ne sa današnjim stanjem tehnologije.

4.1 Uklju či i isklju či

Kada postoji (predvidljiva) povremena potreba za IT resursima, onda govorimo o scenariju „Uključi i isključi“.

Kod tradicionalnih IT sustava imamo problem što moramo plaćati troškove svih alociranih IT resursa bez obzira da li ih koristimo, odnosno, ako se radi o povremenoj potrebi za koju nemamo dovoljno IT resursa, može se desiti da nam je potrebno duže vrijeme za njihovu nabavu od idealne.

Kod računalstva u oblaku, IT resurse možemo brzo zakupiti (alocirati) kada su nam potrebi, te kad ih prestanemo koristiti – više za njih ne plaćamo.

Slika 3 Uključi i isključi scenarij

4.2 Brzi rast

Svaka organizacija bi voljela da broj korisnika njihovih usluga raste iz dana u dan. Neki puta se takav rast može desiti jako brzo pa može doći do zagušenja postojećih IT resursa. Naravno, to bi vodilo i do loše usluge, pa stoga je potrebno brzo reagirati i staviti u upotrebu onoliko IT resursa koliko nam je potrebno u čim kraćem vremenu. Dok kod tradicionalnih IT sustava to može biti veliki problem, kod računalstva u oblaku, radi se samo o dodatnom zakupu/alokaciji potrebnih IT resursa.

Slika 4 Scenarij "Brzi rast"

4.3 Nepredvi ñeno optere ćenje

Neki puta nije moguće predvidjeti opterećenje na IT resurse: npr. u slučaju velikog pristupa stranici koja pokazuje vremensku prognozu za neku prirodnu nepogodu koja bi mogla utjecati na veliki broj ljudi. U tom slučaju brzu reakciju može osigurati računalstvo u oblaku jer su IT resursi uvijek dostupni u kratkom vremenskom roku. Isto tako, nakon prestanka opterećenja na IT sustav, jednostavnim prestankom korištenja dodatno alociranih IT resursa prestaje i dodatni trošak.

Slika 5 Scenarij "Nepredviñeno opterećenje"

4.4 Predvidljivo optere ćenje

Kod scenarija poput npr. prodaja karata za koncert popularnog glazbenog sastava, može se predvidjeti dodatno opterećenje od trenutka kada počinje prodaja karata, dok ne završi. U tom scenariju moguće je vrlo povoljno zakupiti dodatne resurse (povoljnije nego kod nepredvidljivog opterećenja).

Slika 6 Scenarij: "Predvidljivo opterećenje"

Kod tradicionalnih sustava, morali bi ih dimenzionirati za „vršna opterećenja“, koja mogu trajati vrlo kratko (bez obzira koliko bila česta) što bi dovelo do neefikasnog ulaganja u IT opremu koja bi veći dio vremena bila neiskorištena.

5. TRI MODELA RAČUNALSTVA U OBLAKU

Uz prethodno navedenu definiciju računalstva u oblaku, postoji i općenita definicija za tri glavna modela, ovisno o karakteru i načinu pružanja usluga: 1 IaaS – Infrastruktura-kao-Servis (Infrastructure-as-

a-Service) 2 PaaS – Platforma-kao-Servis (Platform-as-a-

Service) 3 SaaS – Softver-kao-Servis (Software-as-a-Service)

5.1 Koji model(e) pokriva Windows Azure?

Ne ulazeći u teoriju svakog od tih modela, Windows Azure najbolje odgovara modelu PaaS : 1 Koristi se Windows Azure servisni model za razvoj

aplikacija 2 Aplikativna rješenja zasnovana na Windows Azure

platformi održava njihov proizvoñač-zakupac platforme i servisa (ovdje korisnik!)

3 Operativni sustav i potporne servise osigurava i održava (nadzire i ažurira) pružatelj usluge računalstva u oblaku.

4 Implementacija gotovog IT rješenja ili novih verzija je brza budući je platforma uvijek spremna, kao i dodatni eventualno potrebni resursi


5 Ovakav sustav je pouzdan, otporan na prekide rada i podržava globalnu dostupnost rješenja

6 Nije moguće odabirati i previše mijenjati postavke „operativnog sustava“ i servisa, nego se koriste predefinirane opcije

5.2 Kako koriste ći Windows Azure platformu realizirati IaaS i SaaS?

Kako bi se omogućila čim lakša migracija postojećih (eng. legacy) aplikacija u računalstvo u oblaku, nudi se Windows Azure VM rola (Virtual Machine). Ova opcija: 1 Omogućava organizacijama da koriste sustav sličan

onome koji imaju u svojim informatičkim odjelima – identične poslužiteljske operativne sustave i ostale servise, čak s opcijom integracije putem virtualnih privatnih mreža s IT sustavim „u kući“ (eng. on-premise).

2 Izborom ove opcije, zakupac usluga postaje odgovoran za održavanje (nadzor i ažuriranje) ne samo servisa i aplikacija koje je implementirao na takvom sustavu, nego i za operativni sustav i potporne servise.

3 S druge strane, IaaS daje veću fleksibilnost u podešavanju parametara kako operativnog sustava, tako i vrste i načina rada potpornih servisa

Postoji mogućnost i upotrebe Windows Azure kao SaaS i to na način da: 1 Na Windows Azure se instalira softver i kao takav

ponudi na zakup krajnjim korisnicima 2 Poslovni model može biti da je softver namijenjen

da ga koriste više zakupaca (multi-tenant) ili izolirano za pojedinačne zakupce

3 Ovakav sustav često održavaju tvrtke koje su proizvele softver, tzv. neovisni proizvoñači softvera (Independent Software Vendors – ISV)

4 Obično je kod SaaS modela računalstva u oblaku moguće raditi puno manje prilagodbi od onih koje su dostupne kod PaaS, a pogotovo kod IaaS modela

6. MICROSOFT WINDOWS AZURE PLATFORMA

Windows Azure platforma se sastoji od tri osnovna dijela (ovo je trenutačno stanje, sustav je u razvoju pa se očekuju i proširenja):

1 Windows Azure 2 SQL Azure 3 Windows Azure AppFabric

7. WINDOWS AZURE – GLOBALNI DISTRIBUIRANI OPERATIVNI SUSTAV

Windows Azure je dio platforme koji možemo s punim pravom nazvati novim „globalnim distribuiranim operativnim sustavom“. Tad dio upravlja hardverskim resursima (npr. balansiranjem opterećenja, optimizacijom korištenja spremišta podataka, alokacijom memorije itd.), te servisima kao što je apstrakcija pristupa hardveru kroz programsko sučelje, upravljanje zadacima i njihovo vremensko okidanje, omogućuje nadzor i praćenje performansi pojedinih dijelova sustava, upravlja sigurnošću (pravima pristupa i ovlastima), upravlja cijelim životom aplikacije od njenog učitavanja, rada, pa do završetka života.

Slika 7 servisi u Windows Azure

Windows Azure se sastoji od slijedećih servisa (Slika 7): 1 Windows Azure Fabric i Fabric Controller 2 Windows Azure Compute 3 Windows Azure Storage

7.1 Windows Azure: „Fabric Controller“ servis

„Fabric controller“ automatizira upravljanje funkcijama kao što su balansiranje opterećenjem i izračunava potrebne resurse za rad. Kao što mu u prijevodu i ime govori „fabric“ – tkanje – on prožima čitav sustav Windows Azure.

Sve Windows Azure aplikacije i podaci u Windows Azure Storage su smješteni u jednom od Microsoftovih

Slika 8 shema rada Fabric Controller-a


podatkovnih centara. U svakom centru, grupa strojeva koji opslužuju Windows Azure su organizirani u „tkanje“ (fabric).

Kao što pokazuje Slika 8, Windows Azure Fabric (tkanje) se sastoji od velike grupe strojeva kojima upravlja softver po imenu fabric controller. Fabric controller se nalazi rasporeñen unutar grupe od 5-7 strojeva i on upravlja svim resursima tog „tkanja“: računalima, mrežnim preklopnicima, rasporeñivačima opterećenja i drugim (computers, switches, load balancers, etc). Budući on može komunicirati sa agentom tkanja (fabric agent) a svakom računalu, on je svjestan i svake Windows Azure aplikacije u promatranom tkanju.

Možda je interesantno napomenuti da farbic controller vidi Windows Azure Storage kao još jednu aplikaciju, tako da su od njega skriveni svi detalji upravljanja i replikacije podataka.

Takva povezanost i saznanja omogućuju fabric cotroller-u da radi puno korisnih stvari. Na primjer, on prati sve pokrenute aplikacije i stvara aktualnu sliku o tome što se dogaña u tkanju. Isto tako, on upravlja operacijskim sustavom, vodeći računa o stvarima kao što je ažuriranje verziju sustava Windows Server 2008 koji se izvršava u Windows Azure virtualnoj mašini (VM). Takoñer odlučuje gdje treba pokrenuti nove aplikacije, tako što odabire fizičke poslužitelje da bi se optimiziralo korištenje hardvera. Da bi to mogao uspješno raditi, fabric controller ovisi o konfiguracijskoj datoteci koja se učitava sa svakom Windows Azure aplikacijom. Ta konfiguracijska datoteka sadrži XML opis onoga što aplikacija treba: koliko treba instanci Web rola, koliko instanci Woker rola i drugo.

7.2 Windows Azure: „Compute“ servis

Windows Azure Compute servis može pokrenuti različite vrste aplikacija, no primarni cilj ove platforme je da podrži aplikacije koje imaju vrlo velik broj istovremenih korisnika, a sam Microsoft koristi Windows Azure platformu za izgradnju vlastitih SaaS aplikacija.

Postizanje ovog cilja nije mogu će na način da se sve izvršava na sve jačim i jačim strojevima – dodavanjem

više procesora, memorije, više prostora za pohranu podataka u jednu mašinu – tzv. „scale-up“. Umjesto toga, Windows Azure je dizajniran za podršku aplikacija koje se mogu izvršavati na tzv. način „scale-out“, odnosno gdje se više kopija istog programskog kôda jedne aplikacije izvršava na puno uobičajenih poslužitelja. Kako bi se to omogućilo, Windows Azure aplikacija može imati više instanci, od kojih se svaka izvršava u svojem virtualnom stroju (VM). Ti VM-ovi se izvršavaju 64-bitne Windows Server 2008 poslužitelje, čija je virtualizacija bazirana na hipervizoru (koji se temelji na modificiranom Hyper-V).

Proces kreiranja aplikacijskog paketa za izvršavanje u Windows Azure

Proces stavljanja aplikacija u upotrebu se obavlja pristupom Windows Azure portalu putem web preglednika, gdje se (nakon postavljanja aplikacije) može konfigurirati koliko je potrebno instanca aplikacije, na bazi kojeg Windows Azure kreira virtualne mašine unutar kojih se izvršava programski kod.

Važno je napomenuti, budući se radi o PaaS modelu računalstava u oblaku, da se ne može postaviti svoja verzija virtualne mašine (VM-a) nego Windows Azure platforma osigurava svoju (modificiranu i upravljivu verziju). Na taj način se razvojni tim može koncentrirati na razvoj same Windows Azure aplikacije

Kod Windows Azure, na raspolaganju su dva različita tipa instanci: instanca Web role i instanca Worker role, o čemu više u slijedećem odlomku.

Windows Azure: Web i Worker role

Kao što i samo ime sugerira, instanca Web role može prihvatiti dolazni HTTP ili HTTPS zahtjev. Kao što je već navedeno, za svaku se instancu kreira nova virtualna mašina (VM), koja uključuje Internet Information Services (IIS). Razvojni inženjeri mogu kreirati instancu Web role pomoću ASP.NET, WCF, ili neke druge .NET tehnologije koje rade sa IIS. Razvojni inženjeri takoñer mogu kreirati aplikacije u programskom jeziku prema izboru, a to ne mora biti nužno na .NET Framework bazirani programski jezik (npr. PHP).

Izvršavanjem više od jedne instance aplikacije, Windows

Slika 9 shematski prikaz uloge Windows Azure Compute servisa


Azure osigurava skalabilnost aplikacije. Kako bi se to omogućilo instance Web role moraju biti napisane bez da pamte stanje izmeñu dva pozivanja neke metode na njima (tzv. stateless). Umjesto da se stanje pamti u nekoj instanci, ono se (izmeñu dva poziva neke metode) mora spremiti u trajno spremište podataka ili vratiti nazad klijentskom kodu kako bi se moglo upotrijebiti pri slijedećem pozivu neke metode (možda na nekoj drugoj web instanci). Nije definirati tzv. afinitete (preferiranje) neke odreñene instance web role, odnosno da svaki poziv neke metode uvijek ide prema odreñenoj instanci web role.

Instance Worker role se razlikuju od Web role jer, prema definiciji, ne mogu zaprimati direktne zahtjeve iz „vanjskog svijeta“ budući njihova virtualna mašina nema pokrenut IIS i ne može (podrazumijevano) prihvatiti bilo kakav zahtjev za vanjskom mrežnom komunikacijom. Umjesto toga, instanca Wokrer role pokreće svoj zahtjev za ulaznim podacima. To može napraviti, npr. tako da čita poruke iz reda čekanja (message queue), što je opisano kasnije u ovom tekstu, ili može sama instanca Worker role inicirati veze s vanjskim svijetom. Instanca Worker role može se promatrati kao vrlo slična batch obradama ili Windows servisima. Razvojni inženjer može koristiti: samo instancu Web role, samo instancu Wokrer role, ili njihovu kombinaciju. ListenRead phoneticallyDictionary

7.3 Windows Azure: „Storage“ komponenta

Bez obzira na to kako su spremljeni – bilo u blobovima, tabelama ili redovima - svi podaci spremljeni u Windows Azure Storage su replicirani tri puta (postoje tri kopije podataka), čime se omogućuje tolerancija na kvarove, pa gubitak jedne kopije podataka nije koban. Bez obzira

na postojanje tri kopije podataka, Windows Azure sustav jamči konzistentnost podataka, odnosno, da će bilo koja instanca programa pročitati upravo one podatke koji su u zadanom trenutku aktualni (a možda ih je upravo zapisala neka druga instanca aplikacije). U svakom slučaju, Windows Azure omogućava pristup tim podacima ne samo iz Web role, nego i bilo koje aplikacije koja se može izvršavati i izvan Windows Azure platforme – a u oba slučaja, neovisno o tome kojima se od tri tipa Windows Azure podataka pristupa, koristi se REST. To znači da se podaci imenuju koristeći URI i da im se pristupa sa standardnim HTTP operacijama, osobito ako se radi o jeziku koji ne podržava . NET Framework. S druge strane, ukoliko se radi o klijentskom kodu koji koristi .NET Framework, onda su za pristup podacima dostupne i tehnologije WCF Data Services i LINQ.

8. SQL AZURE

SQL Azure se sastoji od baze podataka koja je kompatibilna sa Microsoft SQL Server bazom podatka, a koja je dostupna na Windows Azure platformi. Druga komponenta su servisi za sinkronizaciju podataka izmeñu baza podataka izvan i u računalstvu u oblaku.

SQL Azure je distribuirana baza podataka, koja je visoko dostupna i izgleda jednako za korištenje .NET klijentskom programskom kodu kao da se radi SQL Serveru. U stvarnosti, radi se o 3 konzistentne kopije podataka ispred kojih se nalazi servis koji oponaša način rada SQL Servera. Sve logičke operacije i optimizacije su dostupne kao na SQL Server-u, no one fizičke (npr. optimizacije file grupa), naravno, nisu.

Bazama podataka se upravlja kroz web bazirani portal

Slika 10 shema Windows Azure Storage i tipovi podataka

Slika 11 SQL Azure i servisi


(kreira, modificira struktura i upravlja podacima), a SQL Azure upravlja samim fizičkim bazama, te osigurava visoku dostupnost i otpornost na kvarove. Isto tako, moguće je razvijati i upravljati bazama podataka putem alata za razvojne inženjere Visual Studio.

9. WINDOWS AZURE APPFABRIC

Slično kao što SQL Azure prenosi funkcionalnost SQL Server-a u oblak, AppFabric prenosi funkcionalnost .NET-a u računalstvo u oblaku. Usluge koje pruža AppFabric su ključne komponente za gradnju distribuiranih, povezanih aplikacija u Windows Azure, a osobito kada govorimo o povezivanju postojećih aplikacija koje se izvršavaju unutar neke organizacije i onih implementiranih u računalskom oblaku, odnosno izrade tzv. hibridnih aplikacija.

Trenutno postoje dva AppFabric servisa: Service Bus & Access Control Service.

9.1 AppFabric Service Bus

Service Bus je dizajniran da osigura aplikacijski bus (komunikacijski kanal) općenite namjene, dostupan putem Interneta. O Service Busu se može razmišljati kao Enterprise Service Bus-u koji su mnoge već implementirali, no za Service Bus-u dostupnim na Internetu postoji širi raspon scenarija za različite tipove organizacija. U osnovi, .NET Service Bus služi povezivanju aplikacija preko mreže i granica aplikacija, te omogućava jednostavnu implementaciju programskih predložaka poput objavljivanja i pretplate na servise.

9.2 AppFabric servis za kontrolu pristupa

Servis za kontrolu pristupa je dizajniran za implementaciju sigurnosti kroz zadana pravila, a na bazi zahtjeva tvrdi se temelji kontrole pristupa za aplikacije.

U osnovi, AppFabric servis za kontrolu pristupa omogućuje definiranje pravila za autorizaciju Windows Azure aplikacije koristeći temelji pristup koji je usvojen kod mnogih Microsoftovih proizvoda i tehnologija, a koje je Microsoft stavio na raspolaganje IT industriji.

10. ZAKLJU ČAK

Windows Azure platforma se sastoji od 3 ključna dijela: Windows Azure („globalnog distribuiranog operativnog sustava), SQL Azure (visoko dostupne, distribuirane baze podatka otporne na kvarove), te Windows Azure AppFabric (servisa za povezivanje aplikacija i servisa, te kontrolu pristupa).

Kod razvoja aplikacija, važno je razlikovati dva osnovna principa implementacije instanci programskog koda: Web role (kojima se može direktno pristupiti iz vanjskog svijeta putem HTTP/HTTPS protokola) i Worker role (koje moraju biti predkonfigurirane da bi im se moglo pristupiti, a čitaju poruke ili zadatke iz redova). Bez obzira o kojem se modelu radi (Web ili Worker), skalabilnost i visoka dostupnost je omogućena na način da Windows Azure kreira posebnu virtualnu mašinu (VM) za svaku instancu aplikacije.

Windows Azure je dostupan u 41 zemlji, a uskoro i u Hrvatskoj (već je dostupan za razvoj i testiranje), a predviña se da će uskoro biti dostupan i u inačici „ureñaja“ pa će organizacije moći kreirati svoje vlastito privatno računalstvo u oblaku.

Iz svega napisanog, vidljivo je da je Windows Azure na odličnom putu da kreira cjelovitu platformu za računalstvo u oblaku, a osobita prednost platforme je to što razvojni inženjeri mogu koristiti svoje stečeno znanje u razvoju web aplikacija i servisa, koristeći već poznati alat Visual Studio, programski jezik koji znaju i .NET tehnologije koje su već koristili (poput WCF-a).

Literatura:

1 Tomislav Bronzin: " Scenariji za razvoj aplikacija na Windows Azure platformi“, WinDays 11 Technology, Opatija, 2011

2 Tomislav Bronzin: "Azure Services platforma“, WinDays 9 Technology, Opatija, 2009

3 Dobriša Adamec: „Microsoft Azure Services Platform Development“, WinDays 9 Virtual, Opatija, 2009

4 Tomislav Bronzin: „N-slojni informacijski sustavi“, CASE 11, Opatija, 1999

5 Tomislav Bronzin: „SOA - Service Oriented Architecture - malo drugačije“, CASE 17, Opatija, 2005

6 Tomislav Bronzin, Dobriša Adamec: „Kako graditi povezive aplikacije korištenjem .NET Framework 3.5 tehnologije i Visual Studio 2008.“

7 „What is Windows Azure?“, http://www.microsoft.com/windowsazure/

8 „Cloud Computing“, http://en.wikipedia.org/wiki/Cloud_computing

9 „IBM Cloud Computing“, http://www.ibm.com/cloud

10 „Salesforce Cloud Computing“, http://www.salesforce.com/cloudcomputing/

11 Ostatak – u podnožjima na stranicama rada

Slika 12 Windows Azure AppFabric


Podaci o autorima:

Tomislav Bronzin, mag. ing. el., Microsoft Regional Director & MVP Tomislav Bronzin, mag. ing. el. je osnivač tvrtke CITUS, Microsoft Gold Certified partnera, čija je glavna djelatnost proizvodnja programskih rješenja i savjetovanje za razvoj aplikacija na Microsoft platformi. Autor je dva patenta s područja ICT-a registriranih u Hrvatskoj agenciji za intelektualno vlasništvo. Bio je uključen u projektiranje i implementaciju prvih nekoliko velikih mobilnih rješenja na Microsoftovoj platformi, uključivši one za Hrvatske šume i Hrvatske željeznice. Tomislav je nositelj počasnih titula Microsoft Regional Director, Microsoft MVP, te Microsoft Certified Trainer. Redovni je predavač na velikim Microsoftovim konferencijama u široj regiji, Microsoft TechEd Europe ili domaće WinDays i Mobility Day. Sudjelovao je kao predavač na akademskim konferencijama koje organizira Ministarstvo znanosti obrazovanja i športa, predaje studentima na Visokoj školi za primijenjeno računarstvo u Zagrebu, a kao pozvani predavač predavao je na FOI-u i FER-u, bio je mentor timovima studenata na natjecanju Microsoft Imagine Cup. Uz navedeno, Tomislav je potpredsjednik Udruženja za IT pri HGK, predsjednik je Hrvatskog udruženja programera, suosnivač je http://www.mscommunity.net portala, te je član upravnog odbora INETA Europe. Tomislav Bronzin is Senior Advisor in CITUS, Microsoft Gold Certified Partner Company for Solution Development and Consulting for Application Lifecycle Management. He is owner of two ICT based patents which was used in first two large Mobile Solutions on Microsoft platform developed for Croatian Forests and Croatian Railways. Tomislav has more than 18 years of real-life experience with Microsoft technologies with current interest in development of distributed applications based on .NET Smart Client and Mobile Devices technology, resulting in having 2 patents in those areas as well in Microsoft Unified Communication Development. He is teaching students at University College for Applied Computer Engineering in Zagreb and he is often invited to speak at Faculty of Electrical Engineering and Computing (FER) and Faculty of Organization and Informatics. Tomislav has been a regular speaker at Microsoft conferences in the region, as well as at several academic conferences and he was speaker at Microsoft TechEd Europe. He is INETA Europe Vice President, Croatian Chamber of Economy - IT Association Vice President, President of the Croatian Association of Computer Programmers and co-founder of http://www.mscommunity.net. Tomislav has honorable titles: Microsoft Regional Director and Most Valuable Professional – Solution Architect.

Dobriša Adamec, ing., Microsoft Most Valuable Profess ional (MVP) Dobriša Adamec, ing. je Solution Architect u tvrtki Citus, Microsoft Gold Certified partneru, gdje radi na razvoju i uspostavi servisno orijentiranih aplikacija. Višegodišnje iskustvo razvojnog inženjera i rada na izradi web aplikacija služi mu kao temelj današnjoj specijalizaciji: .NET platforma, XML i prateći otvoreni standardi te interoperabilnost aplikacija. Uz to što nove tehnologije koristi u svakodnevnom radu znanja o njima prenosi studentima Tehničkog Veleučilišta u Zagrebu gdje radi kao asistent na kolegijima "Uvod u XML programiranje" i "XML programiranje (web servisi)". Kao jedan od najaktivnijih članova Hrvatskog udruženja programera i SQL/Developers zajednice izabran je za člana upravnog odbora INETA Europe, a supruga i dva sina mu progledaju kroz prste kada dio slobodnog vremena potroši na rad mscommunity.net web portala. Zalaganje u zajednici pridonijelo je dobivanju Microsoft MVP statusa za područje ASP.NET. Dobrisa Adamec is Solution Architect in CITUS (Croatia, Zagreb), Microsoft Gold Certified Partner Company for Solution Development and Consulting for Application Lifecycle Management. He has being working on different projects for building service oriented applications. Dobrisa has years of experience in writing code, deploying long living applications, setting and walking up projects and building a development teams. This led to his today’s specializations: .NET Framework, Web Services and interoperability. He is exploring new technologies (WCF, WWF etc.) and teaching students at Zagreb Polytechnic (Tehnicko Veleucilste Zagreb) where he lectures in courses “XML programming - introduction” and “XML programming – Web Services”. As active member of Croatian Association of Computer Programmers (HUPRO) and SQL/Developers community, Dobrisa become the INETA Europe Vice President. His wife and two sons let him spend some free time on maintaining www.mscommunity.net portal. He is proud owner of Microsoft Most Valuable Professional for ASP.NET award. CITUS d.o.o.



PRIHVAĆANJE, PROVEDBA I RIZICI CLOUD COMPUTING - „STATE OF ART“ – STANJE STVARI 2011

ADOPTION, IMPLEMENTATION AND RISKS OF THE CLOUD COMPUTING -STATE OF ART

Miho Pitarevi ć

SAŽETAK:

Cloud computing prolazi kroz faze djetinjstva. Put do zrelosti ne vodi ravno. Uočavanje i pripremanje su glavna karakteristika ovog stanja. Zanimljivo istraživanje provedeno je prošle godine u SAD-u. Neki zanimljivi pokazatelji će biti prikazani u članku. Tijekom provedbe i prije početka korištenja korisnici imaju više pitanja nego što su u mogućnosti pronaći odgovore. Sigurnost je jedan od brojnih briga potencijalnih korisnika. Na sastanku na vrhu u ADS Infosecurity Europe, Cloud Security Alliance (CSA) je najavila da će imati ključnu ulogu u razvoju sigurnosti u „oblaku“ (cloud-u) i privatnosti standarda pod ISO/IEC. U dolazećem dobu cloud computinga sve više i više aplikacija se isporučuje kao daljinski „hostane“ i upravljane usluge. Potražnja za upravljanjem učincima Web-a i uslugama testiranja raste. Kao dio Digital Agenda procesa, u svibnju 2011. EU je počela konzultacije o utjecaju Cloud computinga na Europu. Komisija traži mišljenje o tome kako najbolje iskoristiti cloud computing u Europi. Rezultati savjetovanja bit će potka Europskoj cloud computing strategiji koju će Komisija predstaviti u 2012. Ova strategija će imati za cilj razjasniti zakonske preduvjete koji su potrebni da bi cloud computing u Europi zaživio, potaknuti razvoj konkurentnoga europskog odgovora i zamaha „oblak“ (cloud) industrije i tržišta, te olakšati roll-out inovativnih usluga cloud computinga za grañane i poslovne subjekte.

ABSTRACT:

Cloud computing passes childhood phase. The way to maturity is not straight. Looking around and preparations are the main characteristic of present status. An interesting research has been done last year in USA. Some figures are interesting and will be shown in article. Implementing and before the beginning of usage users have more questions than answers they are able to find. Security is one of numerous concerns of potentional users. At the CSA Summit at Infosecurity Europe, the Cloud Security Alliance (CSA) announced that it will have a key role in the development of cloud security and privacy standards under ISO/IEC. With the cloud computing era arriving and more and more applications being delivered as remotely hosted and managed services. Demand for Web performance management and testing services is growing. As a part of Digital Agenda process, in May, 2011 EU started the consultation on Cloud computing impact on Europe. Commission seeks views on how the best to exploit cloud computing in Europe. The results of the consultation will feed into a European cloud computing strategy that the Commission will present in 2012. This strategy will aim to clarify the legal conditions for the take-up of cloud computing in Europe, stimulate the development of a competitive European cloud industry and market, and facilitate the roll-out of innovative cloud computing services for citizens and business.

1. RIZICI CLOUD COMPUTINGA

Uglavnom kada se pitamo ili kada pitaju nas mislimo da znamo SVE. Mislimo da je Cloud computing NEŠTO poznato, samo presloženo na drugi način. U osnovi to je Nova revolucija, ako Internet smatramo prvom Revolucijom. Sve ostaje ISTO (?) ali u osnovi SVE se mijenja.

Kakav je to Novi Svijet? Svijet u Oblacima. I pitamo se koji oblak odabrati ili koji je Moj oblak? Pogledamo nebo i znamo kako u trenu tmurni oblaci prekriju plavo, sunčano nebo. Mi ne želimo tmurne i prijeteće oblake. Mi ne želimo rizike, gubitke, nasrtaje, sve ono što nam zadaje probleme, nanosi štetu, zbunjuje i permanentno nudi neizvjesnost. Ne želimo „Cloud computing“ doživljavati kao adrenalinsku bombu. Ne želimo Rizike!

Sve prednosti su toliko puta izrečene, primamljujuće su kao i Evina „jabuka“. Zovu i vabe. Možemo li im se oduprijeti? Stoje tako na jednoj strani vage. No što stoji na drugoj? Vidimo li jasno? Naslućujemo li? Znamo li? Pogañamo li?

Nismo mi sami. To muči i mnoge „donositelje odluka diljem svijeta.

Pogledajmo što „muči“ korisnike, o čemu oni razmišljaju. Pitanja je puno. Puno, puno i lista je svaki dan raste. Pokušati će navesti tek dio, jer kako Cloud Computing ulazi u naše živote lista je svaki dan sve veće.

Ovo u samo dio te liste pitanja (kako Cloud computing „vidi“ ISACA): � Right to audit � User data � Confidence � Trust � Metrics � Forensics � Identity � Resilience � Compliance � Privacy � Workflow � Location � Incident handling � Competitive Advantage � Traceability � Evidence gathering � Architecture � Virtualization � Maturity models Isolation


� Data segregation � Web services

(Pitanja/„subjects“ u listi su proizvoljnom poretku. Rangiranje po važnosti, značenju i prioritetima stvar je svakog korisnika ponaosob. No, od ovih pitanja nitko ne može „pobjeći“.)

U zatvorenom sustavu uvijek je suma sastavnica (približno) jednaka. To vrijedi i za „cloud computing“.

Recimo NE „filozofiranju“. Ukupna cijena usluga u konačnici neće biti „n“ puta manja, kako to često zagovaraju „advokati“ cloud computinga. Zbrojiti će se u nju i ono o čemu se danas ne govori ali će na kraju račun doći nama na naplatu.

Da, za servis i infrastrukturu plaćati ćemo drastično manje ali sigurno je ćemo za sigurnost, upravljanje rizicima, operativno provoñenje SLA, alatima za mjerenje, upravljanje kvalitetom i billing plaćati više.

Nema računice, koju možemo „prepisati od susjeda“. Svatko mora to obaviti SAM za svoje poslovne potrebe. No i ovo „sam“ ne treba shvatiti doslovno. Dapače čak je i poželjno i preporučljivo koristiti znanje eksperata, koji su već implementirali više Cloud Computing slučajeva i imaju potrebno znanje.

Cloud computing nije jednostavan „plug–and-play“ za svaku firmu veću od 5 zaposlenih, a o velikim sustavima da i ne govorimo. Spomenimo samo integraciju s ERP-om kad je i preporučljivo „kupiti“ znanje. (Gledajući Cloud computing primjere u Hrvatskoj (i regiji) „Agrokor“ je dobar i ilustrativan primjer.)

Najčešće pitanje je koji model odabrati? Pravo pitanje, no za dobiti odgovor moramo znati koja su nam mjerila i parametri odlučivanja, koje moramo prvo odabrati!

Osobno vjerujem u Cloud model i baš zato sam u nastavku rada naveo tek nekoliko rizika i prijetnji sigurnosti, koje treba imati na umu u procesu odlučivanja, ugovaranja, implementacije, korištenja, mjerenja, upravljanja kvalitetom i billinga.

Cloud Computing je „business issue“.

Zapamtite, ne tehnološki ili tehnički.

Odluku o njemu mora donijeti, NE ICT, već poslovna uprava. ICT će ga odraditi po pravilima struke i kanonima znanja, nakon odluke!

2. NEKI OD RIZIKA

U nastavku je radi ograničenja dužine rada navedeno tek nekoliko rizika.

2.1 Nesigurna su čelja i API-ji

Davatelji Cloud Computing usluga nude set softverskih sučelja ili API-ja koji korisnici koriste za upravljanje i interakciju s cloud uslugama. Korištenje, upravljanje, orkestracije, i praćenje sve se izvodi pomoću tih sučelja. Sigurnost i dostupnost cloud usluga ovisi o sigurnosti tih temeljnih API-ja. Od autentifikacije i kontrole pristupa za šifriranje (enkripciju) i praćenja aktivnosti, ta sučelja moraju biti dizajnirani kako bi zaštitili protiv i slučajnih i zlonamjernih pokušaja za zaobilaženje politike zaštite. Osim toga, organizacije i treće strane najčešće grade na tim sučeljima ponudu dodatnu vrijednosti usluge svojim klijentima. To uvodi složenost novih slojevitih API, što, takoñer, isto povećava rizik, jer se od organizacija može zahtijevati da odreknu svojih vjerodajnica trećim stranama kako bi se omogućile vlastite operacije.

Utjecaj

Većina davatelja usluga cloud computinga nastoji osigurati da sigurnost bude „dobro“ integrirana u njihovim servisnim modelima. Važno je da potrošači tih usluga razumiju i sigurnosne implikacije vezane uz korištenje, upravljanje, praćenje i orkestraciji od „cloud“ usluga. Oslanjanje na „slab“ skup sučelja i API-ja izlaže organizaciju niz sigurnosnih pitanja koja se odnose na povjerljivost, integritet, dostupnost i odgovornost

Preporuka � Analizirati sigurnosni model sučelja davatelja cloud

usluga, � Osigurati jaku autentifikaciju i kontrolu pristupa

implementiranu s enkripcijom prijenosa, � Razumjeti „lanac ovisnosti“ (dependancy chain)

povezan s API-jima.

2.2 Zlonamjerni „insider“

Prijetnja od zlonamjernih insidera je dobro poznata za većinu organizacija. Ova prijetnja je pojačana za potrošače cloud computing usluga konvergencijom IT usluga i kupaca pod jedinstvenim upravljanjem domena, u kombinaciji s općim nedostatkom transparentnosti u procesima i procedurama davatelja usluga.

Na primjer, davatelj usluga ne može i/ili ne želi otkriti ili ne postoji uvid, kako se zaposlenicima daje pristup fizičkim i virtualnim sredstvima, kako se monitoriraju i nadziru ti zaposlenici, ili kako se to u ukupnosti analizira i izvješćuje o politici usklañenosti.

Da bi stvari bile još kompliciranije, često postoji malo ili nimalo „vidljivosti“ i transparentnosti u standardima zapošljavanja i praksom za „cloud“ zaposlenika. Ovakva situacija jasno stvara atraktivnu priliku za protivnik, potencijalnog napadača - u rasponu od hobi hakera do organiziranog kriminala, korporativne špijunaže ili čak upada pod pokroviteljstvom nacija-država („cyberwar“). Dodijeljene razine pristupa mogu omogućiti takvim protivnicima bogate „žetve“ povjerljivih podataka ili čak preuzimanje potpune kontrole nad cloud uslugama s malo ili bez rizika otkrivanja.

Utjecaj

Značajan utjecaj na organizaciju može imati zlonamjerni insajder, razmjeran na njegovu (dozvoljenu/odobrenu) razinu pristupa i sposobnosti da se infiltrira u sustav organizacije i njene vrijednosti/imovinu. Štete na brandu, financijskim učincima i gubici produktivnosti samo su neki od načina zlonamjerni insideri mogu utjecati na rad i operacije. Kako organizacija usvojiti cloud usluge, ljudski element poprima sve veće i dublje značenje. To je važno kako potrošači cloud usluga razumjeli što davatelji poduzima i radi za otkrivanje i obranu od prijetnji zlonamjernih insidera.

Preporuke � Provoditi striktno upravljanja opskrbnim lancem i

provoditi sveobuhvatnu procjenu dobavljača, � Odredite zahtjeve na ljudske resurse kao dio pravne

ugovore, � Zahtijevati transparentnost u ukupnoj informacijskoj

sigurnosti i praksama upravljanja, kao i usklañenost izvješća,

� Odrediti obvezatnost procesa obavijesti o proboju sigurnosti.

2.3 Pitanja zajedni čke tehnologije

IAAS dobavljači dostavljaju svoje usluge na skalabilan način dijeljenjem infrastrukture. Često, temeljne komponente koje čine ovu infrastrukturu (npr. CPU


caches, GPU, itd.) nisu bile dizajnirane da pružaju jaka izolacijska svojstva za multi-user (multitenant) arhitekture. Da bi se riješio taj jaz, virtualizacijski hypervisor posreduje izmeñu pristupa gost-operacijskih sustava i fizičkih računalnih resursa. Ipak, čak i hypervisori su izloženi nedostacima koji mogu omogućiti „gost“ operativnom sustavu da dobije neprimjerenu razinu kontrole ili utjecaja na platformi. Preporučuje se strategija obrane u dubinu, koja mora obuhvatiti provedbu i praćenje računalne, skladišne, i mrežne sigurnosti. Treba biti provedeno snažno razgraničenje resursa (compartmentalization) kako bi se osiguralo da pojedini kupci ne utječu na poslovanje ostalih korisnika koji dijele isti blok usluga. Kupci ne bi smjeli imati pristup do bilo kojih stvarnih ili preostalih podataka, utjecaj na mrežni promet ili bilo što drugo a što je vlasništvo drugih korisnika.

Utjecaj

U posljednjih nekoliko godina pojavili su se napadi koje su usmjereni na zajedničke tehnologije unutar okruženja Cloud Computing. Disk particije, CPU cache-evi, GPU i drugi zajednički elementi nikada nisu bili dizajnirani za jake „compartmentalization“-e. Kao rezultat toga, napadači su se fokusirali na to kako utjecati na poslovanje ostalih kupaca cloud usluga, te kako dobiti i osvojiti neovlašteni pristup podacima.

Preporuke � Provesti najbolje sigurnosne prakse za instalaciju/

konfiguraciju, � Monitorirati okruženje od neovlaštenih promjena/

aktivnosti, � Promicati „jake“ postupke autentifikacije i kontrole

pristupa za administriranje i operacije, � Provoditi SLA - sporazum o razini usluge za

„krpanje“ i sanacije/oporavak ranjivosti, � Provoditi „skeniranje“ ranjivosti i konfiguraciji

revizije.

2.4 Gubitak podataka

Postoji mnogo načina za kompromitiranje podataka. Brisanja ili mijenjanja zapisa bez backup izvornih sadržaja je očigledan primjer. Prekidanje (unlinking) record-a/zapisa iz šireg konteksta može donijeti nepopravljivu štetu. Isto tako to može učiniti pohrana na nepouzdanim medijima. Gubitak ključa kodiranja/ enkripcije može dovesti do efektivnog paketa uništenja. Konačno, neovlaštenim osobama mora biti zapriječeno dobivanje pristupa osjetljivim podacima. Prijetnja kompromitiranja podataka povećava se u oblaku, s obzirom na broj interakcija, rizika i izazova koji su ili jedinstveni za oblak, ili više opasni radi arhitekture ili operativnih osobina okoliša clouda.

Utjecaj

Gubitak podataka ili njihovo „curenje“ može imati razarajući učinak na poslovanje. Osim štete na jedan brand i ugled, gubitak bi mogao značajno utjecati zaposlenike, partnere i kupce, na njihov moral i povjerenje. Gubitak samog intelektualnog vlasništva mogao imati konkurentske i financijske implikacije. Što je još gore, ovisno o podacima koji mogu biti izgubljeni ili koji „iscure“, moglo bi doći do kršenja usklañenosti i pravnih posljedica.

Preporuke � Provesti jake API kontrole pristupa, � Šifriranje i zaštita integriteta podataka u tranzitu, � Analizira zaštita podataka kako u dizajnu tako i

vrijeme izvoñenja.

� Implementirati generiranje jakih ključeva, definirati praksu za pohranu i upravljanje, a posebno praksu za uništenje,

� Ugovorom urediti davatelju usluge brisanje „potrošenih“ medija pohrane prije nego što se pohranjuju u „pool“,

� Ugovorom specificirati backup davatelja i strategije zadržavanja.

2.5 Otmica ra čuna ili usluge (Account or service hijacking)

Otmice računa ili usluga nije nova stvar, nije nova prijetnja. Metode napada kao što su krañe identiteta, prijevare i iskorištavanja programskih ranjivosti još uvijek postižu rezultate. Vjerodajnice i lozinke koje se opetovano i često koriste,pojačavaju i osnažuju utjecaj takvih napada. Cloud rješenja dodati novu prijetnju tom krajoliku. Ako napadači dobiju pristup vašim vjerodajnicama, oni mogu „prisluškivati“ vaše aktivnosti i transakcije, manipulirati podacima, povratno falsificirali podatke, i preusmjeriti vaše klijente na nelegitimni-ilegalne stranice i sitove. Vaš račun ili servis mogu postati nova baza za napadača. Odavde, oni mogu iskoristiti moć vašeg ugleda za pokretanje naknadnih napada.

Utjecaj

Ostaje top prijetnja otmice račun i servisa, obično s ukradenim vjerodajnicama. S ukradenim vjerodajnicama, napadači često mogu pristupiti kritična područjima korištenih cloud computing servisa, dopuštajući im da kompromitiraju tajnosti, cjelovitosti i dostupnost tih usluga. Organizacije trebaju biti svjesne ovih tehnika, važnosti zajedničke obrane kao i strategije dubinske zaštite kako bi obuzdali štetu (i moguće pravne sporove) koji bi proizašli.

Preporuke � Zabraniti dijeljenje vjerodajnica računa izmeñu

korisnika i usluga, � Iskoristite snažne tehnike dvostruke autentifikacije

gdje god je to moguće, � Provoditi proaktivno monitoriranje za otkrivanje

neovlaštenih aktivnosti, � Razumjeti oblak sigurnosne politike i SLA pružatelja

usluge.

3. EU KONZULTACIJE

Europska komisija zatražila je sredinom svibnja 2011. od grañana, poslovnih subjekata, javne uprave i druge zainteresiranih strana mišljenje, o tome, kako u potpunost i koristi 'cloud computing'.

Cloud computing, smatra Komisija, omogućuje tvrtkama, javnim upravama i pojedincima da koristeći mreže poput Interneta, pristupaju svojim podacima i softveru na računalima, koji se „nalaze negdje drugdje“ – u oblaku, u oblacima. Cloud computing nije nedavno izmišljen „buzzword“. Već naširoko se koristi u cijeloj Europi, na primjer za web-based e-mail usluge. (Tako je primjerice i u Hrvatskoj oko 500.000 korisnika „hotmail“-a !)

Zašto je „cloud“ važan za europsko gospodarstvo i za društvo u cjelini?

U vremenima recesije i imperativa post recesijskog oporavka, u vremenima borbe ekonomskih imperija za pozicioniranje na globalnim tržištima i najmanje zaostajanje znači gubitak tržišne snage, smanjivanje tržišnog učešća, manje prihode i onda sve negativne


efekte za sve igraće od EU zajednice do grañanina. Digitalna Agenda jedan je odgovora EU na to.

Cloud može osobito pomoći tvrtkama - osobito malim i srednjim poduzetnicima - da se drastično smanje troškovi informatičke tehnologije. Isto tako pomoći će vladama u pružaju usluge informacijskog društva po nižim cijenama i uz uštedu energiju. Cloud će potaknuti i bolje i učinkovitije korištenje hardvera.

Onu što motivira Komisiju da „cloud-u“ pokloni posebnu pažnju je imperativ ostvarenja Digitalne Agende. Cloud dolazi kao ohrabrenje i snažan podupiratelj naporima koji se provode. Činjenica da se u Europi do 2014. očekuje, da će „cloud industrija“ generirati prihod od gotovo 35.000.000.000 €, govori sve.

Promicanje „cloud-a“ i stvaranja uvjeta za grañane i tvrtke da ostvare najbolje koristi od ovog tehničkog razvoja je jedna od radnji predviñenih Digital Agenda za Europu (vidi IP/10/581, MEMO/10/199 i MEMO/10/200). Online Javna rasprava trajat će do 31. kolovoza . Odgovori i mišljenja koristiti će se u pripremi Europske cloud computing strategiju koju će Komisija predstaviti u 2012. Neelie Kroes, potpredsjednica Europske komisije za Digital Agenda, izjavila je:

"Ja sam uzbuñena glede potencijalne koristi od cloud computing u smanjenje troškova, poboljšanju usluge i otvaranju novih poslovnih mogućnosti. Trebamo dobro definirati strategije cloud computinga kako bi se osiguralo najbolje korištenje tog potencijala. „Inpute“ koje tražimo od svih zainteresiranih strana važni su nam da biste dobili ONO pravo."

Cloud computing ima potencijal da se razvije u veliku novu uslužnu djelatnost, što predstavlja i otvara velike mogućnosti za europsku telekom industriju i ICT tehnološke tvrtke. To je ono što primarno fokusira EU u tom smjeru. (Ako na ovom mjestu pogledamo napore i pravac razvoja što ga prema „cloud“ uslugama provode u Hrvatskoj: T-Com i/ili KING, onda možemo samo reći da su i oni na tragu razmišljanja Komisije!)

Klijenti bilo u domeni poduzeća ili javne uprave mogu imati velikih koristi od nižih troškova i „state-of-the-art“ usluge koristeći cloud computing umjesto instaliranja i održavanja softvera i vlastite računalne opreme. I ujedno fokusirati se na „core“ poslovanje a poslovni model pojednostaviti. Time mogu povećati elastičnost i fleksibilnost osobito važnu u vremenima kada je nužna velika brzina promjena. (I u Hrvatskoj sve više poduzeća okreće se cloudu a i SdeH na svojoj web stranici „govori“ o „upravi u oblaku“).

Hrvatska sa svojim razvojem prema cloudu nije nesukladna sa Europom. Možda Europa „malo“ kaska za drugim naprednijim tržištima i možda je priprema Europske strategije „zakasnila“.

Cloud će donijeti uštede jednima ali i glavobolje drugima. Komisija je pozvala sve zainteresirane stranke, posebice developere na razvoju „cloud“-a i korisnike da iskažu i objasne svoja iskustva, potrebe, očekivanja i uvid u buduće korištenje i pružanje cloud computing.

Izmeñu ostalog, predviñeno istraživanje traži povratne informacije o sljedećim pitanjima: � zaštita podataka i odgovornost pitanja, osobito u

prekograničnim situacijama; � druge pravne i tehničke prepreke koje mogu usporiti

razvoj cloud computing u Europi; � standardizacija i interoperabilnost rješenja; � usvajanje oblak (“cloud“) usluga, posebice za

potrebe malih i srednjih poduzeća;

� načini za promicanje istraživanja i inovacija u cloud computing.

Rezultati savjetovanja bit će sadržani u Europskoj cloud computing strategiji koju će Komisija predstaviti u 2012. (za godinu dana!).

Ova strategija imati će za cilj: � razjasniti zakonskih uvjeta za potrajati-up za cloud

computing u Europi, � potaknuti razvoj europske konkurentne „cloud“

industrije i tržišta, te � olakšati „roll-out“ inovativnih usluga cloud computing

za grañane i poslovne subjekte.

4. ZAKLJU ČNA RAZMATRANJA

Cloud će donijeti uštede jednima ali i glavobolje drugima.

Nameće se jedna usporedba. Ako zatvorimo oči i prisjetimo se trgovačke maloprodaje, malih uličnih dućana, po nekoliko u maloj ulici. Da, to je bilo nekad i koliko ih sad radi?

Pojeli su ih veliki. Maxi marketi, supermarketi...I daju niže cijene i duže rade i sve imaju, baš koliko ti treba.

Kako i cloud davatelji.

Sve ima. Novi PC u nekoliko klikova i tako dalje i dalje. Ne treba lokalni vendor koji u najboljem slučaju treba 1 dan da nešto isporuči. Ni lokalna mreža. Ni lokalni prodavatelj licenci za radna mjesta za software. Njih neće biti, neće ih trebati. Ali neće biti ni njihovog prihoda u porezu države i lokalne zajednici a njihovi zaposlenici preseliti će se na burzu rada.

To je ono što je zabrinulo Europu i zato je pokrenuta Konzultacija i zato će biti pripremljena Strategija. Ta Strategija trebala je biti na razini Europe pripremljena prije tri godine. No i to je dobar primjer da vidimo da spori administrativni mehanizmi nisu samo monopol Balkana.

Na kraju mogu li se formulirati neke preporuke budućim „Cloud“ userima?

Autoru se najviše svidjelo ovih nekoliko poruka. (One se prenose na engleskom kako bi se izbjeglo „možda“ krivo interpretiranje uzrokovano lošim prijevodom !) � Organizations should look beyond SaaS offerings

when evaluating cloud computing options � IaaS and PaaS services are key cloud computing

technologies that can be leveraged to accomplish business objective

� Cloud computing touches many different technologies

� Before implementing a cloud environment Organizations should invest time understanding how the cloud will affect:

- access control - network security - virtualization - other core network components

� Cloud computing deployments should be a cross-functional effort with:

- IT: • application developers IT, • network architects IT • network resources management • information security, data protection & privacy

experts IT - risk management - other critical business stakeholders weighing in prior

to cloud purchasing decisions


Podaci o autoru:

Miho Pitarevi ć Hrvatska udruga za razvoj informacijskog društva e-mail: [email protected] Autor je radio u Ministarstvu mora, turizma, prometa i razvoja u Upravi za telekomunikacije i pošte na poslovima ICT infrastrukture i informacijskog društva. Objavljuje radove i sudjeluje na brojnim konferencijama u inozemstvu i domovini. Prethodno radio u Zagrebačkoj banci sudjelujući, koordinirajući i vodeći brojne info projekte. Zadnjih 12 godina fokusiran na elektroničko bankarstvo, call centre, upravljanje kontaktima i CRM.


UPRAVLJANJE ZNANJEM: PRIMJER IZ HRVATSKE POSLOVNE P RAKSE

KNOWLEDGE MANAGEMENT: A CASE STUDY FROM CROATIAN BUSINESS PRACTICE

prof.dr.sc. Vesna Bosilj Vukši ć, mr. Adrian Špoljar, mr. Helena Štulina

SAŽETAK:

Znanje ima glavnu ulogu u stvaranju modernog svijeta, pretvarajući tradicionalnu ekonomiju u ekonomiju znanja. Cilj je upravljanja znanjem stvoriti uvjete za kvalitetniji proces donošenja odluka, a u tu svrhu organizacije razvijaju sustave za upravljanje znanjem koji se sastoje od širokog spektra različitih informacijskih tehnologija.

Premda je svrha sustava za upravljanje znanjem unaprijediti i ubrzati tijek poslovanja, često dolazi do komplikacija prilikom njihovog uvoñenja, te je stoga važno izbjeći implementacijske propuste. U tu svrhu nastali su različiti modeli procjenjivanja i mjerenja uspješnosti implementacije sustava za upravljanje znanjem.

U ovom radu prikazan je primjer implementacije sustava za upravljanje znanjem u hrvatskoj javnoj upravi. U svrhu povećanja efikasnosti i efektivnosti rada inspekcijskih službi, te usklañenog djelovanja različitih tijela državne uprave u funkciji inspekcijskog nadzora, razvijen je sustav e-Inspektor. Prikazane su koristi, mogućnosti, ograničenja i izazovi ovog sustava te su dani prijedlozi budućih poboljšanja.

ABSTRACT:

Knowledge plays a key role in creating modern world, transforming a traditional economy to a knowledge economy. The goal of knowledge management is to support decision making and to achieve this, organizations use knowledge management systems which represent a whole variety of information technologies to manage organizational knowledge.

Though the primary purpose of knowledge management systems is to improve and accelerate the business, deployment of these systems often leads to complications. Therefore it is important to avoid the implementation failures.

This paper gives an overview of the knowledge management system implementation in Croatian government. In purpose of increasing effectiveness of inspection services, and synchronized actions of different government bodies in the function of inspection surveillance, system e-Inspector was developed. The benefits, opportunities, limitations and challenges of e-Inspector system are examined and the proposals for the future improvements are given.

1. UVOD

Suvremeno poslovno okruženje karakterizira velika nesigurnost i neizvjesnost. Organizacije koje žele postići uspjeh u takvom okruženju moraju djelovati brzo i učinkovito, uvoñenjem novih modela poslovanja. Nekada je za stvaranje vrijednosti ključno bilo uložiti materijalne resurse u obliku kapitala ili zemlje, dok je danas fokus na znanju, kritičnom faktoru u stvaranju inovacija i postizanju konkurentske prednosti. Prema Gallupe (2001) znanje je prava imovina organizacije i kao svakom drugom imovinom, njime se mora učinkovito upravljati. Znanje može postojati u različitim vrstama i oblicima, te služiti različitim svrhama. Ono se smatra proširenom informacijom u kojoj je znanje „ugrañeno“ s odreñenim kontekstom. Zbog toga je veći izazov njime manipulirati i upravljati u sustavnom smislu, nego s informacijom.

Upravljanje znanjem (engl. Knowledge management – KM) jest pristup koji se pojavio na stručnim i znanstvenim konferencijama polovinom 90-ih godina prošlog stoljeća te se godinama svrstavao meñu najvažnije pristupe promjenama u poslovanju, zajedno s TQM-om i BPC-om. U početku se upravljanje znanjem bavilo isključivo primjenom informacijske tehnologije za prikupljanje, pohranjivanje i deseminaciju znanja, a potom se fokus interesa usmjerio prema organizacijskim promjenama, upravljanjem intelektualnim kapitalom te upravljanjem odgovornošću. Posljednjih godina se u važne elemente ovog pristupa ubrajaju društva koja uče

(inteligentna društva), upravljanje inovacijama i upravljanje promjenama. Kao rezultat takvoga djelovanja, sve intenzivnije se javljaju sustavi koji procese stvaranja, prikupljanja, pohrane, širenja, dijeljenja i primjene znanja čine efikasnim, a nazivaju se sustavima upravljanja znanjem. Premda je svrha sustava za upravljanje znanjem unaprijediti i ubrzati tijek poslovanja, često dolazi do komplikacija prilikom njihovog uvoñenja, te je stoga važno izbjeći implementacijske propuste. U tu svrhu nastali su različiti modeli procjenjivanja i mjerenja uspješnosti implementacije sustava za upravljanje znanjem.

U ovom radu prikazan je primjer implementacije sustava za upravljanje znanjem u hrvatskoj javnoj upravi. U svrhu povećanja efikasnosti i efektivnosti rada inspekcijskih službi, te usklañenog djelovanja različitih tijela državne uprave u funkciji inspekcijskog nadzora, razvijen je sustav e-Inspektor. Prikazane su koristi, mogućnosti, ograničenja i izazovi ovog sustava te su dani prijedlozi budućih poboljšanja.

2. UPRAVLJANJE ZNANJEM U ORGANIZACIJI

2.1 Pristupi upravljanju znanjem u organizaciji

Općenito se može reći da je upravljanje znanjem proces kreiranja, prikupljanja i korištenja znanja zbog unapreñenja performansi poduzeća.Prema V. Hlupic


(2003) upravljanje znanjem se sastoji od tri osnovne aktivnosti: (1) stvaranja znanja – obuhvaćanje postojećeg znanja, otkrivanje znanja, pretraživanje znanja, (2) organizacije znanja – pohranjivanje znanja i upravljanje pohranjenim znanjem i (3) podjele (širenja) znanja – suradnja, razmjena i prijenos znanja. Na razvoj KM-a utjecala su četiri pokretača: (1) informacijska tehnologija i procesiranje informacija, (2) poslovno izvještavanje (poslovna inteligencija), (3) organizacijsko znanje i (4) razvoj organizacije temeljen na znanju. U skladu s navedenim, razlikujemo i četiri pristupa upravljanju znanjem (Bosilj Vukšić i Kovačič, 2004).

Najvažnije obilježje prvog pristupa KM-u je intenzivna primjena informacijske tehnologije u prikupljanju, pohranjivanju i meñusobnoj razmjeni informacija, odnosno znanja. Ideja o tome da se znanje može pohraniti u informacijskom sustavu poduzeća temeljila se na uspjesima umjetne inteligencije i ekspertnih sustava. Prvi sustav za upravljanje znanjem (engl. Knowledge Management System - KMS) razvijen je 1988. godine kao potpora arhivi (knjižnici) dokumenata, priručnika i procedura za potrebe mornarice SAD-a. Sustav nije bio ništa drugo doli golema baza podataka s mehanizmom povezivanja srodnih dokumenata (SGML, HTML). U toj fazi se sustavima za upravljanje znanjem obuhvaćalo samo eksplicitno znanje, odnosno znanje koje je bilo dobro strukturirano, organizirano i semantički nije bilo zahtjevno.

Obilježje drugog pristupa KM-u je osnivanje posebnih odjela za poslovnu inteligenciju koji su se bavili strateškim analizama unutarnjih (podataka iz informacijskog sustava poduzeća) i vanjskih informacija (informacije iz okruženja poduzeća o stanju na tržištu i konkurenciji). Početkom 1990-ih su stvoreni uvjeti za prikupljanje informacija iz vanjskih izvora u realnom vremenu (razvoj Interneta) te se započelo s razvojem sustava koji bi omogućili analizu i kategorizaciju velike količine informacija prema potrebama korisnika. Tako nastaju poslovni inteligentni sustavi koji osiguravaju da informacije, odnosno znanja budu dostupna u svakom trenutku onome kome su potrebna za donošenje poslovnih odluka.

Za treći pristup KM-u je karakteristična svijest o postojanju organizacijskog znanja. Organizacijskim znanjem se smatra sve ono znanje koje posjeduju zaposlenici neke organizacije, a koje nije rezultat samo obrazovanja i vještine zaposlenih već i njihova dugogodišnjeg iskustva u obavljanju poslova u toj organizaciji, kao i znanje ugrañeno u sustav upravljanja i rukovoñenja, u definirane vrijednosti, norme, poslovna pravila i procedure organizacije.

Obilježje četvrtog pristupa KM-u je provedba organizacijskih promjena potrebnih za razvoj poduzeća orijentiranog znanju. Poduzeće koje svoj uspjeh temelji na znanju mora provesti odgovarajuće organizacijske promjene. Istraživači na čelu s Nonakom pokušali su povezati upravljanje znanjem i poslovne procese i tako stvorili organizaciju koja uči (inteligentnu organizaciju) u kojoj se upravlja procesom stvaranja znanja.

Upravljanje znanjem pretpostavlja uvoñenje odreñenih promjena u svakidašnjem radu. Svaka promjena u procesu rada, pa makar i malena (npr. promijenjeno vrijeme odmora, zapošljavanje novih djelatnika), u početku stvara negativan odnos zaposlenika. Istraživanja su pokazala kako je otpor zaposlenika najveća zapreka pri implementaciji sustava za upravljanje znanjem, a ostali često spominjani problemi jesu troškovi razvoja sustava i nizak stupanj razvoja informacijske tehnologije u poduzeću.

Kako bi se izbjegli otpori zaposlenika prema promjenama, potrebno je upoznati ih s prednostima upravljanja znanjem i ugraditi svijest o potrebi upravljanja znanjem u organizacijsku kulturu poduzeća. Organizacijska kultura je način razmišljanja («sustav mišljenja») koji je zajednički ljudima u organizaciji i razlikuje jednu organizacijo od druge. Ako unutar poduzeća postoji organizacijska kultura, to znači da zaposleni u organizaciji čvrsto zastupaju neke zajedničke vrijednosti. Oblikovanje tih vrijednosti počinje već pri osnivanju poduzeća u obliku simbola (logotip, zastava, ureñenost prostora), i nastavlja se razvijati tokom njegova djelovanja. Razumljivo je da je pri tome uzor vodstvo poduzeća koje se mora ponašati sukladno načelima organizacijske kulture. Zbog toga je za uspješno upravljanje znanjem važno da se vodstvo aktivno uključi u proces obuhvaćanja i identificiranja znanja te motivira zaposlenike da se brže i lakše prilagode promjenama.

2.2 Informacijska tehnologija za upravljanje znanjem u organizaciji

Iako tehnologija nije jedina komponenta u upravljanju znanjem, u informacijskom vremenu u kojem živimo bi bilo teško zamisliti ijednu efikasnu inicijativu za upravljanje znanjem bez tehnološke infrastrukture koja će je podupirati (Wickramasinghe i von Lubitz, 2000.). Pojam tehnologije u tom se kontekstu uglavnom odnosi na informacijsku tehnologiju, odnosno programske alate za upravljanje znanjem. Osnova sustava za upravljanje znanjem je informacijska tehnologija koja ima višestruku ulogu: generira novo znanje, prikuplja i pohranjuje znanje, strukturira znanje u odgovarajući oblik te osigurava njegovu dostupnost korisnicima (Bosilj Vukšić i Kovačič, 2004). Sveukupnu informacijsku tehnologiju koja omogućuje upravljanje znanjem u organizaciji nazivamo sustavom za upravljanjem znanjem, eng. knowledge management system – KMS (Bosilj Vukšić et al. (2010). Budući da sustavi za upravljanje znanjem rabe različite oblike informacijske tehnologije, možemo ih podijeliti u više kategorija, kao što su: � sustavi za upravljanje dokumentima – računalni

sustavi za prikupljanje, pohranjivanje, i pretraživanje dokumenata tokom cijelog njihovog životnog ciklusa,

� sustavi za grupni rad i suradnju – pružaju potporu radu na zajedničkim projektima, omogućuju elektroničku razmjenu poruka, suradnički rad na elektroničkim dokumentima, koordinaciju rada u skupini, odlučivanje u skupini i održavanje telekonferencija,

� mape i direktoriji znanja – poveznice do izvora novog znanja (dokumenata, zbirki podatka i osoba),

� mreže znanja, diskusijske liste, forumi, Web 2.0 servisi – omogućuju razmjenu iskustava i mišljenja stručnjaka elektroničkim putem

� inteligentni agenti – alati za samostalno pretraživanje i pronalaženje podataka prema zadanim kriterijima,

� baze eksplicitnih znanja – koriste se za pohranjivanje eksplicitnog (organizacijskog i individualnog) znanja poduzeća u repozitorij kojem ovlašteni korisnici mogu pristupati zbog pretraživanja i stjecanja novog znanja, kao i pohranjivati vlastita znanja u bazu,

� ekspertni sustavi - računalni programi za potporu odlučivanju temeljeni na znanju iz nekog specijalističkog područja, sastoje se od baze znanja (izvor znanja o nekom području, najčešće u obliku pravila), baze činjenica (sadrži činjenice o nekom


problemu koji se rješava) i mehanizma zaključivanja (za traženje rješenja problema),programski alati za poslovnu inteligenciju – alati za analitičku obradu podataka iz skladišta podataka, alati za upravljanje performansama poduzeća, upravljačke kontrolne ploče, alati za upravljanje poslovnim procesima i poslovnim pravilima, alati za otkrivanje znanja u bazama podataka (omogućuju stvaranje znanja identifikacijom novih, potencijalno korisnih i razumljivih uzoraka i odnosa meñu podacima u bazama podataka (skladištima podataka) pomoću metoda kao što su klasifikacija, regresija, klasteriranje, modeliranje zavisnosti i analiza vremenskih serija). Zbog velikog interesa i primjene

u praksi, danas na tržištu postoji veliki broj alata za upravljanje znanjem. Zato je pri odabiru alata koji će biti integrirani u sustav upravljanja znanjem poduzeća potrebno razmotriti njihovu namjenu i mogućnosti. U tu svrhu predlaže se metodologija procjene alata prema sljedećim obilježjima (Hlupic, 2003):

� tip alata – za stvaranje, organizaciju i podjelu znanja,

� namjena alata – opća ili specifična, � vrsta znanja – strukturirano, nestrukturirano, � oblik znanja – tekst, brojke, grafika, audio/video

zapis, slike, � metode koje alat koristi za upravljanje znanjem –

razlikuju se ovisno o tipu alata.

Iako neki alati pružaju potporu samo jednoj od četiri faze u procesu upravljanja znanjem, većina proizvoñača pokušava u svoje alate ugraditi više mogućnosti i integrirati što veći broj metoda za stvaranje, organizaciju i podjelu znanja, te tako osigurati njihovu višestruku primjenu. Ovakav pristup u praksi otežava jedinstvenu i preciznu podjelu, vrednovanje i usporedbu alata prema prethodno navedenim obilježjima. Slika 1 prikazuje ulogu informacijske tehnologije u različitim fazama odnosno aktivnostima životnog ciklusa upravljanja znanjem (Alavi i Leidner, 2001). S obzirom da su programski alati za potporu upravljanju znanjem mnogobrojni, treba naglasiti da ova slika prikazuje samo neke od važnijih.

2.3 Uspješnost upravljanja znanjem u organizaciji

Organizacije uvode sustave upravljanja znanjem s pretpostavkom da će rezultat biti porast učinkovitosti, efikasnosti i konkurentnosti. Implementacija sustava upravljanja znanjem može meñutim rezultirati i neželjenim ishodima, kao što su otpori korištenju sustava, dodatni troškovi implementacije, kašnjenje sa implementacijom ili čak odustajanje od implementacije sustava. Da bi primjena strategije upravljanja znanjem bila učinkovita, potrebno je jasno odrediti ciljeve te stvoriti mjerni sustav kako bi se utvrdilo hoće li organizacija imati koristi od uvoñenja sustava upravljanja znanjem (Štulina, 2010). Maier (2007) predlaže tri metode procjene isplativosti ulaganja: � Kvalitativna procjena - ovaj pristup uključuje

subjektivnu procjenu pojedinaca koji mogu biti učesnici, projektni menadžeri ili pojedinci koji nisu uključeni u proces, pojedinci koji imaju tehnička ili poslovna iskustva.

� Kvantitativna procjena - kvantitativne tehnike se zasnivaju na precizno definiranim varijablama koje se mogu neprestano mjeriti te se na taj način dobivaju kvantitativni, objektivni rezultati.

� Polu-kvantitativna procjena - u ovom slučaju osoba, ili što je češći slučaj, grupa pojedinaca, ocjenjuje inicijativu upravljanja na osnovi strukturiranog postupka ocjenjivanja (obično se koristi Likertova skalu od 1-5 ili 1-7). Time se subjektivne prosudbe procjenjivačkoga tima o velikom nizu varijabli kvantificiraju i kodiraju, te se stvara podloga za analizu korištenjem odgovarajućih statističkih metoda.

Premda mnogi smatraju da je utvrñivanje troškova, a posebno procjenjivanje koristi od upravljanja znanjem i sustava upravljanja znanjem još uvijek nerazvijeno područje, u praksi se primjenjuju mnogobrojni modeli mjerenja uspješnosti, a jedan od njih je i Skandia Navigator koji je razvijen u švedskoj osiguravajućoj kompaniji Skandia. Fokus je na praćenju intelektualnog kapitala, a u tu svrhu razvijena je shema tržišne vrijednosti kompanije i kritičnih faktora koji tu vrijednost stvaraju. Na osnovi sheme Skandijine tržišne vrijednosti moguće je analizirati ulogu svakog pojedinog elementa intelektualnog kapitala (Kolaković, 2003). Tržišna se vrijednost poduzeća sastoji od financijskog i intelektualnog kapitala koji se posebno još raščlanjuje na ljudski i strukturalni kapital, zatim na potrošački i

Slika 1: Informacijska tehnologija u životnom ciklusu upravljanja znanjem (Alavi i Leidner, 2001)


organizacijski, inovacijski i procesni, te na intelektualno vlasništvo i neopipljivu imovinu. Udio pojedine vrste intelektualnog kapitala u poduzeću uglavnom ovisi o industrijskoj grani u kojoj poduzeće djeluje i samoj djelatnosti koju obavlja.

3. PRIMJER IZ POSLOVNE PRAKSE: E-INSPEKTOR – SUSTAV ZA INSPEKCIJSKI NADZOR

3.1 Inspekcijski nadzor u Republici Hrvatskoj

Jačanje institucionalne osposobljenosti i meñuresorne suradnje bitan su dio aktivnosti koje se poduzimaju na prilagodbama državne uprave zahtjevima Europske unije, a poslovi inspekcijskog nadzora od posebnog su značaja u već započetim i predstojećim procesima prilagodbe. Usklañeni zakoni, njihova dosljedna primjena, transparentni poslovni procesi te uspostava elektroničke komunikacijske infrastrukture, imperativ su u poduzimanju mjera za dosizanje razine spremnosti Republike Hrvatske za punopravno članstvo u Europskoj uniji.

Nakon što pokrene postupak po službenoj dužnosti, inspektor obavlja inspekcijski nadzor u konkretnoj ustanovi, sačinjava zapisnik o inspekcijskom pregledu, te upravnim rješenjem poduzima mjere (naredbe i zabrane), a potom vrši kontrolu izvršenja, podnosi po potrebi prekršajne i kaznene prijave i podnosi opsežna izvješća nadležnim tijelima. Kao jedino moguće rješenje povećanja efikasnosti inspekcije, da sa znatno manje uloženog truda, uz standardizaciju poslova i poslovne dokumentacije, i sa bitno manje vremena utrošenog na administriranje postigne dvostruko bolje rezultate, jeste informatizacija i tehnološko unaprjeñenje ukupnog rada, a što se može postići upravo uvoñenjem informacijskog sustava.

U svrhu povećanja efikasnosti i efektivnosti rada inspekcijskih službi, te usklañenog djelovanja različitih tijela državne uprave u funkciji inspekcijskog nadzora, razvijen je sustav e-Inspektor kao sustav opće namjene u području inspekcija. Uvoñenje sustava kao podrške u radu službi za provoñenje inspekcijskog nadzora probitačno je s više aspekata, prije svega se ističe olakšan i transparentan rad inspektora i drugih ovlaštenih državnih službenika. Podizanje razine odvijanja poslovnih procesa u funkciji inspekcijskog nadzora neposredno dovodi do uspostave stabilnog okruženja pogodnog za ubrzani gospodarski razvoj. U svom inspekcijskom poslu inspektori vrše neposredan nadzor nad primjenom zakona, podzakonskih akata i drugih propisa, što im svojim brojnim modulima olakšava i ovaj sustav. Sustav je najnovije i u ovom obliku implementiran u oblasti poljoprivredne i veterinarske inspekcije u okviru Ministarstva poljoprivrede, ribarstva i ruralnog razvoja, te će na njima biti fokus ovoga rada. Sustav je u primjeni od 01.01.2010. u poljoprivrednoj inspekciji, te od 01.05.2010. u veterinarskoj inspekciji.

3.2 Sustav e-Inspektor

Sustav e-Inspektor u potpunosti podržava rad inspekcije te je izrañen u skladu s direktivama Europske Unije (za područja različitih inspekcija), a temeljna mu je svrha povećanje efikasnosti i efektivnosti rada inspekcijskih službi. Sustav u potpunosti podržava sve poslovne procese rada inspekcije: planiranje nadzora, upravljanje rizicima, voñenje registra objekata i subjekata nadzora, priprema inspektora za nadzor, rad na terenu (sastavljanje zapisnika, donošenje rješenja, prekršajnih

naloga), upravljanje dokumentima (DMS), popunjavanje i dijagnostiku pomoću kontrolnih lista, automatska veza na pisarnicu, digitalnu arhivu, evidenciju dojave i praćenje izvršenja mjera, upravljačku konzolu (BAM), analizu podataka i izvješćivanje (Infodom, 2009). Za uvoñenje sustava za upravljanje inspekcijskim nadzorima nužno je definiranje standardiziranih postupaka i aktivnosti u poslovnom procesu te njihovo preslikavanje (pridruživanje) u informatizirani poslovni proces (Cetinić et al., 2009). Prema profilu proizvoda, sustav u svojoj strukturi ima osam modula pomoću kojih se može upravljati raznim fazama inspekcijskog posla (Infodom, 2009): � Modul upravnih funkcija i struktura države.

Predstavlja ključni modul u sustavu za obavljanje inspekcijskih poslova. Sadrži detaljan opis nadležnosti-djelokruga tijela državne uprave po upravnim područjima i upravnim funkcijama. Na taj način je različitim subjektima omogućeno koordinirano djelovanje u funkciji inspekcijskog nadzora.

� Modul za imenovanje i razrješenje inspektora. Služi za generiranje pristupa sustavu e-Inspektor kojem su temelj ovlasti koje inspektori imaju kako bi mogli provesti inspekcijski postupak.

� Modul za upravljanje inspekcijskim poslom. Podržava sve faze inspekcijskog posla: evidentiranje, praćenje poslovnih procesa, izvještavanje o nalazima, generiranje izvješća, zapisnika, rješenja i ostalih akata koji se javljaju u pojedinim fazama inspekcijskog posla. Posebni naglasak u ovom modulu stavljen je na precizno izrañene opise poslovnih procesa inspekcijskog nadzora.

� Modul za registriranje objekata inspekcije. Omogućava inspektoru da detaljno definira objekt inspekcije, njegova svojstva i njegovu prostornu lokaciju (administrativnu i GIS-lokaciju). Mogućnost detaljnog opisa objekta pruža preciznost aplikacijske podrške inspekcijskog posla. Praćenje povijesti inspekcije pojedinih objekata inspekcije još je jedna od karakteristika ovoga modula. Funkcionalnosti modula su: administracija slučajeva, izrada zapisnika, izrada rješenja, registriranje žalbi po rješenjima, praćenje izvršenja odreñenih mjera, povijest slučajeva.

� Modul baze znanja. Ovaj modul služi kao napredni ekspertni sustav koji prikuplja znanje o inspekcijskom poslu te u nekim segmentima sustav može predlagati inspektoru moguće mjere-rješenja te pritom pomoći u konačnoj odluci. Ujedno ovaj modul omogućava jedinstveno i ujednačeno postupanje inspektora na cjelokupnom području Republike Hrvatske te skupljanje njihova znanja i prakse u svrhu povećanja efektivnosti rada inspekcijskih službi. Modul sadrži niz izuzetno važnih podataka kao što su: vrste nedostataka, vrste mjera, propisane odredbe – nedostaci i mjere, životni ciklus odredbi propisa po upravnim područjima i tipovima objekata. Modul se konstantno ažurira novim znanjima iz prakse.

� Modul za statistiku. Služi za praćenje dinamike odvijanja inspekcijskih poslova. Omogućava detaljno izvješćivanje o radu službi te izrade statistike rada inspektora i inspekcijskog posla. Sadrži statistiku rada službe i statistiku rada inspektora te omogućava praćenje aktivnosti po područjima i po razdobljima.

� Prekršajni modul. Služi za evidenciju, praćenje i generiranje prekršajnih naloga, zahtjeva za


pokretanje prekršajnog postupka i mandatnih kazni. Prekršajni modul se bazira na bazi znanja u kojoj su pohranjena pravila iz prekršajnih propisa (nedostaci, mjere, propisi).

� Modul za kontrolne liste. Pomoću kontrolnih lista, inspektor ima mogućnost evidentirati i dijagnosticirati stanje inspektiranog objekta. Ovaj modul omogućava inspektoru, da se na temelju evidentiranog stanja prepoznaju vrste nedostataka iz baze znanja, te da ekspertni sustav predloži mjere za uočeno stanje.

U kontekstu upravljanja znanjem od osobite je važnosti činjenica da je sustav e-Inspektor hibridni ekspertni sustav koji se temelji na Rule-based algoritmima zaključivanja (RBR), i to prvenstveno na zaključivanju ulančavanjem unaprijed. RBR mehanizmi zaključuju nad bazom znanja koja se temelji na činjenicama iz pravne regulative (primjer zaključivanja: IF nedostatak (propis) THEN inspekcijska mjera (propis)). Baza znanja sadrži oko 6500 činjenica i 23 000 RBR pravila što ovaj sustav svrstava meñu trenutno najveće ekspertne sustave u Republici Hrvatskoj. Uz RBR mehanizme sustav hibridno kombinira i zaključivanje na temelju sličnih slučajeva (CBR mehanizmi zaključivanja), sa ciljevima indeksiranja najbolje i najlošije inspekcijske prakse. CBR mehanizmi zaključuju nad bazom slučajeva koji se temelje na slučajevima najbolje i najlošije inspekcijske prakse. Kontrolne liste (engl. „check“ liste) koriste se kao dijagnostički alat za dijagnosticiranje situacija (činjenica) koje inspektor može uočiti.

Opisani sustav je u primjeni od 01.01.2010. u poljoprivrednoj inspekciji, te od 01.05.2010. u veterinarskoj inspekciji. Rezultati primjene opisani su i analizirani u poglavlju 4.

4. ANALIZA I EVALUACIJA SUSTAVA E-INSPEKTOR

Špoljar (2010) u svom diplomskom radu detaljno prikazuje funkcionalnosti sustava e-Inspektor te analizira i evaluira rezultate primjene sustava. Pri tome daje odgovore na 3 istraživačka pitanja: (1) Da li je sustav efikasniji u inspekcijskom nadzoru od klasičnog obavljanja inspekcijskog nadzora; (2) Kakvo je zadovoljstvo inspektora sustavom, izraženo kvalitativno i kvantitativno; (3) Kakva je krivulja učenja inspektora u radu sa sustavom, odnosno koliko brzo su inspektori

savladali rad sa sustavom?

4.1 Usporedba kvantitativnih pokazatelja u Sektoru veterinarskih inspekcija

Zbog analize efikasnosti sustava e-Inspektor provedena je kvantitativna analiza kojom je usporeñen broj zapisnika, rješenja i optužnih prijedloga iz razdoblja od 1. lipnja – 1. studenog 2009. godine tijekom kojeg nije korišten sustav za inspekcijske nadzore, sa istim razdobljem 2010. godine u kojemu se koristio ovaj sustav. S obzirom da je svaki inspektor prije inspekcijskog nadzora obavezan kreirati neupravni predmet koji mora sadržavati i zapisnik, kao glavni statistički pokazatelj uzet je broj zapisnika iz godišnje statistike broja pismena za 2009. godinu. Taj broj upućuje na približni* broj obavljenih inspekcijskih nadzora. Takoñer, usporeñivani su i broj rješenja i optužnih prijedloga, koji pokazuju učestalost korištenja upravnih mjera. Inspektor je naime obavezan po uočavanju nedostatka u inspekcijskom nadzoru otvoriti

upravni predmet te izdati rješenje ili optužni prijedlog, te je njihovom usporedbom moguće vidjeti koliko su inspektori bili efikasni u uočavanju nedostataka u inspekcijskom nadzoru. Iako je službena primjena sustava pri Sektoru veterinarskih inspekcija počela 1.5.2010. godine u istraživanje nisu uključeni podaci iz svibnja 2010. godine jer su u prvom mjesecu primjene mnogi od korisnika sustava još uvijek bili u fazi privikavanja te je intenzitet korištenja bio manji, tako da rezultati za taj mjesec ne bi bili reprezentativni u odnosu na isto razdoblje protekle godine.

Analiza je pokazala neznatan pad broja zapisnika od 2,09%, dok se broj rješenja povećao za polovicu svoga prošlogodišnjeg iznosa, odnosno za 56,32% (Slika 3). U Veterinarskom uredu Rijeka broj rješenja se gotovo utrostručio, dok je u Veterinarskom uredu Varaždin porastao za čak 125,15%. Jedini pad je zabilježen na području Veterinarskog ureda Osijek, i to tek za zanemarivih 0,78%. Rast broja optužnih prijedloga bio je zanemariv (1,83%).

* Iako bi broj zapisnika trebao u potpunosti odgovarati broju inspekcijskih nadzora, ponekad se pojavljuje slučaj neispravne inspekcijske prakse u kojoj zapisnik nije prisutan u predmetu inspekcijskog nadzora.

Usporedba broja rješenja

0 500 1000 1500 2000 2500 3000 3500

Veterinarski ured Bjelovar

Veterinarski ured Osijek

Veterinarski ured Rijeka

Veterinarski ured Split

Veterinarski ured Varaždin

Veterinarski ured Zagreb

Ukupno

Broj rješenja

1.6. - 1.11.2010. 1.6. - 1.11.2009.

Slika 3: Usporedba broja rješenja u periodu bez i sa korištenjem sustava

Izvori podataka: Interni podaci Uprave za veterinarske inspekcije i tvrtke Infodom d.o.o.

Usporedba broja zapisnika

0 2000 4000 6000 8000 10000 12000

Veterinarski ured Bjelovar

Veterinarski ured Osijek

Veterinarski ured Rijeka

Veterinarski ured Split

Veterinarski ured Varaždin

Veterinarski ured Zagreb

Ukupno

Broj zapisnika

1.6. - 1.11.2010. 1.6. - 1.11.2009.

Slika 2: Usporedba broja zapisnika u promatranom periodu bez i sa korištenjem sustava

Izvori podataka: Interni podaci Sektora za veterinarske inspekcije i tvrtke Infodom d.o.o.


Uz pretpostavku kako je na objektima inspekcije praksa otprilike jednaka kao i prošle godine, odnosno da se nije u velikoj mjeri povećao broj nedostataka ili prijestupa, povećani broj rješenja govori da je sustav olakšao uočavanje nedostataka u nadzoru, što je sa sobom povuklo i veći broj upravnih mjera za te iste nedostatke. Treba uzeti u obzir kako se sustav još uvijek neprekidno nadograñuje za upotrebu u domeni veterinarske inspekcije, kako neki inspektori još nisu u potpunosti navikli na njega ili su u fazi navikavanja, te kako postoje izvjesni tehnički problemi sa spajanjem na sustav na terenu zbog ograničenosti brzih mobilnih mreža u Republici Hrvatskoj.

4.2 Analiza rezultata anketnog upitnika

Polu-kvantitativna procjena efikasnosti sustava e-Inspektor provedena je korištenjem anketnog upitnika koji je distribuiran korisnicima sustava tijekom ljeta 2010. godine. Popunjavanje upitnika nije bilo obavezno, već je bilo potpuno dobrovoljno sa ciljem prikupljanja sugestija, pohvala i primjedbi korisnika kako bi se moglo raditi na daljnjem poboljšanju sustava. Korisnici su mogli popuniti anketni upitnik na dva načina: (1) popuniti anketni upitnik u obliku Microsoft Word dokumenta koji im je pristigao kao elektronička pošta ili (2) popuniti anketni upitnik u obliku formulara na internom portalu Ministarstva poljoprivrede, ribarstva i ruralnog razvoja. Oba oblika upitnika su unatoč različitoj formi imala potpuno ista pitanja i ponuñene odgovore, te se kao takvi potpuno jednako i vrednuju u daljnjoj statističkoj analizi. Upitnik se sastojao od dva dijela, u prvom su korisnici odgovarali na pitanja odabirom ponuñenih odgovora ili ocjenjivali sustav ocjenama na Likertovoj skali od 1-5, dok je drugi dio bio opisni, te su ovdje korisnici mogli napisati odreñenu količinu teksta po želji. Istraživanje je provedeno meñu inspektorima u Sektoru za poljoprivredne inspekcije i Sektoru veterinarskih inspekcija. Anketni upitnik popunilo je 52 djelatnika iz Sektora inspekcija u poljoprivredi te 29 djelatnika iz Sektora za veterinarsku inspekciju, što daje ukupno brojku od 81 inspektora. Rezultati za ove sektore su obrañeni i analizirani odvojeno i zbirno, a ovdje su odabrani i prikazani samo neki od važnijih rezultata.

Nešto bolje prosječne ocjene su ostvarene kod veterinarskih inspektora, gdje je aritmetička sredina prosječnih ocjena 3,48, dok je kod poljoprivrednih inspektora aritmetička sredina prosječnih ocjena 3,37. Ukupno, aritmetička sredina prosječnih ocjena svih inspektora je 3,41, dok je medijan 3,5 (Slika 4).

Napravljena je geografska analiza prosječnih ocjena (Slika 5), tako da se pokušalo geografski izjednačiti organizacijske jedinice poljoprivredne i veterinarske inspekcije. Tako su „Odjel poljoprivredne inspekcije – Područna jedinica Zagreb“ i „Veterinarski ured Zagreb“

2 2,2 2,4 2,6 2,8 3 3,2 3,4 3,6 3,8 4 4,2 4,4 4,6 4,8 5

Bjelovar

Osijek

Rijeka

Split

Varaždin

Zagreb

Geo

graf

ska

jedi

nica

Sredina pro. ocj.

Ispitanika 4 13 12 6 7 22

Sredina pro. ocj. 3,64 3,3 3,28 3,33 3,23 3,53

Bjelovar Osijek Rijeka Split Varaždin Zagreb

Slika 5: Pregled ukupnih rezultata anketnog upitnika po geografskim jedinicama

Slika 4: Pregled ukupnih rezultata anketnog upitnika


združeni u geografsku jedinicu „Zagreb“; „Odjel poljoprivredne inspekcije – Područna jedinica Split“ i „Veterinarski ured Split“ su združeni u geografsku jedinicu „Split“ i tako dalje.

U svrhu ove analize koristili su se odgovori 64 od ukupno 81 ispitanika koji je odgovorio na anketni upitnik. Zanemareno je 17 ispitanika† koji rade u organizacijskim jedinicama koje nisu geografski odreñene, odnosno u kojima ne mora nužno biti da inspektori rade i djeluju u gradu koji je odreñen kao sjedište organizacijske jedinice. Najslabije prosječne ocjene su ostvarene na području geografske jedinice Varaždin, gdje je aritmetička sredina prosječnih ocjena 3,23 na uzorku od sedam ispitanika. Slijede Rijeka sa 3,28, Osijek sa 3,3, Split sa 3,33, Zagreb sa 3,53, dok je geografsko područje sa najboljim ocjenama ono oko Bjelovara sa 3,64.

Korisnici su prepoznali glavne prednosti ovog sustava, namjeru za transparentnost čitavoga inspekcijskog procesa, ujednačavanje inspekcijske prakse, bazu znanja koja pomaže u velikoj mjeri kod inspekcijskih nadzora te mogućnost bržeg i efikasnijeg obavljanja cjelokupnog posla. Neke od istaknutih prednosti jesu: transparentnost i jednakomjernost postupanja, dostupnost i preglednost kontrolnih lista, brzina pisanja zapisnika i rješenja zbog preuzimanja podataka, pojednostavljenje urudžbiranja. Što se tiče zamjerki, korisnici su većinom istaknuli sporost rada sustava na terenu, iako treba naglasiti da uzrok tome uopće nema veze sa kvalitetom samog sustava, već sa pokrivenošću ruralnih sredina Republike Hrvatske mobilnim internetom. Isporučitelj sustava pokrenuo je aktivnosti za rješavanje ili barem ublažavanje ovih problema povećanjem funkcionalnosti sustava u off-line ili

† Od toga je 16 poljoprivrednih inspektora

izvanmrežnom načinu rada. Korisnici su takoñer prepoznali i nedostatak nekih kontrolnih lista, no na njihovom dorañivanju i usavršavanju isporučitelj rješenja takoñer neprestano radi. Neki od prijedloga korisnika za dodatna poboljšanja su: pojednostavljenje kontrolnih lista, redovitije ažuriranje zakonske regulative, mogućnost mjesta za razmjenu pismena sa ciljem ujednačavanja prakse, konkretnije kontrolne liste sa manjim brojem pitanja i uvoñenje alarma kod gubitka konekcije.

4.3 Kronološka analiza primjene sustava

Cilj ove kvantitativne analize bio je utvrditi kakva je bila krivulja učenja kod inspektora u poljoprivrednoj i veterinarskoj inspekciji, te koliko su se brzo privikli na rad sa sustavom. U tu svrhu, usporeñivao se broj otvorenih predmeta, uočenih nedostataka, rješenja i optužnih prijedloga isključivo u vrijeme korištenja sustava (Slike 6 i 7).

Analiza rezultata je pokazala kako se Sektor veterinarskih inspekcija bitno brže prilagodio radu sa sustavom. Kod broja otvorenih predmeta prethodni zaključak nije bio toliko izražen, te su oba sektora inspekcija pokazala sličan uzorak kretanja gdje se broj novootvorenih predmeta brzo stabilizirao na približno istim razinama. Kod uočenih nedostataka to nije bio slučaj, te je tako poljoprivredna inspekcija pokazala u velikoj mjeri sporiju prilagodbu. Tako je kod njih bilo na primjer 10,75 predmeta po uočenom nedostatku u drugom mjesecu korištenja, dok se taj broj stabilizirao tek u kolovozu pri vrijednosti od oko 3 predmeta po jednom uočenom nedostatku. Kod veterinarske inspekcije je u prvom mjesecu korištenja dolazilo 1,60 predmeta na uočeni nedostatak, dok se već u drugom

Mjesec Broj otvorenih predmeta

Uočenih nedostataka

Predmet / nedostatak

Broj rješenja

Broj optužnih prijedloga

Predmeta / (RJE+OP)

siječanj 351 21 16,71 16 13 12,10 veljača 1225 114 10,75 78 44 10,04 ožujak 1549 188 8,24 116 62 8,70 travanj 1419 276 5,14 100 41 10,06 svibanj 1266 228 5,55 129 49 7,11 lipanj 899 206 4,36 114 27 6,38 srpanj 1259 292 4,31 146 39 6,81 kolovoz 1182 440 2,69 214 46 4,55 rujan 1652 557 2,97 329 84 4,00 listopad 1491 495 3,01 286 55 4,37 Ukupno: 12293 2817 4,36 1528 460 6,18

Slika 6: Kronološki predmet predmeta, uočenih nedostataka, rješenja i optužnih prijedloga u Sektoru za

poljoprivredne inspekcije

Mjesec Broj otvorenih predmeta

Uočenih nedostataka

Predmet / nedostatak

Broj rješenja

Broj optužnih prijedloga

Predmeta / (RJE+OP)

svibanj 1233 770 1,60 317 13 3,74 lipanj 2372 4349 0,55 586 102 3,45 srpanj 1979 3068 0,65 612 74 2,88 kolovoz 1960 2883 0,68 500 38 3,64 rujan 2255 3508 0,64 639 56 3,24 listopad 2444 3754 0,65 705 58 3,20 Ukupno: 12243 18332 0,67 3359 341 3,31

Slika 7: Kronološki predmet predmeta, uočenih nedostataka, rješenja i optužnih prijedloga u Sektoru

veterinarskih inspekcija


mjesecu brojka stabilizirala na oko 0,5 predmeta po uočenom nedostatku. Kod izdavanja upravnih rješenja se primjećuju slična kretanja, te je kod poljoprivredne inspekcije njihov broj ponderiran sa brojem predmeta takoñer stabiliziran tek u kolovozu, dok je kod veterinarske inspekcije stabiliziran već u drugom mjesecu korištenja. Veterinarska inspekcija imala je brže razdoblje prilagodbe i na kreiranje pismena preko sustava te poštivanje upravnih postupaka.

U svakom slučaju, vidljivo je kako su se svi statistički pokazatelji u oba sektora inspekcija stabilizirali u zadnja promatrana tri mjeseca korištenja, te se slobodno može zaključiti kako je razdoblje prilagodbe prošlo i da se u budućnosti mogu očekivati slični rezultate bez naglih odstupanja.

5. ZAKLJU ČAK

Znanje se danas smatra najvećim i najvažnijim organizacijskim resursom zbog čega bi svako ambicioznije poduzeće trebalo preispitati svoje ciljeve i strategije. Poslovati u ekonomiji znanja znači zasnovati svoje poslovanje na upravljanju znanjem, osiguravajući pritom motivirajuću i prijateljsku radnu okolinu u kojoj će svaki član, odnosno djelatnik, pridonositi svojim idejama, vizijama, zamislima, i naravno, svojim znanjem. Prvi korak na putu usmjeravanja organizacije prema upravljanju znanjem predstavlja usvajanje tehnoloških rješenja, odnosno sustava za potporu procesima upravljanja znanjem. Odabir ispravnoga sustava

predstavlja najvažniji potez, jer upravo pravilno odabran sustav može pozitivno rezultirati na cjelokupno poslovanje poduzeća. Tehnoloških je rješenja mnogo, a malo je onih koji odgovaraju svačijim potrebama stoga je potrebno detaljno analizirati poslovanje kako bi se točno utvrdila područja koja se žele unaprijediti.

Jednom kada su uspješno usvojeni, sustavi upravljanja znanjem poduzeću mogu osigurati niz prednosti, počevši od boljih inovacija koje rezultiraju kvalitetnijim proizvodima i uslugama, pa sve do ubrzavanja radnih tijekova i smanjenja izdataka za odreñene poslovne aktivnosti. Uspješno uveden i na odgovarajući način primijenjen sustav upravljanja znanjem poduzeće će pozicionirati korak ispred konkurencije, osiguravajući im na taj način stratešku prednost, a s druge strane zaposlenicima olakšavajući obavljanje složenih radnih zadataka.

U ovom radu prikazan je primjer implementacije sustava za upravljanje znanjem e-Inspektor u Sektoru za veterinarske inspekcije i Sektoru za poljoprivredne inspekcije Ministarstva poljoprivrede, ribarstva i ruralnog razvoja Republike Hrvatske. Opisane su najvažnije funkcionalnosti sustava, analizirani su i evaluirani rezultati njegove primjene. Uz brojne prednosti i pozitivne rezultate primjene sustava, identificirani su i odreñeni nedostaci, kao i mogućnost unaprjeñenja sustava. Ovaj primjer mogao bi poslužiti hrvatskim poduzećima i institucijama javne uprave kao poticaj za pokretanje projekata upravljanja znanjem i primjenu sustava za upravljanje znanjem u poslovanju.

Literatura:

1 Alavi, M., Leidner, D.E. (2001), „Review: Knowledge management and knowledge management systems: conceptual foundations and research issues“, MIS Quarterly Vol. 25, No. 1, March 2001.

2 Bosilj Vukšić, V. i Kovačič, A. (2004), „Upravljanje poslovnim procesima“, Sinergija, Zagreb.

3 Bosilj Vukšić, V., Milanović, Lj., Gombašek, J. (2010), „Uloga informacijske tehnologije i drugih čimbenika u upravljanju znanjem“, Zbornik stručne konferencije 15. HROUG 19-23.10.2010., Rovinj, Hrvatska, 3-14.

4 Cetinić T., Bobinac S., Kučera N. (2009), “Priručnik za korištenje aplikacijskog sustava e-Inspektor”, Infodom d.o.o.

5 Gallupe, B. (2001), „Knowledge management systems: Surveying the landscape“, International Journal of Management Reviews, 3: 61–77.

6 Hlupic, V. (2003), „Knowledge and Business Process Management“, IDEA Group Publishing.

7 Infodom d.o.o. (2009), “E-inspektor product sheet”.

8 Kolaković, M. (2003), “Teorija intelektualnog kapitala“, Ekonomski pregled, 54 (11-12) 925-944.

9 Maier, R. (2007), „Knowledge management Systems – Information and Communication Technologies for Knowledge Management“ , Springer-Verlag.

10 Špoljar, A. (2010), diplomski rad: „Sustav za inspekcijski nadzor i kontrolu temeljen na bazi znanja“, Ekonomski fakultet Sveučilišta u Zagrebu, mentor: prof.dr.sc. Vesna Bosilj Vukšić.

11 Štulina, H. (2010), diplomski rad: „Primjena sustava upravljanja znanjem u poslovanju“, Ekonomski fakultet Sveučilišta u Zagrebu, mentor: prof.dr.sc. Vesna Bosilj Vukšić.

12 Wickramasinghe, N. i von Lubitz, D. (2007.), Knowledge – Based Enterprise: Theories and Fundamentals, London: Idea Group Publishing.

Podaci o autorima:

prof.dr.sc. Vesna Bosilj Vukši ć Ekonomski fakultet - Zagreb Trg J.F.Kennedya 6 10000 Zagreb Tel 01/2383-333 Fax 01/2335-633 e-mail: [email protected] Vesna Bosilj Vukšić je redovita profesorica na Katedri za informatiku Ekonomskog fakulteta Sveučilišta u Zagrebu i nositeljica nekoliko predmeta iz područja upravljanja poslovnim procesima i znanjem. Područje njezinog istraživanja je upravljanje poslovnim procesima i znanjem, te razvoj poslovnih informacijskih sustava. Voditeljica je znanstvenog projekta Ministarstva znanosti, obrazovanja i športa RH i članica meñunarodnih znanstveno-istraživačkih projekata.


Vesna Bosilj Vuksic is a professor of Business Process Management, Simulation Modelling and Business Computing at the Faculty of Economics and Business, University of Zagreb. Her current research interests are in business process management and information systems development. She participates actively in research within the framework of the Ministry of Science and Technology's scientific projects, she is a leader of the project “Information, process and knowledge management systems” funded from the Croatian Ministry of Science, Education and Sports” (2007-) and is a member of international scientific research projects. Vesna Bosilj Vuksic has been a consultant for business process change on several projects in public and private sector. Helena Štulina Helena Štulina završila je Sveučilišni diplomski studij Poslovne ekonomije u Zagrebu, smjer Menadžerska informatika i stekla akademski status magistra ekonomije. Tijekom studija najviše je interesa pokazala za područje upravljanja znanjem, stoga je kao temu diplomskog rada odabrala temu “Primjena sustava upravljanja znanjem u poslovanju”. Trenutno je u potrazi za prvim zaposlenjem.

Adrian Špoljar

Adrian Špoljar je zaposlen u Izvršnom centru za sustave upravljanja znanjem tvrtke Infodom d.o.o. Trenutno aktivno sudjeluje na projektima koji uključuju implementaciju sustava e-Inspektor (ekspertni sustav za inspekcijski nadzor) i eGOP (sustav za elektronsko upravljanje dokumentima). Završio je preddiplomski i diplomski studij na Ekonomskom fakultetu u Zagrebu, smjer „Menadžerska informatika“.


EKONOMIKA CLOUDA

ECONOMICS OF THE CLOUD COMPUTING

Berislav Bio čić, Draško Tomi ć, Dario Ogrizovi ć

ABSTRACT:

Cloud computing has its root deep into ground and in the market. The evolution of cloud computing is one of the major advances in the computing area as well as in economics of using computing. There are three major technologies which represent cloud computing: Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS) and Infrastructure-as-a-Service (Iaas). In our example we discuss pros and cons of implementing PaaS or SaaS. While there are quite a few papers covering technical aspects of cloud computing technologies, this paper will have focus on economics of the cloud. In this paper we will try to explain which criteria should be considered when deciding to move or not to move to cloud. There is also general view on Return on Investment shown which takes into account various intangible impacts of cloud computing, apart from cost. These impacts include better flexibility, scalability and faster time to market.

I. INTRODUCTION

Cloud computing is one of the technologies which is not new as one could think of. The technology has its roots in late 1960s in mainframe era when services were delivered through shared computing. Some authors go to the point in which they define cloud computing as a 5th utility along with water, electricity, gas, and telephony [1]. In general, cloud computing represent delivery of computing resources to number of users through network resources like LAN, WAN, Internet etc.

The main technology around cloud computing is virtualization which allows delivery of resources on demand and in the end one can call this kind of service utility computing.

Behind the scenes, economy of the cloud is just another way of presenting computing resources to clients in the way that helps them better align their needs and budgets. Users of IT resources become customers of cloud providers which should guarantee some level of availability.

Regarding costs and calculations about Return-on-Investment and total cost of ownership one should say there are not well defined metrics in general, i.e. every cloud candidate should stick on their own metrics and formula.

Gartner expects that cloud computing will be a $150 billion business by 2014, also small and medium businesses are expected to spend over $100 billion on cloud computing by 2014.

In general, cloud computing represents a convergence of two major trends in information technology: IT efficiency, i.e. higher utilization of virtualized computing power; and business agility which leads to faster time-to-market for new products.

II. ADVANTAGES OF CLOUD COMPUTING

Cloud computing advantages can be summarized in the following facts [2]:

1. It can lower initial costs for start-up companies and for traditional companies which own IT resources.

2. It provides IT resources immediately and enables scalability according to needs of user or customer. This is especially useful during peak times of the year when there is a need for additional resources which are not needed in other parts of the year. Users of cloud services have just operative expenses and capital expenses are minimized as much as possible.

3. Usage of cloud computing services can foster innovation because there are no huge upfront costs for test and development environments.

4. Cloud computing will boost new markets which are already present in other business fields. This includes cloud brokers which will be able to sell and buy resources like brokers do today on stock markets.

5. Cloud computing also makes possible parallel batch processing which allows users to analyze terabytes of data for small periods of time and small costs; business analytics that can use the vast amount of computer resources for huge data warehousing

III. CORE TECHNOLOGICAL CONCEPTS AND TERMINOLOGY OF CLOUD COMPUTING

As stated above, virtualization is the main technology concept which enables cloud computing. Virtualization hides the physical characteristics of a computing platform from the users, instead presenting an abstract, emulated computing platform. Emulated platforms can be better managed and utilized which leads to lower upfront and operational costs (smaller data center). Even though virtualization is known from the 1960s, it was not so widespread till nowadays because of the insufficiency in network resources like network speeds and throughput of network equipment.

From an end-user's perspective, the cloud computing models differs from one another in the services are supposed to be delivered. The most commonly heard term perhaps is Software as a Service or SaaS, in which the application runs on the cloud, eliminating the need to own IT infrastructure expect dumb terminal for users. Examples of SaaS include applications such as


Salesforce, Netsuite or Google Apps but the most known are personal applications such as GMail, Facebook and Twitter. Platform as a Service or PaaS represents the development and deployment of applications without the cost and complexity of buying and managing the underlying hardware and software layers. Examples of PaaS include Microsoft's Azure Services Platform, Salesforce's Force.com, Google App Engine, Amazon's Relational Database Services and Rackspace Cloud Sites. The third model of cloud computing is Infrastructure as a Service or IaaS. In this model storage and compute capabilities are offered as a service. Amazon's S3 storage service and EC2 computing platform, Rackspace Cloud Servers, Joyent and Terremark are some most known examples of IaaS [2].

IV. INFRASTRUCTURE AS-A-SERVICE

The Infrastructure-as-a-Service (IaaS) as a model of cloud computing service delivery represents hardware platform services. This kind of service enables scaling of bandwidth, memory, computing power and storage. The pricing is done according to leased computing power, bandwidth and storage. Users of this platform can sign a contract with service provider for the certain amount of time or can rely on pay-as-you go model. The best side of this model is pricing compared to traditional way of computing. User pays just resources they use [3].

In this model, user uploads their virtual machines to cloud or rarely uses physical instances of cloud computing resources. User is responsible for everything except hardware maintenance. This means that user has to prepare application environment in their virtual machines. It includes taking care that all software instances are licensed and installed in a proper manner. The responsibility of cloud provider is to insure availability of hardware resources. It is up to service provider to provide tools for performance monitoring and management. These tools should be able to add additional resources if needed. User should be able to make their own templates for production environment as well as for test and development. In order to be able to provide some every day templates, these tools should be able to offer self-service portal with usual templates with built-in chargeback capabilities. Chargeback capabilities are used as a metrics for pricing which is one of the reasons someone will decide to use or not to use cloud services. The most prominent provider of these tools together with underlying hardware is HP’s BladeSystem Matrix [4].

V. SOFTWARE-AS-A-SERVICE

The Software-as-a-Service (SaaS) concept has been presented as an improved version of the Application Service Provider (ASP). In this model cloud provider host and provide access to a software application over a network, mostly Internet. SaaS provider typically hosts and manages a given application in their own data center and makes it available to multiple tenants and users over internet connection. SaaS services are offered to enterprises customers, but typically focused on SMEs (Small and Medium Enterprises). On the other hand there are consumer-oriented SaaS services which are offered publicly. These services include hosting, news feeds, storage, presentations, etc. (e.g. Dropbox) [5].

Opposite to IaaS model, SaaS model of delivery includes licenses at their expenditure. This means that SaaS

service provider own licenses and is responsible for application implementation in the cloud. This certainly adds additional cost to service but is more cost effective because SaaS provider has better negotiation position than single software user.

The service itself is charged as a subscription fee for certain amount of time. It can be implemented in either pre-paid or in pay-as-you go basis. Failing to pay or renew subscription means that user is not able to access service.

Customer provided services are often not charged for initial services which are supported by advertisements. On the other hand, any upgrade from initial service is charged. This is especially present with storage space providers (Dropbox, Amazon).

VI. PLATFORM-AS-A-SERVICE

The Platform-as-a-Service (PaaS) is a model of cloud services primarily used by software suppliers that want to focus on the development cycle and monetizing of new applications without need to invest in the maintenance of the infrastructure needed for deployment. This platform consists of infrastructure software and typically includes database, middleware and development tools. Services provided by PaaS enable professional and non-professional developers to build their product on the functionalities of an existing SaaS (e.g. Force.com) or develop new web applications (e.g. Google App Engine). PaaS is characterized by built-in scalability, reliability and security; built-in integration with web services and databases; support for collaboration within developers community; and mostly has user’s forum implemented for comments and service improvements. PaaS provides the ‘‘runtime environment” to run external applications inside the platform itself. PaaS also has its own application programming interface (API) to access data and services running on the platform and plug-in API to inject functionality into the platform [5].

Charging mechanism for PaaS services include subscription fee for test and development functionalities on one side and on the other side the service is charged according to the actual time users spend in interaction with application.

Some of the platforms offer application environment as a marketplace on which application developers can offer their applications for a certain fee.

PaaS platforms usually have implemented revenue share mechanism between application developers and platform owners. Usually platform owners receive up to 15% of the revenue generated by application and developers the rest. In other known cases, application developers must pay for the access to platform.

The greatest difference between PaaS and SaaS is in the revenue model. PaaS is built in the way that there is a two way money flow: from user to platform owner and from platform owner to developer. In SaaS there is just a flow from users to SaaS platform owner.

VII. CRITERIA FOR POSSIBLE CLOUD ADOPTION

From this point it is very hard to make standardized formula and criteria for calculating ROI. Key characteristics or variables which should be taken into account when calculating possible ROI for cloud adoption include [6] [7] [8]:


1. Size of IT resources 2. Utilization of existing resources 3. Sensitivity of data 4. Availability of services 5. Data lock-ins and data transfers 6. Performance unpredictability 7. Software licensing 8. Legal terms and conditions

Size of IT resources is measured by the number of existing computing resources, storages, databases and network equipment.

In connection with IT resources, there is also pattern of utilization of existing resources. It is known that main technique for cloud computing, virtualization makes this utilization as high as 90% in contrary to 15% for traditional IT environment.

For some security reasons data should be under direct control of the owner of data. This means that it cannot be moved to every cloud provider. There must be some kind of agreement between cloud provider and cloud user which will determinate where data can sit in the cloud. European Union regulative insists that any cloud provider in the EU states must have one of their data centers on the soil of one of the EU member states.

When considering cloud as an alternative to the owned IT resources, one must take into account availability of cloud service. It is up to users to decide if they can bring additional point of failure in the IT environment presented by network connectivity. In recent days there has been number of outages of cloud platforms. Amazon had unavailability of their users for at least six hours and some customers have experienced problems even for two days. This raises question about the availability of cloud platforms and additionally gives bad reputation for certain provider. Also, one should ask themselves if they need two different cloud providers for running their services to be safe of the failure.

What about Distributed Denial of Service (DDoS)? There has not been a lot of this threats but it exists. It can really threaten one’s operations if successful. The pros of cloud are that it can scale-up easily and smoothly, and most importantly fast enough to defend the service against attack.

Regarding data lock-in one should be fair enough and say that cloud providers will try to give initial data storage for as low as possible amount and then try to harvest for additional resourced. Additional cost can arise from transfers of data to and from the cloud which could be very high if there is a lot data to be transfers. In one point of time, Amazon S3 was so pricy that it was cheaper to send disks full of data by snail mail to Amazon than to upload it to Amazon through web interface.

Performance unpredictability can be a reason to accept and not to accept cloud services. It means that cloud providers can provide faster scale-up of resources when user realizes that it needs data. But, it usually happens that most of users need additional resources in the same time. What usually happens if bottleneck occurs? A bottleneck is solved easily: those who have high value Service level agreement (SLA) will have access to additional recourse; other will have to wait for their availability.

Software licensing adds a lot on cost structure of every company which has its own IT infrastructure. Since cloud providers depend mainly on open source software it is questionable if they will be able to provide commercial

services due to a different licensing. As stated before, cloud providers have better negotiation position for software licenses than individual customers because of the economy of scale.

Legal terms and conditions are thing which are normally left for some others in IT community. But these things should be addressed in a proper way. All service level agreements and resource availability should be signed. Even if user does not opt for cloud services, some of sample cloud service agreements should help them to realize importance of their applications and data [8].

The concept which was developed by [7] incorporates most of previously mentioned facts.

Table 1. Weight Factors for cloud adoption calculation [7]

Calculations: Largeness value: L= NoS *CNoS + NoC * CNoC + AR * CAR (1) Average Usage value: AU=ToS*CToS (or) ToP*CToP+(4 − SCB)*CSCB (2) Peak Usage value: PU=DoP*CDoP+PbA*CPbA (3) Value of Workload Variability: WV=PU*CPU+AU*CAU+ADH *CADH (4) Value of Data Sensitivity: DS = SoD (5) Value of Criticality: C = CWD (6) Suitability index = L*CL + WV*CWV+DS*CDS*ADH+ C × CC × (65 − L) (7) Where,


NoS = Number of Servers CNoS = Credit of Number of Servers NoC = Number of Countries it is Spread Across CNoC = Credit of Number of Countries it is Spread Across AR = Annual Revenue CAR = Credit of Annual Revenue SCB = Size of Customer Base CSCB = Credit of Size of Customer Base ToS = Type of Service CToS = Credit of Type of Service ToP = Type of Project CToP = Credit of Type of Project DoP = Duration of Peak CDoP = Credit of Duration of Peak PbA = Peak by Average CPbA = Credit of Peak by Average CPU = Credit of Peak Usage CAU = Credit of Average Usage ADH = Amount of Data Handling CADH = Credit of Amount of Data Handling CWV = Credit of Work Variability CC = Credit of Criticality.

The example shows how difficult is to calculate cloud adoption criterion. This example confirms our thesis that there cannot be one standardized formula for cloud adoption. All formulas are not applicable for every IT market; smaller markets may even not by default be candidates for cloud adoption.

When trying to find out if one’s environment is a candidate for cloud adoption, some ROI calculation

should be done. There should be at least two approaches. First one is based around adoption of private cloud and the second one is based on public cloud.

The first one seems to be easier to calculate. If there is IT environment, initial cost can be smaller and therefore ROI should be better.

If the user decides to use public cloud services there are no initial costs and investments and the ROI should be even better. But there are some hidden costs which should also be taken into account. For example, data migration could be so pricy and could be prevailing in the decision not to move to cloud [6].

VIII. CONCLUSION

Economics of cloud computing shows that hype which exists around it will soon disappear. A lot of regulations still need to be defined. One specific thing which should be done is interoperability between different cloud providers. Recent downtimes of the greatest cloud providers Amazon and Microsoft Azure show how

vulnerable is existing concept. In the meanwhile lots of users of traditional IT environments are waiting for cloud services to become more mature in aspects like availability, flexibility and scalability.

There is no doubt that cloud computing will change IT world. It seems that giants like IBM, HP, EMC and Cisco started to lose their leading roles in IT development and former niche players and even bookstores like Amazon, Google and Microsoft are becoming leaders and drivers of IT industry.

References:

1 R. Buyya, C.S. Yeo, S. Venugopal, J. Broberg, I. Brandic, Cloud computing and emerging IT platforms: vision, hype, and reality for delivering computing as the 5th utility (2009)

2 S.Marston, Z. Li, S. Bandyopadhyay, J. Zhang, A. Ghalsasi, Cloud computing — The business perspective, Decision Support Systems 51 (2011)

3 S.Bhardwaj, L. Jain, S. Jain, Cloud Computing: A Study of Infrastructure as a Service (IAAS), International Journal of Engineering and Information Technology (2010)

4 www.hp.com/go/bladematrix, accessed on Feb 01 2011.

5 V. Gonçalves, P. Ballon, Adding value to the network: Mobile operators’ experiments with Software-as-a-Service and Platform-as-a-Service models, Telematics and Informatics 28 (2011)

6 M.Armbrust, A. Fox, R.Griffith, A. D. Joseph, R. H. Katz, A. Konwinski, G. Lee, D. A. Patterson, A. Rabkin, I. Stoica, M.Zaharia, Above the Clouds: A Berkeley View of Cloud Computing, February 10, 2009

7 S.C. Misra, A. Mondal, Identification of a company’s suitability for the adoption of cloud computing and modelling its corresponding Return on Investment, Mathematical and Computer Modelling 53 (2011)

8 D. Svantesson, R. Clarke, Privacy and consumer risks in cloud computing, Computer law & security review 26 (2010)

Podaci o autorima:

Berislav Bio čić, Draško Tomi ć, Hewlett-Packard Croatia, Zagreb, Croatia

Dario Ogrizovi ć Center for advanced computing and modeling Faculty of Maritime Studies, Rijeka, Croatia

My profession.

My organization.

My IEEE.

Join a community of more than

365,000 innovators in over 150

countries. IEEE is the world’s

largest technical society, provid-

ing members with access to the

latest technical information and

research, global networking and

career opportunities, and exclu-

sive discounts on education and

insurance products.

Discover the benefits

of IEEE membership.

Join todaywww.ieee.org/join

Zbornik konferencije CASE23 - Case doo

Documents

Transcript of Zbornik konferencije CASE23 - Case doo