ORGANIZATOR

CASE d.o.o.

ORGANIZACIJSKI I PROGRAMSKI ODBOR

TOMISLAV BRONZIN mag. ing. el.

ANTE POLONIJO

MISLAV POLONIJO

IVAN POGARČIĆ mr.sc.

ZLATKO SIROTIĆ univ.spec.inf.

ZLATKO STAPIĆ mag.inf.

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, 2015

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., Antuna Barca 12, 51000 Rijeka tel: 051/217-875, tel/fax: 051/218-043, e-mail: case@case.hr, internet: www.case.hr

2 UVOD

27. KONFERENCIJA CASE - UVOD

Prvi dan – CASEdev

Panel: UNAPREĐENJE PROCESA (moderator Miroslav Mađarić, KBC Zagreb)

Konferencija CASE već 27 godina bavi se razvojem softvera, tj projektiranjem IS i aplikacija. Posljednjih desetak godina uspješno se širi agilni pristup razvoja (Agile). Najpoznatija i najraširenija metoda razvoja SW je Scrum. Scrum se preporuča svakome tko se bavi aktivnim projekt managementom u razvoju SW. Smatra se da veći dio Agile-a je zapravo Scrum, tako da se ta dva pojma i brkaju i poistovjećuju.Scrum je fokusiran samo na software development dok Agile ima potencijalno daleko širu primjenu. Iako ga njegovi tvorci nazivaju frameworkom, Scrum je zapravo jedna od metoda kojom se provodi Agile. Scrum je svoju popularnost stekao vjerojatno što ga je jednostavno razumjeti ali ga je u isto vrijeme teško savladati.

Kako razviti informatički sustav za prihvaćanje ljudskog pitanja korisnika u prirodnom jeziku i davanje točnih odgovora (i time osigurati rješenje poznatog Turingovog testa za mjerenje umjetne inteligencije). Takav sustav je dio većega sustava za upravljanje znanjima temeljenoga na konceptualnom okviru Node of knowledge (NOK). Prikazati ćemo dio NOK konceptualnog okvira i u sklopu njega novu metodu prikaza znanja iskazanoga tekstom – formalised NOK (FNOK). Dakle kako nad FNOK formaliziranim znanjem uspostaviti modul za prihvaćanje korisničkih pitanja na prirodnome jeziku i na prirodnome jeziku davati odgovore?

Kako unaprijediti poslove procese? Razvojem IT industrija je dobila priliku dodatnu mogućnost. Ali ako analiziramo učinke IT na unapređenje poslovnih procesa do kakvih zaključaka dolazimo? Zašto proizvodna industrije najmanje koristi IT u svojoj core djelatnosti (2% ulaganja) dok recimo servisna industrija (6-9% ulaganja)? Zašto je autoindustrija efikasnija od drugih iako manje ulaže u IT podršku procesima? Želimo prikazati i objasniti smjernice u pristupu unaprjeđenju poslovnih procesa na temelju originalnog Toyota Production System (R) - KAI-ZEN (continious change); povezati TPS metodu s modelom upravljanja tvrtkom i sa načinom primjene informacijskih tehnologija.

Sustavi za verzioniranje već dugo predstavljaju sastavni dio razvojnog procesa. Međutim, uporaba takvih sustava i izbor odgovarajućeg načina rada u početku može predstavljati izazov. Programeri i timovi često ne ulože dovoljno vremena da upoznaju mogućnosti ovih sustava, što na kraju rezultira time da ne iskoriste mogućnosti sustava za verzioniranje u punom smislu. Pokušati ćemo doprinijeti rješavanju ovog problema identificiranjem i sistematiziranjem korisnih alata i dobrih praksi za korištenje sustava za verzioniranje. Rad se temelji na Git-u, jednom od najpopularnijih sustava za verzioniranje.

Panel: PRIMJENA CLOUDA (moderator: Mladen Maras, Combis)

Današnje tvrtke imaju pred sobom dva izazova: smanjiti troškove poslovanja i povećati svoju konkurentnost. Jedan od najboljih načina povećanja konkurentnosti je upotreba informatičke tehnologije (IT). Kako uz minimalne troškove male i srednje tvrtke mogu dobiti informatičku infrastrukturu koju imaju velike tvrtke, a da za to (relativno) malo plate? Odgovor na to pitanje je CLOUD i primjena Office365 skupa servisa koji unapređuje poslovne procese u malim, srednjim i velikim organizacijama. Veliki broj korisnika Microsoft Office proizvoda je dovoljan razlog zašto razmisliti o razvoju Apps for Office aplikacija, a posebno za Office365, budući je sve više korisnika koji Office koriste na Apple i Android platformi, bilo kao nativne ili web (on-line) aplikacije.

Razvoj poslovno kritičnih rješenja za velike sustave uvijek je predstavljao poseban izazov, a postavljanje takvog rješenja na cloud (interni ili eksterni) otvara cijeli niz tehničkih, pravnih i poslovnih problema.

U predavanju će biti govora o svim tim problemima i rješenjima istih u stvarnim poslovnim situacijama i iskustvima iz prakse. Višejezičnost, Integracijski procesi, samoinstalacija i konfiguracija, podržavanje različitih državno pravnih pravila i postupaka samo su neki od izazova koje treba planirati u projektiranju i izvedbi poslovnih rješenja u oblaku za ovaj najzahtjevniji segment tržišta

Izlaskom nove verzije Kinect for Windows v2 senzora i pripadajućeg SDK, Microsoft omogućio razvojnim inženjerima mogućnost kreiranja Windows Store aplikacija koje će koristiti Kinect senzor. Navedeno je omogućeno kroz razvoj tzv. Univerzalnih Windows aplikacija i za Kinect for Windows, čime se Microsoft još bliže primaknuo obećanom - kreiranju jedinstvene razvojne platforme za sve Windows uređaje i popularizaciji sintagme: "Devices-and-Services"? Kako napraviti Windows Store aplikaciju koja koristi Microsoft Kinect v2, te kako je uklopiti u Univerzalnu Windows aplikaciju? Kako iskoristiti Microsoft Azure u pojedinim scenarijima ovakvih aplikacija te širenje i na Linux i na Mac okolinu? A sve ovo nosi nam brže izvršavanje, potpuno modularnu gradnju gdje uzimamo samo ono što i trošimo, izvršavanje u istim uvjetima na razvojnim i serverskim računalima i ubrzani "in-memory compile" razvoj.

Internet stvari (IoT) obuhvaća različite aspekte povezanosti života; od pametnih domova i gradova pametnih automobila i cesta do uređaja koji prate ponašanje pojedinca te koristi tako prikupljene podatke za usluge davanja (push usluga). Cisco predviđa 50 milijardi uređaja spojenih na Internet do 2020. godine. McKinsley Global Institute predviđa milijardu uređaja spojenih na Internet do 2025. godine, te mobilni telefon kao finalnu platformu aplikacija koje povezuju sve "stvari". Da bi IoT zaživio kao globalni eko sustav, on mora biti siguran, i što je jednako važno, transparentan za javnost. Širenje IoT-ia je uvjetovano povjerenjem

UVOD 3

javnosti u očuvanje privatnosti pojedinaca tj. osobnih podataka za vrijeme života tih podataka.

Upravo se dovršava Strategija e-Hrvatska 2020. Cilj je stvaranje IS države za pružanje elektroničkih usluga na nacionalnoj i na europskoj razini. Strategija se odnosi na tijela javnog sektora s obzirom da su ona obuhvaćena Zakonom o državnoj informacijskoj infrastrukturi. U fokusu ove Strategije je osigurati interoperabilnost između postojećih i novih IKT sustava u javnoj upravi, ujedno eliminirajući dupliciranje njihovih funkcionalnosti. Ostvarenje ciljeva mjerit će se na temelju postotka građana i tvrtki koje koriste javne e-usluge, kao i razinom zadovoljstva korisnika. Ciljevi: Poboljšana poslovna produktivnost javne uprave korištenjem IKT-a i novih vještina.

Podaci u vlasništvu javne uprave čine resurs koji zahtijeva učinkovito upravljanje. Korištenje vjerodostojnih, ažuriranih, umreženih, kompetentno prikupljenih i obrađenih podataka čine temelj za učinkovito državno upravljanje i donošenje politika temeljeno na činjenicama. Svi podaci moraju biti obrađeni u skladu sa sigurnosnim mjerama uzimajući u obzir privatnost i povjerljivost. Direktiva EU iz 2013 nalaže da se podaci (koja objavljuju tijela javne vlasti) objavljuju u formatu strukturirane datoteke kako bi otvorena ili zatvorena SW aplikacija mogla izvući podatke (i njihovo „strojno čitanje“). Portal data.gov.hr omogućuje: pristup setovima podataka (u njihovom originalnom obliku - zasad 102) koje objavljuju hrvatska tijela javne vlasti/institucije, distribuciju tih podataka i katalogiziranje javnih aplikacije koje koriste te podatke. U Hrvatskoj već postoji 30-40 aplikacija na tržištu (App store i Google Play, …) namijenjene npr. turistima (kampovi, vremenske prognoze, promet, zdravstvo,..). Osobni podaci nisu dostupni (jer su zakonom zaštićeni). Osobni podaci se mogu koristiti kao statistički podaci ili ako su anonimizirani (zaštićen je identitet).

1. Radionica: "Unapređenje procesa" razmatrala bi primjenu TPS metodologije na konkretnom vrlo uspješnom primjeru iz servisne industrije primijenjeno u Hrvatskoj. Prikazano ćemo kako u 6 mjeseci povećati produktivnost 3 puta, kako osigurati održivost uvedenih promjena u poslovanje i pri tome povećati zadovoljstvo djelatnika. Poseban naglasak će biti o načinu primjene IT podrške u cilju ostvarenja ovih rezultata.

Kako je u ovom konkretnom slučaju primijenjena ORIGINALNA TPS metoda, a ne njene zapadna inačica Lean Six SIgma, pojasnit ćemo ključne razlike između ove dvije metode, odnosno dat ćemo jasan odgovor na pitanje "Moraš li biti Japanac da bi primijenio TPS?" U diskusiji ćemo pojasniti je li TPS primjenjiv u konkretnim slučajevima u Hrvatskoj - zdravstvo, proizvodnja, javna uprava, državna uprava, komunalne usluge i slično.

2. Radionica: Cloud usluge izlaze iz faze tranzicije i postaju (logičan) izbor u kompanijama koje broje od jednog do nekoliko desetaka, stotina, ili čak i više, zaposlenika. Druga radionica će obraditi temu: „Upravljanje IT uslugama u Cloud-u koristeći ITIL najbolju praksu“. Masovnom pojavom i upotrebom cloud usluga slijede i mnoga pitanja a sežu u sferu upravljanja IT uslugama u cloud-u:

- Kako definirati IT usluge u cloudu za razliku od konvencionalnih rješenja?

- Da li se isplati prijeći na cloud usluge?

- Kako iskoristiti postojeće znanje i iskustvo u upravljanju IT uslugama?

- Kako aplicirati najbolju praksu na cloud usluge?

- Što je ITIL i što on ima s cloud uslugama?

- …

Dakle dođite na radionice da čujete odgovore na ta, kao i na mnoga druga pitanja.

Drugi dan CASEmobile

Panel: RAZVOJNE PLATFORME (Moderator: Andrej Radinger, Mobendo)

Višestruko nasljeđivanje klasa je dugo vremena neopravdano držano kao kompleksno i nepotrebno.

Vjerojatno je jedan od glavnih razloga taj što je višestruko nasljeđivanje u jeziku C++ relativno loše riješeno.

Višestruko nasljeđivanje u C++ uvedeno je naknadno, 1989., tj. nije uvedeno od početka. Na temelju takvih loših iskustava, dizajneri jezika Java (a poslije i C#) odlučili su da ne podrže višestruko nasljeđivanje klasa. No, jezik Eiffel je imao višestruko nasljeđivanje od početka (1986.) i smatra se da od svih OOPL-a najbolje podržava višestruko nasljeđivanje. U Javi 8 krenulo se u pravcu uvođenja višestrukog nasljeđivanja klasa. Prikazati ćemo kako je višestruko nasljeđivanje podržano u jezicima Eiffel, C++, Scala i Java 8.

Xamarin je u proteklim godinama davao naglasak na razvojne alate za mobilne platforme za c# (.net) programere. Budući da su alati ušli u stabilnu fazu razvoja, težište Xamarina se pomiče prema cjelokupnom procesu razvoja, od designa, preko razvoja / implementacije do automatiziranog procesa testiranja. U sklopu ove prezentacije biti ce opisan kompletan razvojni proces mobilnih aplikacija kako je to zamišljeno u Xamarin-u.

Razvoj za sve Windows uređaje konačno je omogućeno dolaskom Windows 10. Razvoj univerzalnih aplikacija, bez potrebe da za svaku platformu imamo zasebni projekt, ili dijeljeni projekt. Prikazati ćemo osnove razvoja za Windows 10 za sve uređaje (tablet, PC, Phone, XBox), novitete u Windows 10 razvojnim alatima, nove kontrole, unificirano objavljivanje aplikacija na Windows i Windows Phone Store, te migraciju postojećih aplikacija na Windows (Phone) 10. Moći ćete vidjeti uživo razvoj univerzalnih Windows 10 aplikacija u Visual Studiu 2015

Aplikacije i podaci dostupni su na svim vrstama i oblicima mobilnih uređaja i koristimo ih ma gdje god se nalazili. Svi su spojeni, svi su "online", tvrtke i korisnici, zaposlenici i obitelji, učenici i učitelji ... I sve je isprepleteno: platforme, proizvođači, programske okoline. Od razvojnih timova očekuje se da izrađuju aplikacije koje rade na svim platformama, koje se mogu spojiti na postojeće sustave i naravno da budu uvijek dostupne, elastične i skalabilne. Azure App Service je novi servis za izradu mobilnih i web aplikacija i čini ga nekoliko integriranih servisa:

- Mobile Apps za podršku razvoju mobilnih aplikacija za više platformi,

- Web Apps za razvoj web aplikacija koje rastu sa poslovnim izazovima,

- Logic Apps za automatiziranje izvršavanja poslovnih procesa i

- API Apps za brzi razvoj aplikativnih sučelja na otvorenim standardima.

Automatizacija doma jedan je od dijelova Internet Stvari (eng. Internet Of Things). Pojavom malih uređaja poput Raspberry Pi-a "Sam Svoj Majstor" automatizacija doma sve je popularnija. Korištenjem Raspberry Pi uređaja, prototipne pločice i nekoliko senzora (npr. senzor temperature, vlage, vlažnosti zemlje, senzor pokreta) moguće je na različite načine automatizirati dom. Iskorištena je, uz same senzore, infracrvena kamera za

4 UVOD

snimanje po noći i napravljen kućni video nadzor. Od starog televizora, radio prijemnika iskorišten je infracrveni senzor i tv daljinski upravljač kako bi se olakšalo upravljanje automatiziranim kućnim nadzorom. Kao programski jezik za osnovno testiranje i podešavanje rada senzora korišten je Python, dok je konačno rješenje razvijeno u Javi.

Velik broj današnjih mobilnih aplikacija često ima potrebu za dohvaćanjem ili spremanjem podataka pohranjenih na udaljenim mrežnim lokacijama. Aplikacija zapravo komunicira s web servisom koji prima zahtjeve i vraća odgovore. Popularna softverska arhitektura za implementaciju web servisa je REST (eng. Representational State Transfer). Implementacija nativnih REST klijentskih aplikacija u Android operacijskom sustavu obično oduzima dosta vremena. Industrija je prepoznala Retrofit, razvojni okvir koji olakšavaju i ubrzavaju implementaciju spomenutih klijenata, kako bi razvojni inženjeri mogli više vremena posvetiti drugim važnijim aktivnostima tijekom procesa razvoja. Kako bi smanjio količinu potrebnog koda i dodatno ubrzao razvoj, Retrofit koristi Java anotacije. Prikazat ćemo prednosti korištenja Retrofit razvojnog okvira i usporediti taj pristup s onim u kojem se ne koristi nikakav pomoćni razvojni okvir prilikom implementacije REST klijentskih Android aplikacija.

Panel: MOBILNA RJEŠENJA (moderator: Adis Mustedanagić, Infinum)

Najrašireniji način prikaza vizualnih podataka na mobitelima je putem mapa koristeći geolokacije. Primjena može biti raznolika, od prikazivanja točno definiranih i odabranih podataka (poput pozicija autobusnih stanica, bolnica, poštanskih ureda), prikaza rute i kalkulacije udaljenosti za odabrani način prijevoza (npr. do odabranog bankomata) pa sve do složenijih aplikacija koje imaju integrirane mape i servise sa mapama. Demonstrirati ćemo mobilnu iOS i Android aplikaciju koja, koristeći geolokacije, na mapi vizualno predstavlja pozicije ljekarni u Hrvatskoj zajedno sa njihovim relevantnim javnim informacijama. Detaljnije će se usporediti i objasniti razlike implementacija za iOS i za Android platformu.

Kroz nekoliko jednostavnih primjera prikazati ćemo razvoj mobilnih aplikacija za iOS i Android upotrebom Embarcadero Delphi razvojne okoline. Prezentacija će se dotaknuti problema „jednog izvornog koda za različite platforme“ odnosno problema upotrebe „vizualnih elemenata OS-a“ ili „grafički renderiranih vizualnih elemenata“. Na kraju prezentacije bit će prikazana mobilna aplikacija razvijena za potrebe medicinsko-biokemijskih laboratorija.

Koncept Interneta stvari (eng. Internet of Things, IoT) predstavlja novu paradigmu koja se odnosi na unapređenje tradicionalnog Interneta međusobnim povezivanjem različitih objekata iz fizičkog svijeta u

inteligentne mrežne sustave. Ovaj koncept omogućuje interakciju ljudi s uređajima i uređaja s uređajima, integrirajući ih u jedinstvenu mrežu kojom se upravlja putem web aplikacija. Povezivanje bežičnog senzorskog čvora s poslužiteljem u oblaku predstavlja veliki izazov jer čvor ne posjeduje tradicionalna korisnička sučelja (tipkovnica, serijsko ili ethernet mrežno sučelje, zaslon). Prezentirati ćemo aplikaciju za povezivanje bežičnog senzorskog čvora s poslužiteljem u oblaku.

Proširena stvarnost je vrsta tehnologije koja nam omogućava da se digitalni sadržaji (poput videa, slike, animacije, 3D modela i dr.) integriraju sa realnim svijetom te na taj način proširimo (obogatimo) doživljaj stvarnosti koja nas okružje. Primjer takvih informacija može biti prepoznavanje objekata te prikaz dodatnih informacije o promatranom objektu (visina, boja, klasifikacija itd.). Današnji pametni mobiteli i tableti su opremljeni sa brzim procesorima, jakim grafičkim komponentama, velikim ekranima osjetljivim na dodir, kamerom visoke rezolucije, GPS senzorima, kompasom, akcelerometrom, i drugim senzorima te su idealni za proširenu stvarnost bilo na otvorenom ili u zatvorenom prostoru. Prikazati ćemo i opisati projekt izrade aplikacije s proširenom stvarnošću za grad Varaždin. Aplikacija je razvijena za iPhone / iPad uređaje te koristi Metaio razvojni okvir za razvoj elemenata proširene stvarnosti. Aplikacija omogućava pretraživanje ključnih točaka od interesa (engl. Points of Interest) i integraciju multimedije za svaku ključnu točku, te prepoznavanje slika i prikaz multimedijalnih objekata.

3. Radionica: kao dio Xamarin procesa pokazati ćemo alate za Testiranje mobilnih aplikacija po Xamarin procesu i metodologiji.

4. Radionica: Automatizacija doma jedan je od dijelova Internet Stvari (eng. Internet Of Things). Pojavom malih uređaja poput Raspberry Pi-a "Sam Svoj Majstor" automatizacija doma sve je popularnija. Korištenjem Raspberry Pi uređaja, prototipne pločice i nekoliko senzora (npr. senzor temperature, vlage, vlažnosti zemlje, senzor pokreta) moguće je na različite načine automatizirati dom. U ovom radu iskorištena je, uz same senzore, infracrvena kamera za snimanje po noći i napravljen kućni video nadzori od dijelova koje je moguće na inovativan način iskoristiti u automatizaciji doma (iskorišten je infracrveni senzor i tv daljinski upravljač) kako bi se olakšalo upravljanje automatiziranim kućnim nadzorom. Kao programski jezik za osnovno testiranje i podešavanje rada senzora korišten je Python, dok je konačno rješenje razvijeno u Javi.

Tajnik organizacijskog i programskog odbora

Ante Polonijo

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, 098/260 509, fax. +385 51 218 043, e-mail: ante@case.hr

S A D R Ž A J

SUSTAV ZA ODGOVARANJE NA PITANJA PRIRODNIM JEZIKOM

Mile Pavlić, Zdravko Dovedan Han, Alen Jakupović, Sanja Čandrlić,

Martina Ašenbrener Katić, Jasminka Tomljanović, Marina Rauker Koch 5

SUSTAVI ZA VERZIONIRANJE, ALATI I DOBRA PRAKSA: SLUČAJ GIT

Igor Tepavac, Krešimir Valjevac, Stefano Kliba, Marko Mijač 17

VIŠESTRUKO NASLJEĐIVANJE - SAN ILI JAVA 8?

Zlatko Sirotić 25

XAMARIN PROCES

Miljenko Cvjetko 33

AUTOMATIZACIJA DOMA KORIŠTENJEM RASPBERRY PI-A

Dragutin Kermek, Matija Novak 41

KORIŠTENJE RETROFIT RAZVOJNOG OKVIRA PRI IMPLEMENTACIJI ANDROID REST KLIJENTA

David Ante Macan, Zlatko Stapić, Milan Pavlović 49

MOBILNA APLIKACIJA ZA PRONALAZAK LJEKARNI

Jasmin Abou Aldan, Mario Lončar, Marina Ivašić – Kos 57

POVEZIVANJE BEŽIČNOG SENZORSKOG ČVORA S POSLUŽITELJEM U OBLAKU

Tonko Kovačević, Mario Čagalj, Toni Perković, Ivan Vuković 65

APLIKACIJA S PROŠIRENOM STVARNOŠĆU ZA GRAD VARAŽDIN

Ana Ćorić Samardžija 73

OPTIMIZACIJA RAČUNARSTVA U OBLAKU ZA BYOD

Vlatka Davidović, Dijana Liverić, Daniele Milani 77

CASE27 5

SUSTAV ZA ODGOVARANJE NA PITANJA PRIRODNIM JEZIKOM

QUESTION ANSWERING SYSTEM IN NATURAL LANGUAGE

Mile Pavlić, Zdravko Dovedan Han, Alen Jakupović, Sanja Čandrlić, Martina Ašenbrener Katić, Jasminka Tomljanović, Marina Rauker Koch

SAŽETAK

Rad opisuje razvoj sustava za prihvaćanje ljudskog pitanja u prirodnom jeziku od korisnika i pružanje jednog ili više točnih odgovora. Opisani sustav je dio većega sustava za upravljanje znanjima temeljenoga na Node of knowledge (NOK) konceptualnom okviru. Prikazan je dio NOK konceptualnog okvira i u sklopu njega nova metoda prikaza znanja iskazanoga tekstom – formalised NOK (FNOK). Člankom se odgovorilo na pitanje je li moguće nad FNOK formaliziranim znanjem uspostaviti dio koji će prihvaćati korisnička pitanja na prirodnome jeziku i na prirodnome jeziku davati odgovore. Algoritmi su testirani na posebno definiranome skupu rečenica uz pitanja na engleskome jeziku. Keywords: pitanja i odgovori, sustavi upravljanja znanjem, NOK

1. INTRODUCTION

Node of Knowledge (NOK) je konceptualni okvir za za razvoj baza znanja kojega su razvili autori ovoga članka. Početak njegova razvoja kreće krajem 2011. godine kada su autori počeli s razvojem nove grafičke metode prikaza tekstom iskazanoga znanja. Prva verzija nove grafičke metode prikaza znanja nazvane Node of Knowledge, prikazana je u Pavlić et al. (2013a). Usporedba nove metode NOK s nekim drugim grafičkim metodama prikaza znanja dana je u Jakupović et al. (2013) i Pavlić et al. (2013b). U Rauker et al. (2014) prikazana je primjena metode NOK u modeliranju istoga teksta pisanoga na dva različita jezika – hrvatskom i engleskom jeziku.

Temeljem grafičke metode prikaza znanja NOK razvijena je formalizirana metoda za prikaz znanja u obliku teksta (FMTEK) koja je detaljno opisana u Jakupović et al. (2014). U tom članku je prikazana i prva verzija računalnog modela za obradu tekstualnih znanja kojega autori dalje razvijaju.

Ovaj “knowledge based system” se sastoji iz 9 podsustava (Jakupović et al., 2014): Sustav 1. ovaj podsustav omogućava ekspertu ažuriranje mehanizma za formalizaciju tekstom iskazanoga znanja.

Sustav 2. ovaj podsustav kao ulaz prihvaća tekst kojega segmentira na rečenice. Segmentirane rečenice se privremeno spremaju u kontejner rečenica. Sustav 7. ovaj podsustav kao ulaz dohvaća rečenicu koja se nalazi u kontejner rečenica te ju obogaćuje – rečenicu prikazuje na poseban način koji je pogodan za računalnu obradu znanja. Sustav 9. ovaj podsustav omogućava dodavanje znanja u bazu znanja uz povezivanje formaliziranoga teksta koji je izlaz iz podsustava formalizacije teksta s postojećim formaliziranim tekstom (znanjem) iz baze znanja. Sustav 3. ovaj podsustav kao ulaz uzima formalizirani tekst iz baze znanja postavlja pitanje korisniku te temeljem mehanizma u podsustavu formalizacije pitanje

prikazuje u prirodnome jeziku. Potom od korisnika u prirodnome jeziku prihvaća odgovor kojega formalizira i zatim provjerava njegovu točnost pomoću baze znanja ili proširuje bazu znanja novim rečenicama. Sustav 8. ovaj podsustav kao ulaz prihvaća korisničko pitanje iskazano prirodnim jezikom. Pomoću podsustava formalizira postavljeno pitanje i odgovor traži u bazi znanja. Odgovor se u prirodnome jeziku dostavlja korisniku. Ovaj podsustav je opisan u ovome radu. Sustav 4. ovaj podsustav temeljem mehanizama zaključivanja (indukcijom, dedukcijom, analogijom, itd.) a uz korištenje formaliziranoga teksta iz baze znanja predlaže nove rečenice. Ove rečenice se u prirodnome jeziku prikazuju korisniku koji ih validira. Ako rečenice prođu validaciju, one se spremaju u bazu znanja povezujući se s ostalim formaliziranim tekstovima.

Tijekom razvoja opisanoga konceptualnoga modela i početnih načina razvoja njegovih podsustava, Node of Knowledge iz grafičke metode prikaza znanja prerasta u konceptualni okvir za razvoj sustava zasnovanih na tekstualnim znanjima. Ovaj konceptualni okvir definira osnovne koncepte i njihove međusobne odnose, a koji su bitni u razvoju takvih sustava.

Svrha provedenoga i ovdje opisanoga istraživanja je pronaći i prikazati jedan od načina na koji se može razviti podsustav "Primanje pitanja od korisnika i pružanje odgovora" (vidi sliku 1). Zahtjeve koje ovaj podsustav treba zadovoljiti su:

Primanje pitanja od korisnika prirodnim jezikom Traženje odgovora u formaliziranoj bazi znanja Pružanje odgovora u prirodnom jeziku

Osnovni cilj rada je prikazati podsustav "Primanje pitanja od korisnika i pružanje odgovora" i njegove rezultate. Ovim člankom autori žele odgovoriti na pitanje je li moguće razviti podsustav uz ograničenu vrstu pitanja, primjenom NOK konceptualnog okvira za razvoj sustava baza znanja.

6 CASE27

2. RAZVOJNI OKVIR "NODE OF KNOWLEDGE"

U (1) je prikazana jednostavna PSG gramatika (Chomsky 1957) i njeni dijelovi koja opisuje odnos riječi u rečenici "The girl writes a letter." (Ona opisuje i neke druge rečenice koje se mogu tvoriti s riječima iz leksikona).

<sentence> → <noun_phrase><verb_phrase><noun_phrase> → <determiner><noun><verb_phrase> → <verb><noun_phrase><noun> → girl letter<verb> → writes<determiner> → the a

lexicon

rule

(1)

PSG gramatika se može koristiti za provjeru sintaktičke ispravnosti neke rečenice (parsing or syntactic analysis), odnosno za provjeru ispravnoga sintaktičkoga odnosa među riječima koje tvore neku rečenicu unutar nekoga jezika. S druge strane, PSG gramatika se može koristiti za generiranje sintaktički ispravnih rečenica u nekome jeziku, odnosno rečenica koje se sastoje iz riječi u ispravnome sintaktičkome odnosu (Aho et al., 1972; Dovedan, 2012a; Dovedan, 2012b; Jakupović et al., 2014). Primjera radi, PSG pod (1) generira rečenicu "A girl writes.", ali i "The letter writes.".

Rečenica "The girl writes a letter." obogaćena semantičkim identifikatorima (wh-questions) može se grafički prikazati kako slijedi:

The girl writes a letterwho? what?

Slika 2. Grafički prikaz rečenice sa semantičkim identifikatorima (wh-questions)

Na slici 2. se vide dva osnovna koncepta koja se koriste u opisu semantičke veze među riječima rečenice – čvor (node) i link with wh question. Čvor predstavlja word or word phrase i kao takav ima neko značenje. Kada ga se semantičkom vezom poveže s nekim dugim čvorom dobiva se bogatije značenje. Zbog toga su autori ovaj pristup u prikazu semantičke veze među riječima rečenice općenito nazvali Node of Knowledge (NOK).

Grafički prikaz rečenica koji u sebi čuva semantički odnos među riječima primjenom wh-pitanja autori nazivaju Diagram of Node of Knowledge (DNOK). U Pavlić et al. (2013b) opisana je jedna grafička metoda prikaza rečenica koja spada u DNOK, te je prikazan način na koji se neformalizirani jednostavni tekst engleskoga jezika (autori ga nazivaju TENG) prevodi u zapis DNOK.

Osim grafičkoga prikaza, rečenica sa semantičkim odnosima među riječima (primjenom wh-pitanja) se može prikazati i tekstualno. Ovakav način prikaza rečenica autori nazivaju Formalised Node of Knowledge (FNOK). U Jakupović et al. (2014) prikazana je jedna metoda tekstualnoga prikaza rečenica s identificiranim semantičkim odnosima među riječima koja nosi naziv FMTEK (Formalised Method for Text Expressed Knowledge). Prema toj metodi, grafički prikaz rečenice prikazane u (1) bi glasio:

writes(who? The girl, what? a letter) (2)

7. Formalizacija teksta - FMTEK

2. Prilagodba teksta:podejla

teksta u rečenice,

obogaćivanje, ...

Baza znanja -

DBNOK

9. Dodavanje

formaliziranog teksta u

bazu znanjaVanjske baze

znanja

Tekst

Pitanja korisnia

Korisnik

1. Ažuriranje

formaliziranog

teksta

Ekspert

3. Postavljanje pitanja

korisniku i primanje

odgovora od korisnika

4. Predlaganje novih

rečenice na temelju

rasuđivanja i validacije

6. Predlaganje novih rečenice na

temelju drugih baza znanja

5. Predlaganje novih rečenice na

temelju leksikona i / ili postojećih

znanja

Gramatika i leksikon

8. Primanje pitanja od korisnika i pružanje

odgovora

– QANOK

Formatiranje

pitanja -

TtoF

Formatiranje

odgovora -

FtoT

Pružanje

odgovora –

PROA

Slika 1. Računalni sustav zasnovan na NOK

CASE27 7

U istome članku izvedena je PSG prema kojoj se prevodi neformalizirani jednostavni tekst engleskoga jezika (TENG) u njegov formalizirani zapis FNOK. Primjera radi, PSG za rečenicu prikazanu u (2) a prema (1) bi izgledala kako slijedi:

<sentence> → <verb> (<noun-

wh><noun_phrase> , <noun-wh><noun_phrase>)

<noun_phrase> → <determiner><noun>

<noun> → girl letter

<verb> → writes

<determiner> → the a

<noun-wh> → who? what?

(3)

Baza znanja koja se sastoji iz FNOK autori nazivaju KBNOK (NOK based Knowledge Base). Njezin integralni dio je i mehanizam zaključivanja nad FNOK kojega autori nazivaju RNOK (NOK based Reasoning). KB sustav koji se temelji na FNOK prikazu znanja i RNOK mehanizmu zaključivanja autori nazivaju KBSNOK (NOK based KB System). Interakcija korisnika i KBSNOK odvija se preko sučelja kojega autori nazivaju QANOK (Question Answering NOK). Osim ovoga sučelja, postoji i posebno sučelje za eksperte koji održavaju KBNOK. Autori ovo sučelje nazivaju MNOK (Maintenance NOK).

Definicija koncepata i njihov međusobni odnos tvore NOK konceptualni okvir za razvoj sustava baze znanja i on je prikazan na slici 3.

U interakciji sa sustavom KBSNOK, korisnik i ekspert koriste TENG (tekst na prirodnom engleskom jeziku). Korisnik je u interakciji sa KBSNOK preko sučelja QANOK koje koristi FNOK radi formalizacije odnosno deformalizacije teksta. U pružanju odgovora korisniku, QANOK koristi RNOK (pravila zaključivanja) i/ili formalizirano znanje iz KBNOK. Također KBSNOK koristi QANOK kako bi korisniku postavio pitanja.

KBSNOK ima posebno sučelje i skup programskih alata za eksperta MNOK koje koristi u oblikovanju sustava KBSNOK. MNOK može ažurirati mehanizme u FNOKu i QANOKu. MNOK može ažurirati mehanizme u RNOKu kao i znanje u KBNOKu. RNOK može koristiti RNOK iz drugoga KB sustava KBSNOKx, ali i znanje iz svoje KBNOK, kako bi izveo prijedloge novih pravila

zaključivanja (npr. indukcijom, dedukcijom i analogijom). Prijedlozi pravila zaključivanja se preko MNOKa prezentiraju ekspertu koji ih validira.

U ovome radu su opisani dijelovi sljedećih podsustava KB sustava KBSNOK: QANOK, FNOK i KBNOK.

3. METODOLOGIJA ISTRAŽIVANJA

Osnovni proces koji se odvija u podsustavu "Primanje pitanja od korisnika i pružanje odgovora"

prikazan na slici 1., odnosno u podsustavu sustava QANOK preko kojega korisnik postavlja pitanja KBSNOK-u na koja ovaj daje odgovore, sastoji se iz sljedećih aktivnosti:

prihvaćanej pitanja u prirodnom engleskom jeziku (qTENG)

prevođenje pitanja s prirodnoga engleskog jezika u formalizirani oblik (qFNOK)

usporedba qFNOK s FNOK rečenicama u KBNOK-u

Prije provedbe opisanoga osnovnog procesa potrebno je bazu znanja KBNOK napuniti formaliziranim znanjem. To znači da u KBNOK trebaju postojati FNOK formalizirane rečenice koje se dobivaju prevođenjem iz njihova TENG oblika. Za potrebe razvoja sustava QANOK razvit će se sustav koji se sastoji iz dva pretvarača:

FNOK transducer koji ulaznu rečenicu napisanu u jeziku TENG prevodi u rečenicu u jeziku FNOK.

qFNOK transducer koji ulaznu rečenicu (pitanje), napisanu u jeziku qTENG prevodi u rečenicu u jeziku qFNOK.

i evaluatora koji na temelju prevedenog teksta i pitanja u FNOK i qFNOK notaciju i njihovog uparivanja pronalazi odgovor (slika 4). qFNOK pretvarač i evaluator predstavljaju dijelove QANOK sustava.

U nastavku slijede definicije pojmova “recognizing i translation” koji su bitni u razvoju FNOK i qFNOK transducera.

3.1. Prepoznavač

Osim parsiranja (parsing), sintaksne analize jezika L(G)

definiranog gramatikom postoji i sintaksna analiza

FNOK RNOK

QANOK

MNOK

Expert

User

TENG

TENG

DNOK

KBSNOK

KBSNOKx

KBNOK

Slika 3. Razvojni okvir za razvoj sustava baze znanja

8 CASE27

nazvana prepoznavanje (recognizing) (Aho et al., 1972). Ovdje je definiran prepoznavač primjenljiv na sve tipove formalnih jezika, nazvanih languages with the properties (jezici sa svojstvima) (Dovedan, 2012b; Dovedan, 2013).

Recognizer jezika sa svojstvima je a 7-tuple

J = (Q, V , , q0, F, , M )

where

Q konačan skup stanja V rječnik, V

+

funkcija prijelaza, definirana kao : Q V {@} P(Q) gdje je P(Q) particija od Q ; @ je oznaka kraja

ulaznog niza q0 početno stanje, q0Q

F skup završnih stanja, F Q

skup akcija pridruženih svakom paru

(qi,sj), qiQ , sjV, za koji je definirana

funkcija prijelaza

M pomoćna memorija

3.2 Prevodioc

Općenito se proces prevođenja sastoji od nekoliko faza: leksičke i sintaksne analize ulaznog niza (rečenice x) i

generiranje izlazne rečenice, y. Program za prevođenje

naziva se translator. Ako se u fazi sintaksne analize

prevodioca koristi recognizer (prepoznavač), takav se translator naziva transducer (pretvarač).

4. REZULTATI ISTRAŽIVANJA

Razvijeni sustav QANOK testiran je na 42 jednostavne rečenice prirodnog jezika (Dodatak A stupac TENG). Sustav je razvijan metodom indukcije tako da su se TENG rečenice analizirale u smjeru od jednostavnijih ka složenijima i prema njima su se razvijali mehanizmi QANOK sustava. Razvoj je usmjeren na glagolsko vrijeme Simple Present Tense. Nakon toga algoritmi su testirani na rečenicama Simple Past Tense, te su se time pokazale mogućnosti i načini njihova širenja u druga glagolska vremena. Za definirane TENG rečenice načinjena je KBNOK baza znanja koja se sastoji iz 42 jednostavne FNOK formalizirane rečenice (vidi Dodatak A stupac FNOK). Potom je za svaku TENG rečenicu definirano nekoliko pitanja čime se dobilo ukupno 88 pitanja (vidi Dodatak B stupac qTENG). Sva pitanja

prevedena su u qFNOK oblik (Dodatak B stupac qFNOK).

Rezultat primjene QANOK sustava na KBNOK prikazan je u Dodatku C. Tablica iz dodatka C se sastoji iz tri stupca: postavljeno pitanje na engleskom jeziku (qTENG), dobiveni odgovor QANOK sustava (Answer) i rečenica na engleskom jeziku u kojoj je odgovor pronađen (TENG).

5. ZAKLJUČAK

U radu je pokazano kako QANOK sustav „razumijeva“ jednostavne rečenice engleskog jezika sa leksikonom od odabranih stotinjak riječi i izvođenjem odgovora na postavljena pitanja. Prvo su učitane rečenice i prevedene u FNOK jezik. Rečenice engleskoga jezika

TENG opisane su beskontekstnom gramatikom ili, još

preciznije, regularnom gramatikom i ekvivalentnim regularnim izrazima. Potom je definirano sintaksno-upravljano prevođenje u jezik FNOK. Definiran je i jezik

za postavljanje pitanja, qTENG. I njega smo opisali

regularnim izrazima. Da bismo mogli dobiti odgovor na postavljeno pitanje, prvo smo upitnu rečenicu qTENG

jezika preveli sintaksno-upravljenim prevođenjem u qFNOK oblik. Struktura jezika qFNOK jednaka je strukturi

jezika FNOK sa varijablama X i Y na mjestima

nepoznanica – riječi koje predstavljaju odgovor na pitanje. Time smo pojednostavili problem i sveli ga na jednostavno uparivanje (maching) dvaju nizova (stringova). Ako rečenica jezika qFNOK ne sadrži

varijable, odgovor je YES, ako se može uprati s nekom

rečenicom jezika FNOK, inače je odgovor NO.

Prirodni jezik nije beskontekstan, ali smo ga mi u prethodnom članku „beskontekstirali“ uvođenjem svojstava, tj. pridružujući svakoj riječi rečenice odgovarajuća svojstva pa smo takav jezik nazvali “jezik sa svojstvima”. Pritom nismo išli previše „po dubini“ pojedinih vrsta riječi, pa je, na primjer, Nc bila

zajednička, a Np vlastita imenica, ne ulazeći u druga

svojstva (rod, broj, živo-neživo, itd).

To vrijedi kako za riječi, tako i za pitanja. Imali smo ukupno 18 vrsta riječi u fazi sintaksne analize, a treba ih biti puno više. Kod pitanja treba, na primjer za početak, razgraničiti pitanja QN na QNc i QNp, kao i QA. Uveli smo i

šest podklasa pridjeva s novim skupovima pitanja, QA1,

QA2 do QA6. Na primjer, pitanja 'how much?', 'how

sentence

(TENG)RECOGNIZER

sentential

form

(TENG)tFNOK

sentential

form

(FNOK)

FNOK TRANSDUCER

LexiconTransition

table

sentence

(qTENG)RECOGNIZER

sentential

form

(qTENG)tqFNOK

sentential

form

(qFNOK)

qFNOK TRANSDUCEREVALUATION

(matching)ANSWER

QANOK

Slika 4. Model sustava QANOK

CASE27 9

many?' i 'what kind?' postavljala su se za pridjeve različitih skupina svojstava.

Daljnja će istraživanja biti fokusirana na:

proširenje semantičkih svojstava riječi – glagoli, imenice, zamjenice, uvođenje veznika, sinonima itd.

proširenje sintaksne strukture – npr. za glagole: lica, glagolska vremena itd.; uvođenje složenih rečenica

uvođenje sematike rečenica: obrada dvoznačnosti, međusobno povezane rečenice itd.

Pored navedenoga daljnja istraživanja će obuhvatiti i trenutno uočena problemska područja QANOK sustava kao što su:

kod dan/ne osim odgovora "YES" ili "NO" generirati širi odgovor. (npr. "No. Girls are on the beach")

kod wh-questions koji sadrži glagol u trećem licu jednine generirati i odgovor s glagolom u množini

trenutno se daju odgovori kod kojih postoji potpuno poklapanje između FNOK rečenica i qFNOK pitanja. Pitanje koje se postavlja je što učiniti s

odgovorima kod kojih postoji djelomično poklapanje i kada je to djelomično poklapanje značajno a kako bi se odgovor ponudio korisniku.

proširenje mehanizma "izračuna" odgovora tako da se u obzir uzimaju "skrivene" veze među rečenicama (npr. jedna rečenica je povezana s dijelom druge preko zamjenice).

odgovaranje na pitanje do koje mjere tolerirati gramatičke pogreške u korisničkim pitanjima i što uopće učiniti s takvim pitanjima.

odgovaranje na pitanje čiji se dijelovi odgovora nalaze na različitim mjestima u rečenici.

6. ZAHVALA

The research has been conducted under the project "Extending the information system development methodology with artificial intelligence methods" (reference number 13.13.1.2.01.) supported by University of Rijeka (Croatia).

References:

1 Aho, A. V., & Ullman, J. D. (1972). The Theory of Parsing, Translation and compiling. Vol. 1.Parsing, Prentice-Hall.

2 Ašenbrener, M., Pavlić, M., & Tomljanović, J. (2014, January). Intelligent Question–Answering Systems: Review of research. In 1847-3946. Hrvatska znanstvena bibliografija i MZOS-Svibor.

3 Biber, D., Hohansson, S., Leech, G., Conrad, S., & Finegan, E., (1999). Longman Grammar of Spoken and Written English. London: Longman.

4 Chomsky, N. (1956). Three models for the description of language. IRE Transactions on Information Theory. Volume 2. 113 - 124.

5 Dovedan, H. Z. (2012a). Formalni jezici i prevodioci – regularni izrazi, gramatike, automati. Zagreb: Element.

6 Dovedan, H. Z. (2012b). Formalni jezici i prevodioci – sintaksna analiza i primjene. Zagreb: Element.

7 Dovedan, H. Z. (2013). Formalni jezici i prevodioci – prevođenje i primjene. Zagreb: Element.

8 Erjavec, T. (Eds.) (2010a). MULTEXT-East - Morphosyntactic Specifications (Version 4). from: http://nl.ijs.si/ME/V4/msd/html/index.html

9 Erjavec, T. (2010b). MULTEXT-East Version 4: Multilingual Morphosyntactic Specifications, Lexicons and Corpora. Proceedings of the LREC 2010. Malta: European Language Resources Association. 2544-2547

10 Jakupović, A., Pavlić, M., & Dovedan, H. Z. (2014). Formalisation method for the text expressed knowledge. Expert systems with applications. 41 (11). 5308-5322.

11 Jakupović, A., Pavlić, M., Meštrović, A., & Jovanović, V. (2013).Comparison of the Nodes of Knowledge method with other graphical methods for knowledge representation. Proceedings of the 36th international convention. Rijeka: Croatian Society for Information and Communication Technology, Electronics and Microelectronics – MIPRO. 1276-1280.

12 Jespersen, O. (1964). Essentials of English Grammar. Tuscaloosa: The University of Alabama Press.

13 Katic, M. A., Pavlic, M., & Candrlic, S. (2015). The Representation of Database Content and Structure Using the NOK Method. Procedia Engineering,100, 1075-1081.

14 Koch, M. R., Pavlić, M., & Katić, M. A. (2015). Homonyms and Synonyms in NOK Method. Procedia Engineering, 100, 1055-1061.

15 Koch, M. R., Pavlic, M., & Jakupovic, A. (2014, May). Application of the NOK method in sentence modelling. In Information and Communication Technology, Electronics and Microelectronics (MIPRO), 2014 37th International Convention on (pp. 1176-1181). IEEE.

16 MULTEXT (1996). Multilingual Text Tools and Corpora. from: http://aune.lpl.univ-aix.fr/projects/multext/

17 MULTEXT-East (1996).Multilingual Text Tools and Corpora for Central and Eastern European Languages - Project COPERNICUS 106.from: http://aune.lpl.univ-aix.fr/projects/multext-east/

18 Pavlić, M., Jakupović, A., & Meštrović, A. (2013a). Nodes of knowledge method for knowledge representation. Informatologia. 46 (3). 206-214.

19 Pavlić, M., Meštrović, A., & Jakupović, A. (2013b). Graph-Based Formalisms for Knowledge Representation. Proceedings of the 17th World Multi-Conference on Systemics Cybernetics and Informatics (WMSCI 2013), Volume 2. Orlando: IIIS. 200-204

20 Pavlić, M., Jakupović, A., & Čandrlić, S. (2014). Modeliranje procesa.Sveučilište u Rijeci, 2015.

21 Pavlić, M., Han, Z. D., & Jakupović, A. (2015). Question answering with a conceptual framework for knowledge-based system development “Node of Knowledge”. Expert Systems with Applications, 42(12), 5264-5286.

10 CASE27

22 Pavlić, M., Sistem analiza i modeliranje podataka, Naučna knjiga, Beograd, 1990.

23 Pavlić, M., Razvoj informacijskih sustava – projektiranje, praktična iskustva, metodologija, Znak, Zagreb, 1996.

24 Pavlić, M., Informacijski sustavi, Školska knjiga, Zagreb, 2011.

25 Pavlić, M., Oblikovanje baza podataka, Odjel za informatiku Sveučilišta u Rijeci, Rijeka, 2011.

26 Quirk, R., Greenbaum, S., Leech, G., & Svartvik, J. (1985). A comprehensive grammar of the English language. New York: Longman Inc.

27 Rauker, K. M., Pavlić, M., Jakupović, A. (2014). Application of the NOK method in sentence modelling.. Proceedings of the 37th international convention. Rijeka: Croatian Society for Information and Communication Technology, Electronics and Microelectronics – MIPRO. 1426-1431.

28 Stivers, T. (2010). An overview of the question-response system in American English conversation. Journal of Pragmatics, 42, 2772-2781.

29 Srića, V., Treven, S., Pavlić, M., Menadžer i informacijski sustavi, Poslovna knjiga, Zagreb, 1994.

30 Strahonja, V., Varga, M., Pavlić, M., Projektiranje informacijskih sustava – metodološki priručnik, ZID i INAINFO, Zagreb, 1992.

31 Tomljanović, J., Krsnik, M., & Pavlić, M. (2014). QUESTION ANSWERING SYSTEMS. Zbornik Veleučilišta u Rijeci, 2(1), 177-196.

32 Tomljanovic, J., Pavlic, M., & Katic, M. A. (2014, May). Intelligent question—Answering systems: Review of research. In Information and Communication Technology, Electronics and Microelectronics (MIPRO), 2014 37th International Convention on (pp. 1228-1233). IEEE.

Podaci o autorima:

Mile Pavlić

RIS - Odjel za informatiku, Sveučilište u Rijeci

e-mail: mile.pavlic@ris.hr

Prof. dr. sc. Mile Pavlić bavi se metodologijom projektiranja i razvojem informacijskih sustava. Direktor je tvrtke RIS osnovane 1993. za razvoj informacijskih sustava. Aktivno izučava metode za projektiranje informacijskih sustava. Predavač predmeta o projektiranju informacijskih sustava na Odsjeku za informatiku na Filozofskom fakultetu u Rijeci. Bio je pročelnik Odsjeka od 1995. do 1998. Aktivno sudjeluje na razvoju niza projekata u privredi (MOHV, HRT, CROATIA i dr.). Stalni predavač metoda za projektiranje IS od 1986. za projektante. Član programskog odbora za organiziranje CASE - alati i metode savjetovanja. Završio studij Fizika s matematikom na Pedagoškom fakultetu u Rijeci 1980. godine. Na poslovima analitičara/programera u ERC-u, radio od rujna 1982. godine u brodogradilištu 3. Maj u Rijeci. Prvi informacijski sustav o praćenju stanja skladišta završio 1983. godine. Radio na nizu projekata, bilo na projektiranju bilo na fizičkoj realizaciji, kao voditelj, projektant, analitičar ili programer. Održavao predavanja o: arhitekturi operativnih sustava računara, radu prevoditelja, bazi podataka, ekspertnim sustavima, DSS, modeliranju procesa i podataka, organizaciji informatike, informacijskim sustavima i dr. Radio na radnom mjestu projektanta i direktora INFO centra u RiAdria banci d.d. Rijeka. Biran za područje informacijskih znanosti u znanstvenoistraživačko zvanje znanstvenog asistenta 17. ožujka 1992. a u zvanje znanstvenog suradnika 9. studenog 1994. te u docenta 1997. godine. Objavio niz znanstvenih i stručnih radova. Magistrirao na usporedbi raznih metoda za modeliranje podataka, a doktorirao na temi izučavanja procesa praktične primjene informatičkog inženjeringa u poduzećima.

Zdravko Dovedan Han

Filozofski fakultet Zagreb

Alen Jakupović

Jasminka Tomljanović

Veleučilište u Rijeci

Martina Ašenbrener Katić

Sanja Čandrlić

Marina Rauker Koch

Odjel za informatiku, Sveučilište u Rijeci

CASE27 11

Appendix A: Skup definiranih TENG jednostavnih rečenica i njihov FNOK zapis

No. TENG FNOK

1. They stare. stare("who?" they)

2. Everything glows. glows("what?" everything)

3. Tom swims. swims("who?" Tom)

4. Pencil writes. writes("what?" a pencil)

5. The car drives. drives("what?" the car)

6. A boy stares. stares("who?" a boy)

7. This girl sings. sings("who?" girl("which?" this))

8. Someone's lamp glows. glows("what?" lamp("whose?" someone's))

9. Tom's brother swims. swims("who?" brother("whose?" Tom's))

10. Student's pencil writes. writes("what?" pencil("whose?" student's))

11. My car drives. drives("what?" car("whose?" my))

12. The red car drives. drives("what?" the car("which?" red))

13. A tall boy stares. stares("what?" a boy("which?" tall))

14. Several girls sing. sing("who?" girls("how_many?" several))

15. Someone's electrical lamp glows.

glows("what?" lamp("whose?" someone's, "what_kind?" electrical))

16. This artificial system works. works("what?" system("which?" this, "what_kind?" artificial))

17. Enough information remains. remains("what?" information("how_much?" enough))

18. American's very tall boy stares. stares("who?" boy("whose?" American's, "which?" tall("how?" very)))

19. My incredibly tall boy stares. stares("whose?" my "how?" incredibly "who?" boy("which?" tall))

20. Julia's very incredibly tall boy stares.

stares("who?" boy("whose?" Julia's, "which?" tall("how?" incredibly("how?" very))))

21. The red car on the road drives. drives("what?" the car("which?" red) "where?" on "what?" the road)

22. Several girls from behind the green door sing.

sing("who?" girls("how_many?" several) "where?" from "where?" behind "what?" the door("what?" green))

23. Julia's very incredibly tall boy two feet behind me stares.

stares("who?" boy("whose?" Julia's, "which?" tall("how?" incredibly("how?" very))) "how_many?" two "what?" feet "where?" behind "who?" me)

24. Enough information right on the paper remains.

remains("what?" information("how_much?" enough) "how?" right "where?" on "what?" the paper)

25. This artificial system two feet from behind the table works.

works("what?" system("which?" this, "what_kind?" artificial) "how_many?" two "what?" feet "where?" from "where?" behind "what?" the table)

26. American's very tall boy right from behind the door stares.

stares("who?" boy("whose?" American's, "which?" tall("how?" very)) "how?" right "where?" from "where?" behind "what?" the door)

27. I look myself. look("who?" I, "whom?" myself)

28. The student reads a wonderful book.

reads("who?" the student, "what?" a book("what?" wonderful))

29. Julia writes a letter to a friend writes("who?" Julia, "what?" a letter "where?" to "what?" a friend)

30. He drove my red car on Monday.

drove("who?" he, "what?" car("whose?" my, "which?" red) "when?" on "who?" Monday)

31. A boy gives an apology to the girl.

gives("who?" a boy, "what?" an apology "where?" to "who?" the girl)

32. She makes the room red. makes("who?" she, "what?" the room "which?" red)

33. The view makes him incredibly happy on the hill.

is("what?" the toy, "what?" old("how?" very))

34. The toy is very old. swims("who?" Julia, "how?" fast "where?" on "what?" the pool)

35. Julia swims fast on the pool. are("who?" girls, "where?" on "what?" the beach)

36. Girls are on the beach. talk("who?" I, "where?" with "whose?" my book)

37. I talk with my book. talk("who?" I, "where?" about "what?" the solution "where?" with "whose?" my colleague)

38. I talk about the solution with my colleague.

has("who?" Tom, "how_many?" two "what?" cars)

39. Tom has two cars. drives("who?" Tom, "what?" a car "when?" today)

40. Tom drives a car today. drove("who?" Tom, "what?" car("which?" red) "when?" on "who?" Monday)

41. Tom drove red car on Monday. drove("who?" Tom, "what?" car("whose?" Mery's, "which?" red) "when?" on "who?" Monday)

42. Tom drove Mery's red car on Monday.

makes("what?" the view, "who?" him "how?" incredibly "what?" happy "where?" on "what?" the hill)

12 CASE27

Appendix B: Skup jednostavnih qTENG pitanja i njihov qFNOK zapis

No. qTENG qFNOK

1. Are girls on the beach? are (_ girls, _ on _ the beach

2. Who is on the beach? is ("who?" X, & _ on _ the beach

3. Who are on the beach? are ("who?" X, & _ on _ the beach

4. Where are girls? are (_ girls, & "where?" X

5. To whom does Julia write a letter? write (_ Julia, _ a letter _ to _ X

6. Who writes a friend a letter? writes ("who?" X, _ a friend _ a letter

7. Who write a letter to a friend? write ("who?" X, _ a letter _ to _ a friend

8. What does Julia do to a friend? X (_ Julia & _ to _ a friend

9. What does Julia do on the pool? X (_ Julia & _ on _ the pool

10. Where does Julia swim? swim (_ Julia & "where?" X

11. How does Julia swim? swim (_ Julia, "how?" X

12. Who swim fast on the pool? swim ("who?" X, _ fast _ on _ the pool

13. What does Julia's very incredibly tall boy do two feet behind me?

X (_ boy (_ Julia's, _ tall (_ incredibly (_ very))) _ two _ feet _ behind _ me

14. What does Julia's very incredibly tall boy do? X (_ boy (_ Julia's, _ tall (_ incredibly (_ very)))

15. Who swim? swim ("who?" X

16. Does a tall boy stare? stare (_ a boy (_ tall)

17. How old is the toy? is (_ the toy, _ old ("how?" X)

18. Is the toy very old? is (_ the toy, _ old (_ very)

19. What did Tom do with Mery's red car on Monday?

X (_ Tom & _ car (_ red) _ on _ Monday

20. What did Tom do with red car? X ( _ Tom & _ car (_ red)

21. What do I do about the solution with my colleague?

X (_ I, _ about _ the solution _ with _ my colleague

22. With whose colleague I talk about the solution?

talk (_ I, & with _ X & _ about _ the solution

23. What do I do with my book? X (_ I, _ with _ my book

24. What do I do? X (_ I

25. What do several girls do? X (_ girls (_ several)

26. What do several girls from behind the green door do?

X (_ girls (_ several) _ from _ behind _ the door (_ green)

27. What do they do? X (_ they

28. What does someone's electrical lamp do? X (_ lamp (_ someone's, _ electrical)

29. How many cars has Tom? has (_ Tom, "how_many?" X _ cars

30. What does Tom do today? X (_ Tom & _ today

31. What does Tom do with a car today? X (_ Tom & _ a car _ today

32. What does Tom do? X (_ Tom

33. What does Tom's brother do? X (_ brother (_ Tom's

34. Who give an apology to the girl? give ("who?" X, _ an apology _ to _ the girl

35. What does a boy do to the girl? X ( _ a boy , _ Y & _ to _ the girl

36. What does a boy do? X (_ a boy

37. What does a pencil do? X (_ a pencil

38. What does a tall boy do? X (_ a boy (_ tall)

39. What does American's very tall boy do? X (_ boy (_ American's, _ tall (_ very)

40. What does American's very tall boy right from behind the door do?

X (_ boy (_ American's, _ tall (_ very)) _ right _ from _ behind _ the door

41. What does enough information do? X (_ information (_ enough)

42. What does enough information right on the paper do?

X (_ information (_ enough) _ right _ on _ the paper

43. What does everything do? X (_ everything

44. What does my car do? X (_ car (_ my

45. What does my incredibly tall boy do? X (_ my _ incredibly _ boy (_ tall)

46. What does she do to the room red? X (_ she & _ the room _ red

47. What does someone's lamp do? X (_ lamp (_ someone's

48. What does the car do? X (_ the car

49. What does the red car do? X (_ the car (_ red)

CASE27 13

50. What does the red car on the road do? X (_ the car (_ red) _ on _ the road

51. What does the student do? X (_ the student

52. What does student's pencil do? X (_ pencil (_ student's

53. What does this artificial system do? X (_ system (_ this, _ artificial)

54. What does this girl do? X (_ girl (_ this

55. What drives on the road? drives ("what?" X, & _ on _ the road

56. What drives? drives ("what?" X

57. What glows? glows ("what?" X

58. What is very old? is ("what?" X, _ old (_ very)

59. What makes him incredibly happy? makes ("what?" X & _ incredibly _ happy

60. What remains? remains ("what?" X

61. Which system works two feet from behind the table?

works ( _ system ( _ X ) & _ two _ feet _ from _ behind _ the table

62. What works? works ("what?" X

63. What writes? writes ("what?" X

64. Who drove Mery's red car? drove (_ X, _ car (_ Mery's, _ red)

65. When did Tom drove Mery's red car? drove (_ Tom, _ car (_ Mery's, _ red) "when?" X

66. When does Tom drive a car? drive (_ Tom, _ a car "when?" X

67. Who drive today? drive ("who?" X & _ today

68. Who drive? drive ("who?" X

69. Where does enough information remain? remain (_ information (_ enough) & "where?" X

70. Which girl sings? sings (_ girl, "which?" X

71. Who drove my red car on Monday? drove ("who?" X, _ car (_ my, _ red) _ on _ Monday

72. Who make the room red? make ("who?" X, _ the room _ red

73. Who read a wonderful book? read ("who?" X, _ a book (_ wonderful)

74. Who sing? sing ("who?" X

75. Who stare? stare ("who?" X

76. Who talk about the solution with my colleague?

talk ("who?" X, & _ about _ the solution _ with _ my colleague

77. With what I talk? talk (_ I, _ with _ X

78. Whose brother swims? swims (_ brother, "whose?" X

79. Whose car drives? drives (_ car, "whose?" X

80. Whose lamp glows? glows (_ lamp, "whose?" X

81. Whose pencil writes? writes (_ pencil, "whose?" X

82. Are girls on the pool? are (_ girls, _ on _ the pool

83. Whom do I look? look (_ I, _ X)

84. Who looks himself? looks ("who?" X, _ himself

85. Who look myself? look ("who?" X, _ myself

86. Who is him? is (_ him & "who?" X

87. Whose red car did he drive on Monday? drive (_ he, _ car (_ X, _ red) _ on _ Monday

88. Whose red car did Tom drive on Monday? drive (_ Tom, _ car (_ X, _ red) _ on _ Monday

Appendix C: qTENG pitanja i odgovori QANOK sustava

No. qTENG Answer TENG

1. Are girls on the beach? YES (Girls are on the beach)

2. Who is on the beach? I DO NOT NO

3. Who are on the beach? girls (Girls are on the beach)

4. Where are girls? on the beach

5. To whom does Julia write a letter? a friend (Julia writes a letter to a friend)

6. Who writes a friend a letter? I DO NOT NO

7. Who write a letter to a friend? Julia (Julia writes a letter to a friend)

8. What does Julia do to a friend? writes

9. What does Julia do on the pool? swims

(Julia swims fast on the pool) 10. Where does Julia swim? on the pool

11. How does Julia swim? fast

12. Who swim fast on the pool? Julia

14 CASE27

13. What does Julia's very incredibly tall boy do two feet behind me?

stares (Julia's very incredibly tall boy two feet behind me stares)

14. What does Julia's very incredibly tall boy do?

stares (Julia's very incredibly tall boy stares)

stares (Julia's very incredibly tall boy two feet behind me stares)

15. Who swim?

Tom (Tom swims)

Tom's brother (Tom's brother swims)

Julia (Julia swims fast on the pool)

16. Does a tall boy stare? YES (A tall boy stares)

17. How old is the toy? very (The toy is very old)

18. Is the toy very old? YES

19. What did Tom do with Mery's red car on Monday?

drove (Tom drove Mery's red car on Monday)

20.

What did Tom do with red car? drove (Tom drove red car on Monday)

drove (Tom drove Mery's red car on Monday)

21. What do I do about the solution with my colleague?

talk (I talk about the solution with my colleague)

22. With whose colleague I talk about the solution?

my colleague

23. What do I do with my book? talk (I talk with my book)

24. What do I do?

look (I look myself)

talk (I talk with my book)

talk (I talk about the solution with my colleague)

25. What do several girls do?

sing (Several girls sing)

sing (Several girls from behind the green door sing)

26. What do several girls from behind the green door do?

sing (Several girls from behind the green door sing)

27. What do they do? stare (They stare)

28. What does someone's electrical lamp do? glows (Someone's electrical lamp glows)

29. How many cars has Tom? two (Tom has two cars)

30. What does Tom do today? drives (Tom drives a car today)

31. What does Tom do with a car today? drives

32. What does Tom do?

swims (Tom swims)

has (Tom has two cars)

drives (Tom drives a car today)

drove (Tom drove red car on Monday)

drove (Tom drove Mery's red car on Monday)

33. What does Tom's brother do? swims (Tom's brother swims)

34. Who give an apology to the girl? a boy (A boy gives an apology to the girl) 35. What does a boy do to the girl? gives an apology

36. What does a boy do?

stares (A boy stares)

stares (A tall boy stares)

gives (A boy gives an apology to the girl)

37. What does a pencil do? writes (A pencil writes)

38. What does a tall boy do? stares (A tall boy stares)

39. What does American's very tall boy do?

stares (American's very tall boy stares)

stares (American's very tall boy right from behind the door stares)

40. What does American's very tall boy right from behind the door do?

stares (American's very tall boy right from behind the door stares)

41. What does enough information do?

remains (Enough information remains)

remains (Enough information right on the paper remains)

CASE27 15

42. What does enough information right on the paper do?

remains (Enough information right on the paper remains)

43. What does everything do? glows (Everything glows)

44. What does my car do? drives (My car drives)

45. What does my incredibly tall boy do? stares (My incredibly tall boy stares)

46. What does she do to the room red? makes (She makes the room red)

47. What does someone's lamp do? glows (Someone's lamp glows)

glows (Someone's electrical lamp glows)

48. What does the car do?

drives (The car drives)

drives (The red car drives)

drives (The red car on the road drives)

49. What does the red car do?

drives (The red car drives)

drives (The red car on the road drives)

50. What does the red car on the road do? drives (The red car on the road drives)

51. What does the student do? reads (The student reads a wonderful book)

52. What does student's pencil do? writes (Student's pencil writes)

53. What does this artificial system do?

works (This artificial system works)

works (This artificial system two feet from behind the table works)

54. What does this girl do? sings (This girl sings)

55. What drives on the road? the red car (The red car on the road drives)

56. What drives?

the car (The car drives)

my car (My car drives)

the red car (The red car drives)

the red car (The red car on the road drives)

57. What glows?

everything (Everything glows)

someone's lamp (Someone's lamp glows)

someone's electrical lamp (Someone's electrical lamp glows)

58. What is very old? the toy (The toy is very old)

59. What makes him incredibly happy? the view (The view makes him incredibly happy on the hill)

60. What remains?

enough information (Enough information remains)

enough information (Enough information right on the paper remains)

61. Which system works two feet from behind the table?

this artificial (This artificial system two feet from behind the table works)

62. What works?

this artificial system (This artificial system works)

this artificial system (This artificial system two feet from behind the table works)

63. What writes? a pencil (A pencil writes)

student's pencil (Student's pencil writes)

64. Who drove Mery's red car? Tom (Tom drove Mery's red car on Monday) 65. When did Tom drove Mery's red car? on Monday

66. When does Tom drive a car? today

(Tom drives a car today) 67. Who drive today? Tom

68. Who drive? Tom

69. Where does enough information remain? on the paper (Enough information right on the paper remains)

70. Which girl sings? this (This girl sings)

71. Who drove my red car on Monday? he (He drove my red car on Monday)

72. Who make the room red? she (She makes the room red)

73. Who read a wonderful book? the student (The student reads a wonderful book)

74. Who sing?

this girl (This girl sings)

several girls (Several girls sing)

several girls (Several girls from behind the green door sing)

16 CASE27

75. Who stare?

they (They stare)

a boy (A boy stares)

American's very tall boy (American's very tall boy stares)

Julia's very incredibly tall boy

(Julia's very incredibly tall boy stares)

Julia's very incredibly tall boy

(Julia's very incredibly tall boy two feet behind me stares)

American's very tall boy (American's very tall boy right from behind the door stares)

76. Who talk about the solution with my colleague?

I (I talk about the solution with my colleague)

77. With what I talk? my book (I talk with my book)

78. Whose brother swims? Tom's (Tom's brother swims)

79. Whose car drives? my (My car drives)

80. Whose lamp glows? someone's (Someone's lamp glows)

someone's (Someone's electrical lamp glows)

81. Whose pencil writes? student's (Student's pencil writes)

82. Are girls on the pool? NO

83. Whom do I look? myself (I look myself)

84. Who looks himself? I DO NOT NO

85. Who look myself? I (I look myself)

86. Who is him? I DO NOT NO

87. Whose red car did he drive on Monday? I DO NOT NO

88. Whose red car did Tom drive on Monday?

I DO NOT NO

CASE27 17

SUSTAVI ZA VERZIONIRANJE, ALATI I DOBRA PRAKSA: SLUČAJ GIT

VERSION CONTROL SYSTEMS, TOOLS AND BEST PRACTICES: CASE GIT

Igor Tepavac, Krešimir Valjevac, Stefano Kliba, Marko Mijač

SAŽETAK

Sustavi za verzioniranje već dugo predstavljaju sastavni dio razvojnog procesa i neizostavan alat kako individualnim programerima tako i programerskim timovima. Međutim, uporaba takvih sustava i izbor odgovarajućeg načina rada u početku može predstavljati izazov. Programeri i timovi često ne ulože dovoljno vremena da upoznaju mogućnosti ovih sustava, što na kraju rezultira time da ne iskoriste mogućnosti sustava za verzioniranje u punom smislu. U ovom radu pokušati ćemo doprinijeti rješavanju ovog problema identificiranjem i sistematiziranjem korisnih alata i dobrih praksi za korištenje sustava za verzioniranje. Rad će se temeljiti na Git-u, jednom od danas najpopularnijih sustava za verzioniranje.

ABSTRACT

Version Control Systems for quite some time present an integral part of development process and a must have tool for both individual developers and teams as well. However, use of version control systems and choice of proper workflow can at first be challenging. Developers and teams often do not invest enough time to get to know the possibilities of such systems, which results in these systems not being used to their full potential. In this paper we will try to mitigate this problem by identifying and systematizing useful tools and best practices in using version control systems. We will cover the case of Git – one of today’s most popular version control system.

1. INTRODUCTION

Version control systems for quite some time present an integral part of development process and a must have tool for both individual developers and teams as well. Today, there is probably no serious developer or a company which doesn’t use some sort of version control system on their daily basis. Indeed, these systems are relieving developers of tedious and error prone work of managing source code versions. Indeed, they bring to table a lot of features that now make us wonder how we managed to survive without them.

One of the most popular version control systems, initially developed in 2005 for versioning Linux kernel, is Git. Its popularity is owed to it being free, open-source, fast, highly flexible distributed version control system. Its flexibility is reflected in the fact that it is used by both individual developers for small scale projects and huge companies such as Google, Facebook, Microsoft, Twitter, Eclipse for large projects. However, it also means that in order to use Git, both individuals and teams may have to invest significant time to master its possibilities and to use it to its full potential. Learning a syntax of few commands is not going to guarantee you are doing version control properly. There is also multitude of written and unwritten patterns, anti-patterns, do’s and don’ts, best practices, workflows, recommendations etc.

In this paper we will try to mitigate this problem by identifying some useful tools and some best practices in using Git. All this practices should be considered as rules of thumb, and applied if make sense to your particular environment and situation. Second section introduces Git version control system and its basic concepts. Then in third section we list best practices in

using Git. In section four several useful tools and services for Git are presented, including client applications, service providers and other utilities. Finally in section five we discussed our findings and presented conclusion remarks.

2. GIT VERSION CONTROL SYSTEM

Git version control system allows us to easily manage changes and versions of different files. We can Git as a special database or repository containing snapshots (versions) of our files taken at different point in time. Git and other version control systems are especially useful in software development because most files we want to keep track of are source code files. Since source code files are basically textual files, version control systems can understand changes happening to particular file throughout various versions. This allows you to rather easily roll back to any recorded point in your project history, or only inspect what the project or any file looked like at some point. Although not its primary goal, this makes version control systems a great backup tool. Version control system is also a great way to track contributions of individual team members, it makes it easier to find or at least narrow down bug sources, and it promotes code review and team member communication.

One of the most important features version control systems offer is collaboration between team members. This is usually done by setting up shared central repository, by which team members share and synchronize their work. Also, in a more distributed manner, version control systems such as Git allow team members to exchange their work directly with each other, without setting a dedicated central repository.

18 CASE27

However, even in distributed workflows there are usually special team members which are proclaimed project maintainers/managers, and their repository represent official codebase. This is often done in very large teams or open source projects in order to increase security and retain control over project.

Git has quite a number of different concepts and commands. Some of these can even be used for different purposes, so using Git can sometimes be puzzling. However, most of your daily work with Git will revolve around only a few commands.

In Git every team member besides working directory (working copy) has his own local repository to which he commits changes from working directory. Local repository allows member to privately work without disturbing other team members, or to be disturb by others. Of course, since team members do work on the same project, eventually they need to share and synchronize their work. If this collaboration is done through shared central repository, each team member must pull other member’s changes from central repository and, when ready, push his own changes to central repository. Following picture describes basic flow between user’s working directory, local repository and central repository.

Figure 1 Basic flow in Git

There are two scenarios how we can obtain local Git repositories: we can create new local repository using git init command, or we can join existing project and

fetch this project’s repository from central server using command git clone. At his moment our working directory’s state corresponds to the state of project in local repository.

After we make some changes in Working directory and want to save them as a new version (snapshot) of our project, we prepare these changes by adding them to Staging area, and commit them to Local repository. In order to make these changes available to other team member, we push them to Central repository. If other team members have done the same, we can fetch or pull their contribution from Central repository to our local repository.

3. BEST PRACTICES

3.1 Common Git workflows

One of the best features of Git is ability to use it in a way it suits your team or company best. Its flexibility allows one to define and use various different workflows, so it can be hard to decide which is the most appropriate one. Before inventing your own workflow there are some common workflows that we think you should consider,

that can at least serve as a starting point for your own customized workflow.

A team's decision on appropriate Git workflow can depend on several factors: e.g. size and experience of team, location of team members, type of project, followed development process and methodology, implementation technology etc. For example, a team with a lot of experience in using SVN will be more comfortable using some of the centralized workflows. For an open source project in which practically anyone can participate a distributed workflows would suit better, so a more restrictive policy for changing official codebase can be employed. Teams which follow prescribed development proces with strongly emphasized phases, can profit by specifying a workflow which mirrors their development process.

Centralized workflow

Centralized workflow assumes there is one central repository which serves as a collaboration medium, and possibly multiple local user repositories. Members commit regularly in their local repository, and when they want to synronize with others they pull other member's work from central repository and push their own work. In centralized workflow this is usually the only way to collaborate. Central repository is configured as „bare“ repository, which means that unlike members' local repositories, it doesn't have a working copy. This workflow employs very simple branching strategy. It requires only one branch (master) to exist, so members commit their work directly to master branch.

Figure 2 Centralized workflow

Feature branch workflow

Feature Branch workflow is based on Centralized workflow so members continue to collaborate through central repository. However, the difference is in branching strategy. In this workflow, instead of committing directly to master branch, members create new branch for each new feature they start to work on, hence the name. This means that the main codebase in master branch will remain clean, and will get new features when they are fully completed by merging their branches.

In this workflow all development happens in feature branches. They are usually pushed to central repository in order to back up one's work, and to collaborate and

CASE27 19

discuss with other members. Ofcourse, feature branch can also exist only locally. If we want to discuss changes made in a branch, or we need an approval to merge new feature to official codebase, we can utilize mechanism called pull requests. Such workflow is used even in Github development.

Gitflow workflow

GitFlow workflow continues to use central repository as a primary means for collaboration, and builds upon Centralized and Feature Branch workflow. However, besides master branch, it introduces one additional long-running branch – develop branch. Here, the master branch contains only official codebase, while the develop branch is used to branch off and integrate the new features in. No feature branch is merged directly to master branch. Rather, when completed, the feature branch is merged into develop branch, and then develop branch can bi merged into master branch.

Forking workflow (Integration-manager workflow)

Forking workflow is more of distributed nature. It does not prescribe setting up one central repository to which members individually push their changes from their local repositories. Rather, every member has two repositories, one local (private) and one server-side (public) repository. Members make their changes in their local repositories, and when they want to make these changes available to others they push it to their public repository. Only the owner of public repository can push to that repository, others can only pull.

In order to collaborate, one of the members is proclaimed as project maintainer or a manager, and his public repository as an official codebase (canonical repository). Note however, that any member can be project maintainer and his repository official codebase. It is only a matter of convention who will have that role.

Figure 3 Distributed workflow

Since official codebase can only be modified by owner (project maintainer), contributions of other members are

integrated using pull-requests. E.g. when one of the members finishes new feature, he makes it available by pushing it to his public repository. Then by issuing pull request, member notifies project maintainer that new feature is ready to be integrated to official codebase. The project maintainer pulls new feature from member's public repository into his local repository. After the project maintainer makes sure the new feature is correct, he can push it and make it the part of official codebase repository. Since this workflow introduces higher level of security and control over official codebase, it is often used in open-source projects.

Dictator and Lieutenants workflow

Some projects can be so large and complex, that one project maintainer cannot be in charge of managing complete codebase. In such situations Dictator and Lieutenants workflow can be applied. Here, multiple maintainers (called Lieutanants) are assigned with some part of codebase for which they handle pull requests. Additionally all lieutenants answer to member with Dictator role, who only has access to official codebase.The example of using this workflow can be found in linux kernel development.

Development process workflow

Some teams set up their Git workflow in such way it mirrors and simulates their development process. Such workflows usually contain long-running branches which depict important phases in development process, e.g. development, testing, quality assurance, staging, production, release etc. This perhaps forces or makes easier for team members to follow prescribed methodology, and gives each role (developers, testers, integrators, stakeholders) a place to do their job, before moving on to next phase. However, such approach can besides complexity, introduce additional levels of indirection and burden to development process.

3.2 Using branches

Coding in branches is a simple practice that keeps you and your work more organized. Branches let you easily maintain your “in-progress” work separately from your completed, tested, and stable code. This is an effective way to collaborate with others, it will also allow you to automate the deployment of updates and fixes to your servers. There are two cases of coding: you’re either building new features or fixing bugs in an existing codebase.

We could imagine you launched a big Feature X. Things are working nicely together at first and you decide that everything is alright slowly moving on to your next item of business, Feature Y. You start coding and completing the Feature Y, but somewhere along the way you realize that there is a problem with Feature X and its fixing is urgent. If you were working in your default working branch of your repository, you will need to figure out how to save the work you've done so far on Feature Y, rollback the repository to the state where it was when you deployed Feature X, make your fix to the problem we mentioned earlier, do your fix and then re-introduce your work from Feature Y. This is a messy approach and you will most definitely lose some of your work. Instead, what you could do is make a feature or bug-fix branches and let the VCS do the hard work for you. Once you've finished the deployment of Feature X, you could make a branch that is made for sole purpose of deployment of Feature Y. This allows you to work on a separate history in your features without code overwriting one another. Once you're completely sure

20 CASE27

that Feature Y is ready and working and could be released, you merge the branch for Feature Y with the working branch of Feature X. This of course means you can switch and work on one of the branches whenever you want and create more branches from any point in time, perchance a bug-fix? Making a branch for every small bug-fix might be unnecessary but following this pattern of work you could avoid making a big mistake of not making a branch for big bug-fixes, potentially leaving your working branch in a messy state.

Some of the most important practices to follow using branches that represent features or bug fixes:

Try to avoid committing unfinished work to your repository’s default working branch.

Create a branch any time you begin non-trivial work including features and complex bug-fixes.

Don’t forget to delete feature branches once they were merged into stable branch. This will keep your repository clean.

Another reason to use version control is so that you can use your repository as the source to deploy code to your servers. Much like feature and bug-fix branches, environment branches make it easy for you to separate your in-progress code from your stable code. Using environment branches and deploying from them means you will always know exactly what code is running on your servers in each of your environments.

We’ve mentioned “default working branch” – but you can also think of this as your development environment branch. It’s a good idea to keep this branch clean – this is easily done by using feature and bug-fix branches and only merging them back to your development branch once they are tested. In other words, at any point in time your development branch should contain only stable code, as stated above several times.

When your development environment has been updated with features and bug-fixes that are tested, you can use your VCS to do a diff between your stable (master) branch and staging branch to see what would be deployed that’s not currently on staging. This is a great opportunity to look for low quality or incomplete code, debug code, and other development leftovers that shouldn’t be deployed. This diff can also be helpful in writing release notes. In order to keep your environment branches in sync with the environments, it’s a best practice to only execute a merge into an environment branch at the time you intend to deploy. If you complete a merge without deploying, your environment branch will be out of sync with your actual production environment.

With environment branches, you never want to commit changes directly to the branch. By only merging code from your stable branch into staging or production branches, you ensure that changes are flowing in one direction: from feature and bug-fix branches to stable and staging environments, and from stable to production. This keeps your history clean, and again, lets you be confident about knowing what code is running in which environments.

Some of best practices in environment branches are following:

Use your repository’s default working branch as your “stable” branch.

Create a branch for each environment, including staging and production.

Never merge into an environment branch unless you are ready to deploy to that environment.

Perform a diff between branches before merging—this can help prevent merging something that

wasn't intended, and can also help with writing release notes.

Merges should only flow in one direction: first from feature to staging for testing; then from feature to stable once tested; then from stable to production to ship.

3.3 Committing changes

One should commit his work often. This can prevent unsaved work being lost. Comments to your commits should be meaningful and self-explanatory, because in the end, these comments represent a handbook to your project's making process. Also, commit should be atomic, meaning they contain changes related to one particular issue, task or functionality.

Proper commits ease things up for you, your team members and others, by requiring less time to spend figuring out what actually happend in particular project. If a bug is found in the later stages of the project and it’s concluded on what commit this bug was made, good comments make things easier to understand what the purpose of that commit was. In order to isolate exact revision which introduced a bug, we can use bisect command.

Good commenting does not only help your team, but also helps you. If you have to rework some part of the project that you worked on months ago, good comments will save you time spent figuring out what you intended to do back then.

Commit your work often and give some meaning to your comments. This does not take much time, but helps you and your colleagues and can save your team a lot of time later on.

3.4 Resolving conflicts

Although conflicts are not something to be feared (at least in Git), resolving conflicts can require careful analysis and discussion with other team members, which in the end can be quite time consuming. So one of the strategies in dealing with conflicts is to try to actually avoid conflicts. This means that one should concentrate on much more frequent and smaller commits in order to avoid merging conflicts. Of course, that merely depends on the situation and thus we will share a few of the best gathered practices tied with solving conflicts – not counting the one mentioned in the beginning.

One of the most advised methods is to share the work you've done with your teammates. If commits are being done on a more frequent scale – conflicts will be easier to track and in the end, to resolve. Conflicts are tied with the local machine on which the work is being done, so one shouldn't stop sharing on a more frequent basis due to being afraid of breaking the project. So, commit often and resolve conflicts as soon as you see them. Having frequent commits helps with resolving conflicts because in small scale commits there won't be as many conflicts as it would be in large scale commits.

So far we have been talking about avoiding conflicts and not letting them swarm you or the team. But let's say that conflicts just can't be avoided and that you are sure that there will be some. One of the most important things is that you think about the documentation. Not only with fixing conflicts, but with overall process of pushing your code on Git. Once you've successfully resolved a specific conflict, make a note – say what exactly was fixed, how, what was changed, and what the source of the error was.

CASE27 21

Let's say that two members of a certain team are editing the same file, the same lines of code, and at the same time. Changes will be made, obviously different, and we will face a conflict. The best possible way to resolve that conflict, without relying that much on the software itself is to see who else has been modifying the file. That way through a discussion and a bit of backtracking – conflicts can be resolved without much trouble coming from pin-pointing the issue.

Git itself already says a lot to us when we step into a conflict. But, what if we wanted to make it even better and a bit easier to read and handle? The answer lies in merging tools. Using the git config command, one can set up the merging tool mostly to his liking. So, what do we actually get with a tool like that? Well, it shows us the changes that were made on a particular file, but also provides us with an option to merge one of the shown files into the final version of the file that will be stored into the project tree. Depending on which tool one decides to use, the code that was merged into the final

file can be edited even further. After that's done, changing the file is as easy as closing the tool which will then trigger the git add command and resolve the conflict.

Considering the above described scenario – let's say that you take one of the given options and whilst doing so you actually end up making the code being worse, slower or overall not as good as it was before. Luckily merging tools also come with the undo option which enables it's user to backtrack to the previous state of the affected file.

Lastly – we want to note that Git is extremely helpful and offers us a lot of options with solving conflicts and editing the code itself. It helps no matter if we are working in large teams and on large, medium or actually small projects. However we would like to stress that benefits of using Git are limited when combined with bad team coordination and overall bad project management. What does that actually mean? Well, it means that git as good as the team which uses the software is.

4. TOOLS

4.1 Service providers

For users to collaborate, depending on workflow, Git assumes either setting up a public central repository or a public repository for each user. There is a number of

services which offer hosting and managing these public repositories. Most popular ones are listed in Error! Reference source not found..

4.2 Client applications

Command line interface is primary way of interacting with Git, allowing access to all Git's commands and options. However, many users choose to work with Git through GUI client applications, which may provide better user experience and easier access to some functionalities (such as browsing history, merging, resolving conflicts etc). Error! Reference source not found. presents some of the most popupar GUI

standalone and IDE integrated client applications:

4.3 Other utilities

Table 2 presents several Git standalone and integrated utilities for Git such as: merging tools, scripting tools, user statistics generators etc.

Name Type Platform Cost

Meldl Merge tool All Free

JavaGit Library All Free

Diffmerge Merge tool All Free

Gitolite Authorization Layer All Free

Git Hooks Scripting tool All Free

Git merge tool Merge tool All Free

Gitinspector User statistics All Free

Diffuse Text file comparison Win Free

EGit Team provider interface All Free

Flashbake Commit message generator Linux, OS X Free

Table 2 Other useful tools for Git

5. CONCLUSION

Git's flexibility allows vast number of different workflows and ways to use it. You can customize it to suit your needs. However this flexibility and customizability comes with price in a form of Git's complexity. Indeed, in order to explore Git's full potential one needs to invest significant time and effort. Unfortunately, a large number of developers pressed with their everyday activities and project deadlines do not have enough time to set aside. Nevertheless, we strongly believe that no serious individual developer and especially developer teams should perform their every day jobs without version control system such as Git. For this reason, in this

Name Platform Cost Type Popularity

GitHub for Mac OS X Free Interface tool Client *****

GitHub for Windows Win Free Interface tool Client *****

Gitbox OS X Free / 14.99$ Interface tool Client ***

GitX-dev OS X Free Interface tool Client ****

Git Extensions Win Free Windows explorer integration ****

Tower OS X Trial / 59$ Git Client *****

SourceTree OS X, Win Free Interface tool Client ***

git-cola All Free Interface tool Client **

SmartGit All Free (non commercial) / 79$ Interface tool Client ****

GitEye All Free Integrated interface tool ***

gitg Linux Free Gnome Shell Integration **

TortoiseGit Win Free Windows Shell Extension ****

IDEs supporting Git Microsfot Visual studio, Android studio, Eclipse, Netbeans, IntelliJ, Ninja-IDE

Table 1 Git client applications

22 CASE27

paper, we reported several best practices and useful tools which provide help in using Git.

One of the most important things, which determins overall strategy in using Git, is chosen workflow. We listed several common workflows which can be applied as they are, or they can provide a solid base for developing customized workflows. Also, we indicated a few recommended practices in using branches, which are one of the most advocated Git's features and inseparable part of Git workflows.

In order to collaborate with others and contribute to a project, user wraps his work in a form of commits. Because commits represent a fundamental part of versioning process and influence the quality of this process, we provided a several useful guidelines.

If two team members simultaneously make changes in the same part of the same file, a conflict will occur. In Git, conflicts are nothing to be afraid off, and are quite common. However, if they are too frequent, one should question wheather project tasks are properly distributed

to team members. Nevertheless, we bring few recommendation when dealing with conflicts.

Quite a number of tools and services exist which can help you in using Git. They range from GUI client applications which tend to replace Git command line, to various utility applications for Git statistics, scripting, merging and conflict resolution. Also, since a centralized Git workflows are quite popular, we listed several services which provide Git hosting.

During the writting of this paper a few interesting topics for further exploration and research came up:

Further systematization of best practices in using version control systems,

Formalization of these practices in a form of patterns,

Impact of various factors on choosing proper version control system workflow,

Supporting various software development methodologies with version control system.

References:

1 S. Chacon and B. Straub, Pro Git: [everything you need to know about Git], 2. ed. New York, NY: Apress, 2014.

2 R. Hodson, “Ry’s Git Tutorial,” RyPress, Dec-2012. [Online]. Available: http://rypress.com/tutorials/git/index.

3 “Git Workflows That Work | End Point Blog.” .

4 T. Günther, Learn Version Control with Git. 2015.

5 “Git Tutorials and Training,” Atlassian Git Tutorial, May-2015. [Online]. Available: https://www.atlassian.com/git/tutorials/. [Accessed: 24-May-2015].

6 “Git Best Practices: Workflow Guidelines,” Lullabot. [Online]. Available: https://www.lullabot.com/blog/article/git-best-practices-workflow-guidelines. [Accessed: 24-May-2015].

7 “A successful Git branching model,” nvie.com. [Online]. Available: http://nvie.com/posts/a-successful-git-branching-model/. [Accessed: 24-May-2015].

8 S. Robertson, “Commit Often, Perfect Later, Publish Once: Git Best Practices,” 2012. [Online]. Available: https://sethrobertson.github.io/GitBestPractices/.

9 M. Mijač, I. Švogor, and B. Tomaš, Odabrana poglavlja programskog inženjerstva. Varaždin: FOI, 2014.

10 E. Pidoux, Git Best Practices Guide. Packt Publishing, 2014.

11 B. Binkovitz, “Branching, Merging, Commits, and Tagging: Basics and Best Practices.”

Provider

Free Plan Pricing Plans Code

Review Time

Tracking Private Repos

Public Repos

Users Price

($/month) Private Repos

Users

Assembla 1 1 Unlimited $24 - $199 Unlimited 12 - 100 No Yes

Bitbucket Unlimited Unlimited 5 $10 - $200 Unlimited 10 -

Unlimited Yes Yes

CloudForge Unlimited

(trial) Unlimited

(trial) Unlimited

(trial) $2 per-user - $10 per-user

Unlimited Unlimited No Yes

Codebase 1 1 2 $8 - $65 3 - 40 10 -

Unlimited No Yes

GitEnterprise Unlimited Unlimited 10 $30 - $10

per-user/year Unlimited

25 - Unlimited

No Yes

GitHub None Unlimited Unlimited $7 - $200 5 - 125 Unlimited Yes Yes

GitLab None None None $20 - $249 Unlimited 20 - 100 Yes Yes

Unfuddle Unlimited

(trial) Unlimited

(trial) 10 (trial) $19 - $249 Unlimited 10 - 50 No Yes

Visual Studio Online

Unlimited Unlimited 5 $20 per-user

- $60 per-user

Unlimited Unlimited Yes Yes

Table 3 Popular service providers

CASE27 23

Information on authors:

Igor Tepavac

igotepava@foi.hr

Faculty of Organization and Informatics

Igor Tepavac is currently a second year undergraduate student of Information Systems at the Faculty of Organization and Informatics in Varaždin. He is interested in software development for desktop, web and mobile platforms. Also, he is consistently learning about new development technologies which are upgrading his knowledge and experience.

Krešimir Valjevac

kvaljeva@foi.hr

Faculty of Organization and Informatics

Krešimir Valjevac is a third year undergraduate student of Information Systems studying at Faculty of Organization and Informatics. He is consistently learning new technologies and his main point of interests are Mobile, Web and desktop development. He has participated on SEETech hackathon in 2015. where he attained the sixth place. He has been working as a volunteer for the past 7 years for a German company named Gameforge where he developed his soft skills.

Stefano Kliba

skliba@foi.hr

Faculty of Organization and Informatics

Stefano Kliba is a regular third year college student at Faculty of Organization and Informatics, University of Zagreb, in Varaždin. He is working towards my bachelor's degree in Information systems. He's primary interest is in mobile development, particulary Android. He has participated in several competitions, such as Hamag Bicro's Hackathon where he and his team were placed 6th out of 20 competitors, App Start Contest which is currently in progress. Currently working on several mobile development projects. He is also a member of Laboratory for mobile technologies (MT Lab) at Faculty of Organization and Informatics.

Marko Mijač

mmijac@foi.hr

Faculty of Organization and Informatics

Pavlinska 2

42000 Varaždin

tel: +385 42 390 853

fax: +385 42 213 413

Marko Mijač, as of July 2011 works at the Faculty of Organization and Informatics in Varaždin as a project KI Expert 2012, project MEDINFO associate, and as a teaching assistant on courses related to software engineering and information systems. Prior to his current employment he worked as a developer of intranet production planning system at Boxmark Leather d.o.o. He is interested in web, desktop and mobile applications development in various platforms and technologies.

24 CASE27

CASE27 25

VIŠESTRUKO NASLJEĐIVANJE - SAN ILI JAVA 8?

MULTIPLE INHERITANCE - EIFFEL, C++, SCALA, JAVA 8

Zlatko Sirotić

SAŽETAK

Višestruko nasljeđivanje klasa je dosta dugo vremena neopravdano držano kao kompleksno i nepotrebno. Vjerojatno je jedan od glavnih razloga taj što je višestruko nasljeđivanje u jeziku C++ relativno loše riješeno. Višestruko nasljeđivanje u C++ uvedeno je naknadno, 1989., tj. nije uvedeno od početka.

Na temelju takvih loših iskustava, dizajneri jezika Java (a poslije i C#) odlučili su da ne podrže višestruko nasljeđivanje klasa. No, jezik Eiffel je imao višestruko nasljeđivanje od pocetka (1986.) i smatra se da od svih OOPL-a najbolje podržava višestruko nasljeđivanje. U Javi 8 krenulo se u pravcu uvođenja višestrukog nasljeđivanja klasa.

U radu se prikazuje kako je višestruko nasljeđivanje podržano u jezicima Eiffel, C++, Scala i Java 8.

ABSTRACT

Multiple inheritance has been kept as complex and unnecessary, quite a long time. Probably one of the main reasons is that multiple inheritance in C++ is relatively poorly designed. Multiple inheritance in C++ was not introduced from the beginning, it was introduced later, in 1989.

Based on these bad experiences, the designers of Java (and later C#) decided not to support multiple inheritance of classes. However, the Eiffel language has multiple inheritance from the beginning (1986), and of all OOPLs, Eiffel is the best in supporting multiple inheritance. Java 8 has moved in the direction of introducing multiple inheritance of classes.

The paper shows how is multiple inheritance supported in languages Eiffel, C++, Scala and Java 8.

1. UVOD

Već dugo vremena u praksi objektnog programiranja uvriježeno je mišljenje da je višestruko nasljeđivanje "loša stvar". Vjerojatno je jedan od glavnih razloga za takvo razmišljanje taj što je višestruko nasljeđivanje u jeziku C++, jeziku koji je uveo objektno orijentirano programiranje u "široke mase" početkom 80-ih godina (ali, ne zaboravimo da je prvi OOPL nastao 1967. - Simula 67), relativno loše riješeno. Višestruko nasljeđivanje u C++ uvedeno je naknadno, 1989., tj. nije uvedeno od početka.

Nije pomoglo niti to što postoji jedan jezik u kojem je višestruko nasljeđivanje izuzetno dobro riješeno od početka (1986.) – to je jezik Eiffel. Nažalost, dizajneri jezika Java (a poslije i C#) odlučili su da ne podrže višestruko nasljeđivanje klasa. Istina, postoji višestruko nasljeđivanje sučelja (interface), ali sučelja su samo potpuno apstraktne klase, bez ikakve implementacije (točnije, tako je bilo do Jave 8 i pojave default metoda).

Evo primjera kako autori u poznatoj (i izuzetno dobroj) knjizi o Javi [6] objašnjavaju kako nam se samo čini da nam treba višestruko nasljeđivanje (slika 1.):

Glavno opravdavanje tog svog stava vide u poznatom problemu, tzv. "dijamantne smrti", koji se javlja kod tzv. ponovljenog nasljeđivanja (repeated inheritance), kad jedna klasa (u primjeru na slici 2. to je klasa ComboDrive) nasljeđuje od dvije klase (na slici su to CDBurner i DVDBurner), koje obje nasljeđuju jednu te istu klasu (na slici je to DigitalRecorder), a obje klase su nadjačale (override) metodu koju su naslijedile od vršne klase (na

Slika 1. Autori knjige kao da pitaju: "Valjda ne mislite da nam je potrebno višestruko

nasljeđivanje?"; Izvor: [6]

slici je to metoda burn), pa se onda postavlja pitanje koju

će varijantu nadjačane metode pozivati najdonja klasa (ComboDrive).

Kako ćemo vidjeti u 3. točki, jezik Eiffel ima vrlo učinkovit mehanizam za rješavanje tog problema, pa taj problem (sam po sebi) ne može biti opravdanje za odustajanje od višestrukog nasljeđivanja.

Evo što o višestrukom nasljeđivanju kažu neki drugi znanstvenici. Prvo Luca Cardelli u "A Semantic of Multiple Inheritance" (1988.):

26 CASE27

Slika 2. Kako autori "opravdavaju" zašto je višestruko nasljeđivanje loše; Izvor: [6]

"A class can sometimes be considered a subclass of two incompatible superclasses; then an arbitrary decision has to be made to determine which superclass to use. This problem leads naturally to the idea of multiple inheritance.Multiple inheritance occurs when an object can belong to several incomparable superclasses: the subclass relation is no longer constrained to form a tree, but can form a dag. Multiple inheritance is more elegant than simple inheritance in describing class hierarchies, but is more difficult to implement."

Evo što kaže Bertrand Meyer u "Object Oriented Software Construction" (1997.):

"Multiple inheritance is indispensable when you want to state explicitly that a certain class possesses some properties beyond the basic abstraction that it represents. Consider for example a mechanism that makes object structures persistent (storable on long-term storage)…

The discussion of inheritance methodology will define it as inheritance of the structural kind. Without multiple inheritance, there would be no way to specify that a certain abstraction must possess two structural properties — numeric and storable, comparable and hashable. Selecting one of them as the parent would be like having to choose between your father and your mother."

U nastavku se u točkama od 3. do 6. daje prikaz rješenja višestrukog nasljeđivanja u jezicima Eiffel, C++, Scala i Java (verzije 8). Redoslijed prikaza nije odabran na temelju starosti jezika (jer bi onda bio ovakav: C++, Eiffel, C++, Java, Scala), već na temelju pojave višestrukog nasljeđivanja u određenom jeziku (Eiffel 1986. C++ 1989., Scala 2003., Java 2014.). U sljedećoj (2.) točki daje se kratka usporedba nekih osobina navedenih jezika.

2. KRATKA USPOREDBA PROMATRANIH JEZIKA (EIFFELL, C++, SCALA, JAVA)

Sva četiri jezika imaju zajedničkog pretka – Algol (ALGOrithmic Language), kojeg su napravili Backus i Naur daleke (za informatiku) 1958. godine. Algol je ostavio ogroman utjecaj na programske jezike koji su došli nakon njega. Poznati informatičar C.A.R. Hoare duhovito je rekao:

"Algol je bio toliko ispred svog vremena da je predstavljao poboljšanje ne samo u odnosu na sve svoje prethodnike, nego i u odnosu na skoro sve svoje nasljednike".

Jedan od "Algol-oidnih" jezika bio je i Simula 1, koji je bio namijenjen uglavnom za simulacije.

Kasnija verzija, Simula 67 (nastala 1967. godine, a autori su Kristen Nygaard i Ole-Johan Dahl), je jezik opće namjene i toprvi OOPL u povijesti!

Svaki jezik ima svoj stil za pisanje imena klasa, atributa, metoda, parametara i lokalnih varijabli. Eiffel nije osjetljiv na velika/mala slova,dok C++, Java i Scala jesu (case-sensitive).

Klasa, a ne objekt, je osnovni element objektno-orijentiranih programskih jezika (možda bi se trebali zvati COPL, umjesto OOPL). Klasa je dio programskog koda,takav da ima osobine i modula i tipa.

Pojednostavljeno se može reći da vrijedi formula: KLASA = MODUL + TIP. Klasa definira podatke (atribute) i ponašanje (metode, rutine, funkcije). Zbog jednostavnije usporedbe četiri OOPL jezika, koristit ćemo pojmove "atribut" i "metoda".

Nasljeđivanje je jedna od tri osnovne operacije računa klasa (class calculus). Ostale dvije su agregacija i generičnost. Klasa od koje se nasljeđuje je nadklasa, a klasa koja nasljeđuje je podklasa. Podklasa može imati nove metode i atribute (koje nadklasa nema), ali može i nadjačati (overriding) metode iz nadklase. Eiffel ima ključnu riječ redefine, a Scala override, kojom programer eksplicitno kaže da nadjačava određenu metodu. C++ i Java ne koriste ključne riječi (Java ima anotaciju), nego se nadjačavanje izražava tako da se u podklasi deklarira metoda sa istom signaturom kao što je metoda u nadklasi. Eiffel i Scala (eksplicitan) način izražavanja je bolji, jer smanjuje mogućnost programerske greške.

Stog (stack) i gomila ili hrpa (heap) su vrlo važne strukture podataka i za ne-OOPL i za OOPL. I kod ne-OOPL i kod OOPL se stog koristi za spremanje lokalnih varijabli i argumenata (neko kaže parametara) funkcija / procedura. C++ i Eiffel mogu na stogu imati i objekte, koji nestaju nakon što završi funkcija / procedura koja ih je kreirala. Naravno, mogu imati objekte i na gomili. Java i Scala mogu imati objekte samo na gomili, a na stogu Java može držati samo varijable primitivnog tipa, ili reference na objekte koji su na gomili (Java i Scala). C++ objekti na gomili se ne brišu automatski kad više nema referenci na njih, za razliku od Eiffela, Jave i Scale, gdje ih automatski briše garbage collector.

"Pjesnički rečeno", polimorfizam omogućava da objektima različitog tipa pošaljemo istu poruku i da oni na tu poruku reagiraju na odgovarajući način. Riječ je o tome da možemo varijabli određenog tipa pridružiti ne samo varijablu istog tipa, nego i varijablu podtipa (polimorfično pridruživanje).

Što će se desiti ako imamo neku metodu koja je nadjačana u podklasi i ako nakon polimorfičnog pridruživanja pozovemo tu metodu naredbom "varijabla_nadklase.metoda" - da li će se izvršiti verzija metode iz nadklase ili verzija iz podklase? Odgovor je – metoda iz podklase, zahvaljujući tzv. dinamičkom povezivanju - dynamic binding(ili dynamic method dispatch). Za C++ to vrijedi samo ako je metoda u nadklasi označena sa virtual i ako koristimo dinamičke objekte (na heapu).

Eiffel kod nadjačavanja metoda podržava tzv. covariance i za parametre metoda i za povratnu (return) vrijednost

CASE27 27

funkcije i za atribute, tj. oni ne moraju biti istog tipa kao u izvornoj metodi, već mogu biti podtipa. C++ ima novariance pristup za parametre, ali po Standardu od 1997. podržava covariance za povratne vrijednosti funkcije. Java se ponaša kao C++ od verzije Java 5. Scala ima isto ponašanje. Nekad je logičan izbor covariance, a nekad contravariance, pogotovo kod tzv. nasljeđivanja implementacije. Međutim, covariance i contravariance nad parametrima mogu dovesti i do određenih problema, koje kompajler treba pokušati spriječiti (npr. Eiffel kompajler).

3. EIFFEL

Eiffel je 1985. godine dizajnirao (a 1986. je napravljen prvi compiler) Bertrand Meyer, jedan od najvećih autoriteta na području OOPL-a. Eiffel je od početka podržavao višestruko nasljeđivanje, generičke klase, obradu iznimaka, garbage collection i metodu Design by Contract (DBC). Kasnije su mu dodani agenti, nasljeđivanje implementacije (uz nasljeđivanje tipa) i metoda za konkurentno programiranje Simple Concurrent Object-Oriented Programming (SCOOP).

U široj je javnosti daleko manje poznat nego C++ i Java, ali ga mnogi autoriteti smatraju danas najboljim OOPL jezikom. Eiffel je od 2005. godine ECMA standardiziran, a od 2006. ISO standardiziran. U nastavku je primjer programskog koda u jeziku Eiffel. Klasa ZIVOTINJA ima

metodu-konstruktor, koja se u ovom slučaju zove kao i klasa (ali u Eiffelu to ne mora biti tako), dva atributa, jednu metodu-proceduru (prikazi_podatke) i jednu metodu-funkciju (visina_inch):

class ZIVOTINJA

create zivotinja

feature {ANY}

ime: STRING

visina_cm: DOUBLE

zivotinja (p_ime: STRING; p_visina_cm:

REAL) is

do ime := p_ime; visina_cm :=

p_visina_cm end

prikazi_podatke is

do

print (" Ime: "); print (ime); ...

end

visina_inch: REAL is

do Result := visina_cm / 2.54 end

end

Eiffel poznaje četiri oblika redeklaracije nadjačane metode u podklasi (slika 3.). I efektivna (effective) i apstraktna (deferred) metoda nadklase se može redefinirati (redefinition) u podklasi. Apstraktna metoda iz nadklase može se u podklasi učiniti efektivnom (effecting). Suprotno tome, efektivna metoda iz nadklase može se u podklasi učiniti apstraktnom (undefinition).

Slika 3. Različiti načini redeklaracije metoda u jeziku Eiffel;

Izvor: [4]

U Eiffel "ekosustavu" često se umjesto UML grafičke notacije koristi BON (Bussines Object Notation; Jean-Marc Nerson i Kim Waldén, 1989.) grafička notacija za prikaz klasa, koja ima slične mogućnosti kao UML notacija, ali je jednostavnija. Slika 4. prikazuje primjer u kojem efektivne klase TAXI i TRAM nasljeđuju apstraktnu klasu VEHICLE, pri čemu klasa TAXI nadjačava metodu take, pa ona postaje efektivna, a klasa DISPATCH_TAXI, podklasa od TAXI, redefinira tu metodu.

Slika 4. BON (Bussines Object Notation) grafička notacija za prikaz klasa

(kao UML, ali jednostavnija); Izvor: [4]

U sljedećem primjeru klasa TROLLEY nasljeđuje klase TRAM i BUS, pri čemu redefinira metode add_station i remove_station iz klase TRAM:

class TROLLEY inherit

TRAM

redefine add_station, remove_station

end

BUS

feature

...

end

Slika 5. prikazuje primjer u kojem klasa C nasljeđuje dvije klase A i B, koje imaju metodu istog imena f. Kako riješiti taj problem?

Slika 5. Nasljeđivanje dvije klase koje imaju metodu istog imena; Izvor: [4]

Sljedeći primjer pokazuje kako se u jeziku Eiffel rješava taj problem. Jednostavno, jedna od metoda (ili obje) iz nadklase se preimenuje. U ovom slučaju preimenuje se metoda f iz klase A:

class C inherit

A

rename f as first_f

B

feature

...

end

Slika 6. prikazuje primjer ponovljenog nasljeđivanja (repeated inheritance). Klasa DRIVER ima tri atributa (i dvije metode), a nju nasljeđuju klase FRANCH_DRIVER i US_DRIVER. Obje klase nasljeđuje klasa FRANCH_US_DRIVER. Postavlja se pitanje – koje atribute ima ta klasa (FRANCH_US_DRIVER)?

28 CASE27

Slika 6. Primjer ponovljenog nasljeđivanja (repeated inheritance); Izvor: [3]

Slika 7. daje odgovor na prethodno pitanje. U klasi FRANCH_US_DRIVER preimenovat ćemo dva atributa (i jednu metodu) naslijeđena iz klase FRANCH_DRIVER, i dva atributa (i jednu metodu) naslijeđena iz klase US_DRIVER.

Slika 7. Preimenovanje atributa kod ponovljenog nasljeđivanja (repeated inheritance);

Izvor: [3]

Slijedi odgovarajući programski kod:

class FRENCH_US_DRIVER inherit

FRENCH_DRIVER

rename

address as french_address,

violation_count as

french_violation_count,

pay_fee as pay_french_fee

end

US_DRIVER

rename

address as us_address,

violation_count as

us_violation_count,

pay_fee as pay_us_fee

end

feature

...

end -- class FRENCH_US_DRIVER

Slika 8. pokazuje kako izgledaju atributi klase FRANCH_US_DRIVER, u odnosu na vršnu klasu DRIVER. Vidi se da atribut age nije dupliran (u klasi FRANCH_US_DRIVER), dok su duplirani atributi address i violation_count.

Slika 8. Što se desilo sa atributima kod ponovljenog nasljeđivanja; Izvor: [3]

Pretpostavimo da klase B i C nasljeđuju klasu A,te klasa D nasljeđuje obje klase. Što ako je metoda f iz A redeklarirana u (npr.) klasi B, a obje su varijante efektivne (nisu deferred, tj. apstraktne), kao što pokazuje slika 9.?

Slika 9. Primjer ponovljenog nasljeđivanja, sa redeklariranjem i bez replikacije; Izvor: [3]

Tada moramo koristiti ključnu riječ undefine, kako bismo jednu od njih učinili apstraktnom (ovdje onu iz C). Slijedi odgovarajući programski kod:

class D inherit

B

C

undefine f end

feature

...

end

Pretpostavim da imamo situaciju sličnu prethodnoj, ali je sada metoda f iz A istovremeno i redeklarirana u klasi B, i mijenjano joj je ime iz f u bf, kako pokazuje slika 10.

Slika 10. Primjer ponovljenog nasljeđivanja, sa

redeklariranjem i sa replikacijom; Izvor: [3]

Sada imamo replikaciju (te metode), pa u klasi D moramo

odabrati koju od te dvije varijante želimo koristiti, pomoću ključne riječi select (ovdje onu iz C). Slijedi odgovarajući programski kod:

CASE27 29

class D inherit

B

C

select f end

feature ... end

4. C++

Početkom 70-ih godina napravljen je programski jezik C (autor je Dennis Ritchie), također Algol-ov potomak, kao jezik za sistemsko programiranje operativnog sustava UNIX. U isto vrijeme nastao je i Pascal, isto potomak Algol-a. Za većinu kasnijih programskih jezika možemo reći da (barem po sintaksi) pripadaju C ili Pascal "struji".

Nadograđujući C sa objektno orijentiranim mogućnostima (uz zadržavanje kompatibilnosti), Bjarne Stroustrup je 1983. godine napravio C++ (1986. godine je objavio knjigu "The C++ Programming Language").

Tokom vremena je C++ dobivao neke vrlo značajne mogućnosti, koje na početku nije imao: višestruko nasljeđivanje, generičke klase (predloške), obradu iznimaka (exceptions) i dr. 1997. godine donesen je ISO standard. U standardu C++11 uvedene su npr. i lambda funkcije. Najnoviji je C++14 (koji donosi manja poboljšanja).

Slijedi primjer C++ programskog koda, koji je ekvivalentan programskom kodu koji je prethodno prikazan kod jezika Eiffel. Da bismo postigli što veću sličnost primjera u svim jezicima, sljedeća C++ klasa ima javne atribute i metode, iako bi u C++ stilu bilo bolje napraviti privatne atribute i odgovarajuće "get/set" metode za čitanje/postavljanje atributa:

#include <string>

#include <iostream>

using namespace std;

class Zivotinja {

public:

string ime;

double visina_cm;

Zivotinja(string p_ime, double

p_visina_cm);

virtual void prikazi_podatke();

virtual double visina_inch();

};

// definicija klase

Zivotinja::Zivotinja(string p_ime,double

p_visina_cm) {

ime = p_ime; visina_cm = p_visina_cm;

}

void Zivotinja::prikazi_podatke() {

cout << "Ime: " << ime << ...;

}

double Zivotinja::visina_inch() {

return visina_cm / 2.54;

}

// ovaj kod nije dio nijedne klase

void main() {

Zivotinja* l_dz = new Zivotinja("FIFI",

20);

l_dz->prikazi_podatke();

delete l_dz;

}

Kako je već prije rečeno, višestruko nasljeđivanje je u C++ uvedeno naknadno, 1989. godine. Mehanizam višestrukog nasljeđivanja u C++ nije tako fleksibilan kao Eiffel

mehanizam. Između ostalog, C++ nema preimenovanje (rename) metoda. Ako se od dvije klase naslijede dvije funkcije istog imena, mora se koristiti scope resolution operator za rješavanje dvosmislenosti, kako prikazuje sljedeći kod:

class A {void f() {…}};

class B {void f() {…}};

class C : public A, public B {…};

void test()

{

C∗ p = new C();

// p–>f(); This call would be ambiguous -

invalid;

p–>A::f();

p–>B::f();

}

Ako se kod ponovljenog nasljeđivanja želi raditi replikacija člana vršne klase, opet se koristi scope resolution operator, kako pokazuje sljedeći primjer:

class D {int n;};

class E : public D {};

class F : public D {};

class G : public E, public F {};

void f()

{

G∗ p = new G();

// p–>n = 0; // This would be invalid:

which n?

// Valid, assigns to version replicated

in E

p–>E::D::n = 0;

// Valid, assigns to version replicated

in F

p–>F::D::n = 0;

}

Međutim, ako želimo da se oba člana naslijeđena iz vršne klase spoje u jedan, onda se javljaju dodatne komplikacije (koje ovdje nećemo iznositi).

5. SCALA

Programski jezik Scala kreirao je Martin Odersky, profesor na Ecole Polytechnique Fédérale de Lausanne (EPFL). Krajem 80-ih doktorirao je na ETH Zürich kod profesora Niklausa Wirtha (kreatora Pascala i Module-2). Nakon toga naročito se bavio istraživanjima u području funkcijskih jezika, zajedno sa kolegom Philom Wadlerom (jednim od dva glavna kreatora funkcijskog jezika Haskell).

Kada je izašla Java, Odersky i Wadler su 1996. napravili jezik Pizza nad JVM-om. Na temelju projekta Pizza, napravili su 1997./98. Generic Java (GJ), koji je uveden u Javu 5 (malo ga je nadopunio Gilad Bracha, sa wildcardsima). Dok je za primjenu GJ-a Sun čekao skoro 6 godina, odmah su preuzeli Java kompajler koji je Odersky napravio za GJ. Taj se kompajler koristi od Jave 1.3.

Odersky je 2002. počeo raditi novi jezik Scala. Tako je nazvana kako bi se naglasila njena skalabilnost. Prva javna verzija izašla je 2003.; trenutačna verzija je 2.11, a

30 CASE27

sljedeća verzija 2.12 radit će isključivo na JVM 8! Od tada, Scala se sve više koristi u praksi. Došla je među prvih 50 najkorištenijih jezika, sa tendencijom da se probije među prvih 20. Zanimanje za Scalu naročito se povećalo kada je Twitter prebacio glavne dijelove svojih programa iz jezika Ruby u Scalu.

Scala je čisti objektno-orijentirani jezik (sa statičkom provjerom stipova). Osim toga, na temelju objektno-orijentiranih mogućnosti izgrađene su i brojne funkcijske mogućnosti, tako da je Scala i funkcijski jezik (ali nije čisti). Sa funkcijskim osobinama došle su i neke osobine koje su vrlo pogodne za konkurentno programiranje. Scala je izvrstan jezik i za pisanje DSL-ova (Domain-Specific Language), jezika za specifičnu problemsku domenu. No, važno je da se može programirati u Scali bez da se napusti Java, jer se Java i Scala programski kod mogu jako dobro upotpunjavati.

Vezano za višestruko nasljeđivanje, Scala nema potpuno višestruko nasljeđivanje kao npr. Eiffel. U Scali, klasa može naslijediti samo jednu (direktnu) nadklasu, ali zato može naslijediti više traitova. Može izgledati da je trait nešto kao

Java sučelje sa konkretnim metodama. No, trait može imati skoro sve što ima i klasa, npr. može imati i polja, a ne samo metode. Trait se, zapravo, kompajlira u Java sučelje i pripadajuće pomoćne klase koje sadrže implementaciju metoda i atributa.

Iako traitovi sliče na klase, razlikuju se u dvije važne stvari. Prvo, trait nema parametre klasa. Drugo, kod višestrukog nasljeđivanja klasa, metoda koja se poziva sa super može se odrediti tamo gdje se poziv nalazi. Kod traitova se to, međutim, određuje metodom koja se zove linearizacija (linearization) klase i traitova (koji su miksani s tom klasom). Slijedi primjer programskog koda za linearizaciju.

class Animal

trait Furry extends Animal

trait HasLegs extends Animal

trait FourLegged extends HasLegs

class Cat extends Animal with Furry with

FourLegged

Slika 11 prikazuje na tom primjeru hijerarhiju klasa i traitova, te linearizaciju. Nasljeđivanje se prikazuje pomoću tradicionalne UML notacije: strelice sa bijelim, trokutastim vrhovima označavaju nasljeđivanje (strelice pokazuju prema nadtipu). Strelice sa crnim vrhovima označavaju linearizaciju. Te strelice kreću se u smjeru u kojem se dešavaju pozivi super metoda:

Slika 11. Hijerarhija nasljeđivanja i linearizacija klase Cat; Izvor: [5]

Trait se može koristiti i selektivno na razini objekta. Npr., pretpostavimo da klasa Macka ne nasljeđuje trait Programer. Instanca (objekt) ipak može naslijediti taj trait:

val jakoPametnaMacka = new Macka("Mica

maca") with Programer

Slijedi primjer rezolucije (rješavanja) konflikta kod nasljeđivanja dvije metode istog imena. To programer rješava eksplicitno (za razliku od Eiffela):

trait Hodor {

def speak = "Hodor!"

}

trait Stark {

def speak = "Winter is coming"

}

class StarkHodor extends Hodor with Stark {

override def speak = "Hodoris coming!"

// we can also use super[Hodor].speak

}

6. JAVA 8

Java 1.0 se pojavila 1996. i (u pravo vrijeme!) reklamirana je kao jezik za Internet, čime je odmah stekla ogromnu slavu. Počeci Jave sežu u 1992., kada se zvala Oak i bila namijenjena za upravljanje uređajima za kabelsku televiziju i slične uređaje.

Sami autori su rekli da je Java = C++--, tj. da je to pojednostavljeni (u pozitivnom smislu) C++. Nije stoga čudno da Java i C++ imaju sličnu sintaksu. Eiffel sintaksa je inspirirana jezikom ADA 83. Scala je negdje između. Međutim, Java nije podskup C++ jezika. Također, iako jednostavniji nego C++, Java nije baš jednostavan jezik. Eiffel i Scala su "čisti" OOPL jezici. C++ nije, jer je morao zadržati (potpunu) kompatibilnost sa jezikom C. Java je negdje između.

Evo Što je nakon pojave Jave rekao Bertrand Meyer u [3]:

"Java is one of the most innovative developments in the software field, and there are many reasons to be excited about it. Java’s language is not the main one. As an O-O extension of C, it has missed some of the lessons learned since 1985 by the C++ community; as in the very first version of C++, there is no genericity and only single inheritance is supported. Correcting these early oversights in C++ was a long and painful process, creating years of havoc as compilers never quite supported the same language, books never quite gave accurate information, trainers never quite taught the right stuff, and programmers never quite knew what to think."

Slijedi primjer C++ programskog koda, koji je ekvivalentan programskom kodu koji je prethodno prikazan kod jezika Eiffel.

public class Zivotinja {

public String ime;

public double visina_cm;

public Zivotinja(String p_ime, double

p_visina_cm) {

ime = p_ime; visina_cm = p_visina_cm;

}

public void prikazi_podatke() {

System.out.println(" Ime: " + ime

...);

}

public double visina_inch() {...}

public static void main(String[] args) {

Zivotinja l_dz = new Zivotinja("FIFI",

20);

CASE27 31

l_dz.prikazi_podatke();

}

}

Java je već odavno mogla imati nešto kao lambda izraze, koji su uvedeni tek u Javu 8. Evo što kaže Bertrand Meyer u [4]:

"Java has no equivalent to the notion of agent as used in this book or to similar mechanisms in other languages, such as C#’s “delegates” studied in the next appendix.

... Java of course offers alternatives for such needs ... for most other cases the recommended Java solution is to use inner classes (as detailed, for the example of GUI programming, in the next section).

For a long time, the Java community denied that anything else was necessary ... which (delegates) were then being proposed for Java, but only made their way into the future C# ...

Almost a decade and a half later the designers finally relented: it has been announced that Java 7 will include an agent-like mechanism known as closures." (zapravo, kako sada znamo, to je napravljeno u Javi 8).

Na temelju onoga što čitamo i čujemo, mogli bismo zaključiti da je najvažnija nova mogućnost u Javi 8 lambda izraz (ili kraće, lambda). Inače, lambda izraz je (u Javi) naziv za metodu bez imena. U pravilu je ta metoda funkcija, a ne procedura. Zato možemo reći da je lambda izraz anonimna funkcija, koja se može javiti kao parametar (ili povratna vrijednost) druge funkcije (koja je, onda, funkcija višeg reda).

U Javi 8 pojavile su se i tzv. default metode u Java sučeljima (interfaces). One, zapravo, predstavljaju uvođenje višestrukog nasljeđivanja implementacije u Javu. Međutim, lambda izrazi i default metode su, na neki način, posljedica uvođenja treće važne mogućnosti u Javi 8, a to su Streamsi, koji nadograđuju dosadašnje Java kolekcije.

Pojava masivno višejezgrenih procesora traži bolji i lakši način izrade paralelnih programa od dosadašnjih načina. Jedan (dobar) način je da se koristi funkcijsko programiranje, a naročito paralelne kolekcije. Java nema paralelne kolekcije (collections), ali su zato uvedeni Streamsi, kako bi se postojeće kolekcije "zaogrnule" u (paralelne) Streamse i mogle (indirektno) paralelizirati. Kako bi se olakšalo korištenje Streamsa, bilo je potrebno uvesti i lambda izraze i default metode. Međutim, lambda izrazi i default metode mogu biti korisni i za ostale svrhe, ne samo tvorcima API-a, već i "običnim" programerima.

Slika 12. Razlika između obične kolekcije i Stream

kolekcije

Za razliku od dosadašnjih kolekcija, koje sadrže sve svoje elemente u memoriji, Streamse možemo shvatiti kao "vremenske kolekcije", čiji se elementi (kojih teoretski može biti i beskonačan broj) stvaraju po potrebi. "Stare" Java kolekcije koriste eksternu (eksplicitnu) iteraciju, koju piše programer. Streamsi imaju internu iteraciju. Streamsima se može poslati naš kod, kao lambda izraz, za definiranje obrade elemenata, kako pokazuje slika 12.

Java 8 Streams programiranje je deklarativno (što, a ne kako), slično kao SQL, kako pokazuje i sljedeći programski kod:

// 1. "klasična" obrada "klasične"

kolekcije - for petlja

private static void

checkBalance(List<Account> accList) {

for (Account a : accList)

if (a.balance() < a.threshold)

a.alert();

}

// 2. primjena lambda izraza za obradu

"klasične" kolekcije

private static void

checkBalance(List<Account> accList) {

accList.forEach(

(Account a) -> { if (a.balance() <

a.threshold) a.alert(); }

);

}

// 3. primjena Streamsa za paralelizaciju

"klasične" kolekcije

private static void

checkBalance(List<Account> accList) {

accList.parallelStream().forEach(

(Account a) -> { if (a.balance() <

a.threshold) a.alert(); }

);

}

Kako je već rečeno, default metode su u Javi 8 trebale prvenstveno zbog uvođenja Stream API-a, iako su default metode korisne i za ostale svrhe (ne samo tvorcima API-a). Kod uvođenja Streamsa, bilo je potrebno nadograđivati brojna postojeća Java sučelja, tj. dodavati im nove metode. Međutim, kad dodajemo nove metode u sučelje, moramo mijenjati sve klase koje ga (direktno ili indirektno) nasljeđuju, što može značiti izmjenu milijuna redaka programskog koda.

Default metode su riješile taj problem. Sučelje sada može imati i implementaciju metode, a ne samo deklaraciju, kako pokazuje sljedeći programski kod:

// 1. ako bismo postojeće sučelje

Iterable

// htjeli proširiti sa novom metodom

forEach,

// morali bismo mijenjati svaku klasu

// koja (direktno ili indirektno)

nasljeđuje to sučelje

public interface Iterable<T> {

public Iterator<T> iterator();

public void forEach(Consumer<? super

T> consumer);

}

// 2. default metode rješavaju taj

problem

32 CASE27

public interface Iterable<T> {

public r<T> iterator();

public default void

forEach(Consumer<? super T> consumer) {

for (T t : this) {

consumer.accept(t);

}

}

}

Java 8 sučelje sa default metodom nije tako moćno kao Scala trait. Scala trait može imati i ne-default metode, može imati stanje (atribute), može se komponirati za vrijeme runtimea, može pristupati instanci klase koja ga nasljeđuje. Ništa od toga Java 8 sučelje (sa default metodama) ne može.

7. ZAKLJUČAK

Višestruko nasljeđivanje klasa je dosta dugo vremena neopravdano držano kao kompleksno i nepotrebno.

Vjerojatno je jedan od glavnih razloga taj što je višestruko nasljeđivanje u jeziku C++ relativno loše riješeno.

Realizacija višestrukog nasljeđivanja u programskom jeziku Eiffel je dokazala da se višestruko nasljeđivanje može riješiti puno bolje. Nažalost, ta saznanja nisu primijenjena u Javi od početka.

U zadnjih desetak godina sve se više govori (i) o tome da bi programiranje trebalo biti multiparadigmatsko, tj. da bismo trebali koristiti onu jezičnu paradigmu koja je najprirodnija za rješavanje određenog problema. Dakle, dobro je koristiti i funkcijsko, a ne samo imperativno programiranje. Osim toga, masivno višejezgreni procesori traže bolji i lakši način izrade paralelnih programa. Jedan (dobar) način je da se koristi funkcijsko programiranje.

U Javi 8 je olakšavanje paralelnog programiranja potaknulo uvođenje Streamsa, što je "poguralo" (i) realizaciju lambda izraza i default metoda, čime je višestruko nasljeđivanje "na mala vrata" ušlo i u Java svijet. Nadamo se da će se te nove mogućnosti pokazati kao dobre, i da će se dalje razvijati.

LITERATURA

1 Joyner, I. (1999): Objects unencapsulated – Java, Eiffel and C++??, Prentice Hall

2 Langer A., Kreft K. (2013): Lambda Expressions in Java (Tutorial), Angelika Langer Training/Consulting, www.AngelikaLanger.com (travanj 2015.)

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

4 Meyer, B. (2009): Touch of Class - Learning to Program Well with Objects and Contracts, Springer

5 Odersky, M., Spoon, L., Venners, B. (2010): Programming in Scala (2.izdanje), Artima Press

6 Sierra K, Bates B. (2005): Head First Java, O’Reilly

7 Šribar, J., Motik, B. (2010): Demistificirani C++ (3.izdanje), Element

Podaci o autoru:

Zlatko Sirotić, univ.spec.inf.

ISTRA TECH d.o.o., Pula

e-mail: zlatko.sirotic@iii.hr

Autor radi više od 30 godina na informatičkim poslovima, uglavnom u poduzeću ISTRA TECH d.o.o., Pula (ISTRA TECH je novo ime poduzeća Istra informatički inženjering, osnovanog prije 25 godina). Oracle softverske alate (baza, Designer CASE, Forms 4GL, Reports, JDeveloper IDE, Java) koristi 20 godina. Objavljivao je stručne radove na kongresima / konferencijama HrOUG, CASE, KOM, "Hotelska kuća", u časopisima "Mreža", "InfoTrend" i "Ugostiteljstvo i turizam", a neka njegova programska rješenja objavljivana su na web stranicama firmi Oracle i Quest (danas dio firme Dell).

CASE27 33

XAMARIN PROCES

Miljenko Cvjetko

1. XAMARIN DANAS 2015-05

Xamarin tehnologije dobijaju sve veći i veći zamah među programerima, naročito onima koji dolaze iz .net svijeta. U poslijednjih nekoliko mjeseci došle su i potvrde iz nezavisnih izvora o performansama Xamarin aplikacija.

Potražnja za Xamarin vještinama raste iz mjeseca u mjesec i trenutaćno se nalazi na 4. mjestu po Dice portalu.

Harry Chenug - bivši google developer (jedan od prvih) napravio je jedan od prvih i dubljih benchmark testova za alate za razvoj mobilnih aplikacija.

https://medium.com/@harrycheung/cross-platform-mobile-performance-testing-d0454f5cd4e9

https://medium.com/@harrycheung/mobile-app-performance-redux-e512be94f976

Po tim analizama Xamarin tehnologije ravnopravno se bore sa “nativnim” tehnologijama (java i objective-c), a u nekima su čak i bolje.

Android

iOS

34 CASE27

2. KRONOLOGIJA XAMARIN STRATEGIJE

U razdoblju od 2010.-2013. strategija Xamarin-a je bila razvoj alata za višeplatformski razvoj aplikacija, sa naglaskom na mobilne aplikacije. U tom razdoblju radilo se prvenstveno na alatima koji povezuju (toolchain) mono-.net svijet sa nativnim Android i iOS ekosistemima.

U periodu od 2013.-2014. izdane su nove tehnologije koje su bile usmjerene na povečanju produktivnosti i smanjenju vremena izdavanja aplikacija (time to market), kao što su Xamarin.Forms. Ideja iza Xamarin.Forms-a je bila i ta da se tehnologije prisutne u .net ekosustavu dovedu i u Android i iOS svijet i time olakša .net i c# programerima ulazak u nove tehnologije.

U 2014. godini Xamarin prebacuje strategiju na kvalitetu aplikacija, a i svojih proizvoda kroz neke nove proizvode, te kroz integraciju starih proizvoda u niz alata za višeplatformski razvoj.

U tom razdoblju naglasak je na konceptima testiranja:

TDD (Test Driven Development) sa konceptima Unit Testing-a

BDD (Behaviour Driven Development) sa konceptima User Interface odn. Acceptance Testing-a

Monitoring

Analizom povratnih informacija od kupaca i korisnika došlo se je do zaključka da je kvaliteta aplikacija vrlo bitan faktor u uspjehu i monetizaciji, te su dodatne snage i resursi prebačeni na testiranje aplikacija, alata, te integraciju testnih alata u Xamarin ekosustav.

U jesen 2014. Xamarin team definira proces razvoja mobilnih višeplatformskih aplikacija.

3. XAMARIN PROCES

U Xamarin procesu definirano je 5 faza:

1. Design 2. Development 3. Integracija 4. Test 5. Monitoring

Faza dizajna omogućena je kroz Android i iOS Designer alate koji su integrirani u Xamarin Studio i Visual Studio. Ti alati omogućuju kreiranje nativnih korisničkih sučelja u alatima poznatim .net programerima, bez potrebe za dubljim poznavanjem Apple-ovog XCode-a za iOS, odn. alata Android Studio i Eclipse za Android razvoj.

Faza razvoja (development) pokrivena je već 5-6 godina kroz razvojne alate Xamarin.Android (nekada Mono for Android, odn. Monodroid), te Xamarin.iOS

(MonoTouch). Ti alati donose mogućnost nativnog razvoja u c# i f# programskim jezicima koristeći .net i pristup 100% nativnim API-u platforme koju se targetira.

Faza integracije (Integrate) donosi alate za publiciranje aplikacija, te stavljanje aplikacija u proces beta testing-a i monitoring-a.

Testiranje kao faza postala je jedan od bitnijih koraka u procesu i ovdje su se pojavili mnogobrojni alati i usluge za:

TDD alati bazirani na NUnit framework-u koji su

prilagođeni pojedinim platformama i omogućuju

testiranje Business Logic sloja aplikacije (Domain

Logic). U te alate pripadaju Xamarin.Android NUniti

Xamarin.iOS NUnit projekti.

BDD alati koji se koriste za testiranje korinisčkog

sučelja UI odn. Acceptance testing. Ovi alati su

namjenjeni pokrivanju što većeg broja use-case

slučajeva i eliminaciju manualnog testiranja koje su

mnogi korisnici Xamarin ekosustava primjenjivali, a

na njih se nadograđuju servisi u oblaku za test na

urešajima.

U ove alate spadaju:

o Xamarin.UITest kao alat (framework) za UI

Acceptance testing na bazi Calabsh tehnologije.

o Xamarin.Test.Cloud kao usluga u oblaku

Posljednja faza monitoring donosi alat Xamarin.Insights za praćenje:

problema u aplikaciji (crash and issue reporting) korisničkih navika i interakcija (session and user monitoring)

koji je napisan u potpunosti u .net-u, sa naglaskom na privatnost podataka i sigurnost, te omogućuje integraciju sa mnogim servisima (github, Visual Studio Online, HipChat, Campfire, Slack, jira ...).

4. RAZVOJ (DEVELOPMENT) I INTEGRACIJA (INTEGRATION)

U samom procesu razvoja nije dolazilo do velikih promjena, a naglasak je bio prvenstveno na podizanju kvalitete postojećih alata. Jedini novitet je Xamarin.Profiler.

4.1 Xamarin.Profiler

Xamarin.Profiler je programerski alat koji pruža podršku u procesu razvoja i implementecaije aplikacija, a namjena mu je pružanja detaljnih informacja o resursima uređaja: memoriji i procesoru, što je vrlo bitno zbog karakteristika Xamarin tehnologija.

CASE27 35

5. FAZA TESTIRANJA

Fazi testiranja pružena je najveća pažnja i ovdje su se desili najveći noviteti i tehnološki napredak.

5.1 Xamarin.UITest

Xamarin.UITest je automatizirani “UI Acceptance Testing framework” baziran na Calabasj tehnologiji i omogućava korisnicima izvršavanje NUnit testova pisanih u c# jeziku u cilju validiranja funkcionalnosti Android i iOS aplikacija.

Framework je usko povezan sa Xamarin.Android i Xamarin.iOS tehnologijama, no može biti korišten i za aplikacije pisane u objective-c za iOS i java za Android programskim jezicima.

Xamarin.UITest je biblioteka za automatizaciju interakcije sa korisničkim sučeljem za unos podataka, akcije na sučelju (events - button tap, itd.), geste (gestures - swipes itd.).

Xamarin.UITest oslanja se na Xamarin Test Cloud Agent, biblioteku koja sadrži HTTP server koji sa Calabash odn. Xamarin.UITest testovima komunicira preko JSON-a.i Sam agent ubacuje (injektira) se u testiranu aplikaciju za iOS.

Kod Android sustava agent se ne injektira u aplikaciju nego se instalira kao posebna serverska aplikacija koja na uređaju ili emulatoru komunicira sa testiranom aplikacijom.

Instalacija na Androidu nije potrebna, dok za iOS instalra se preko NuGet paketa “Xamarin Test Cloud Agent”.

Testovi se mogu izvršavati lokalno na uređaju ili emulatoru, ili pak u Xamarin.Test.Cloud-u na 1400+ uređaja (2015-05).

Calabash

Calabash framework je automatizirani UI Acceptance Testing sustav koji korisnicima omogućuje izvršavanje automatskih testova za iOS i Android. Ovaj framework uvodi koncepte Behavior Driven Development-a i vrlo je usko povezan sa Xamarin.Android i Xamarin.iOS proizvodima, no omogućava testiranje i aplikacija pisanih u objective-c i java za iOS i Android sustave.

Automatiziranost ovog framework-a omogućuje mu integraciju u CI (Continuous Integration) sustave.

Test Cloud Agent sadrži:

● Testove pisane u Gherkin-u (Feature i Step

Definitions)

skupu gramatičkih pravila za specifikaciju testova

Feature: Credit card validation.

Credit card numbers must be exactly 16

characters.

Scenario: Credit card number is too

short

Given I use the native keyboard to

enter "123456" into text field number

1

And I touch the "Validate" button

Then I see the text "Credit card

number is too short."

Scenario: Credit card number is too

long

Given I try to validate a credit

card number that is 17 characters long

Then I should see the error

message "Credit card number is too

long."

● Cucumber framework koji radi parsing i izvršavanje

testova preko poziva API-a Calabash framework-a

koji je pisan u Ruby-u

● Calabash framework koji izvršava testove

Calabash je open source projekt, no Xamarin ga je prilagodio .net svijetu i pretvorio u proizvod.

Koncepti testiranja

Testovi se izovde u pattern-u Arrange-Act-Assert klasičnim za većinu testing frameworka, počevši od unit-testinga.

1. Arrange - priprema testa i uvjeta (podaci u

korisničkom sučelju)

36 CASE27

2. Act - simulacija korisničke interakcije (button press,

swipe…)

3. Assert - provjera akcija koje su odrađene i stanja

podataka kao i korisničkog sučelja.

Na višem nivou proces se opisuje kroz slijedeće korake:

1. razvoj aplikacije (Android ili iOS)

2. pisanje testova i izvršenje testova lokalno na

emulatoru-simulatoru ili manjem broju uređaja

3. upload i izvršenje testova u Xamarin.Test.Cloud-u

na velikom broju uređaja

4. ispravljanje grešaka

5. ponavljanje lokalni i Test.Cloud testova

Priprema Testova

Aplikacije su apstrahirane kroz klase

Xamarin.UITest.iOS.iOSApp Xamarin.UITest.Android.AndroidApp

Ovi objekti su kreirani kroz ConfigureApp klasu koja instancira iOSApp i AndroidApp objekte i inicijalizira ih kroz NUnit metode dekorirane slijedećim atributima:

● SetUp

priprema logičke grupe testova (recimo na jednom

ekranu)

Preporuka - odvojeni IApp objekti

● TestFixtureSetup

priprema sitnijih detalja za pojedine testove

● Test

izvršenje testa

app.Tap(c=>c.Button("ValidateButton"))

;

inicijalizacija:

string path_apk1 =

"/Users/nb/sample.iOS/bin/Debug/Sample.Dr

oid.apk";

ConfigureApp

.Android

.ApkFile(path_apk1)

.Debug()

.WaitTimes(new

HolisticWare.XamarinUITest.WaitTimes())

//.ApiKey(api_key)

.StartApp();

string path_app1 =

"/Users/nb/sample.iOS/bin/iPhoneSimulator

/Debug/SampleXamarinFormsiOS.app";

ConfigureApp

.iOS

.AppBundle(path_app1)

//.ApiKey("")

.StartApp();

Sam Xamarin.UITest framework ne kompajlira i pakira aplikacije, stoga to se mora prethodno napraviti.

IApp objekt korisiti AppQuery za lociranje UI elemenata (Views).

app.Tap(c=>c.Text("Save"));

app.Tap(c=>c.Marked("SaveUserDataButton")

);

app.Tap(c=>c.Marked("Pending").Parent().C

lass("AppointmentListCell").Index(0));

AppResult[] results =

app.Query(c=>c.All())

app.Query(c=>c.Class("UILabel"));

app.Query(c=>c.Id("txtUserName"));

app.Query(c=>c.Class("UILabel").Text("Hel

lo, World"));

results =

app.Query(c=>c.Marked("ValidateButton"));

IApp metoda Repl otvoriti će REPL podsustav (Read, Evaluate, Print, Loop) za interakciju sa aplikacijom - nešto slično kao primitivan shell za operativne sustave.

app.Repl();

Primjer izdavanja komandi (tree):

CASE27 37

App has been initialized to the 'app'

variable.

Exit REPL with ctrl-c or see help for

more commands.

>>> tree

[UIWindow > UILayoutContainerView]

[UINavigationTransitionView > ... >

UIView]

[UITextView] id:

"CreditCardTextField"

[_UITextContainerView]

[UIButton] id: "ValidateButton"

[UIButtonLabel] text: "Validate

Credit Card"

[UILabel] id:

"ErrorrMessagesTestField"

[UINavigationBar] id: "Credit Card

Validation"

[_UINavigationBarBackground]

[_UIBackdropView >

_UIBackdropEffectView]

[UIImageView]

[UINavigationItemView]

[UILabel] text: "Credit Card

Validation"

>>>

5.2 Xamarin.Test.Cloud

Xamarin.Test.Cloud je komercijalna usluga za testiranje mobilnih aplikacija na preko 1000 uređaja (2015-04 broj je oko 1400 većinom Android uređaja).

http://xamarin.com/test-cloud

https://www.youtube.com/watch?v=PQMBCoVIABI&feature=youtu.be&t=57m30s

Xamarin.Test.Cloud Continuous Integration

Zbog svoje automatske prirode Xamarin.Test.Cloud se vrlo lako integrira u procese Continous Integration.

Xamarn.Test.Cloud se po svojim karakteristikama razlikuje od ostalih rješenja, prvenstveno paralelnog testiranja aplikacija, na velikom broju uređaja, što je prednost, jer se rezultati testiranja dobijaju daleko brže.

38 CASE27

Screenshots

Error reporting

Device DrillDown

CASE27 39

6. MONITORING - XAMARIN.INSIGHTS

Xamarin.Insights je alat koji omogućava monitoring aplikacije, te mnogobrojna izvješća o stanju aplikacije (greškama, performansama - memorija i procesor).

Proizvod prati i korisnike, njihove demografske podatke (geolokaciju i sl), njihovu interakciju sa aplikacijom do vrlo sitnih detalja ili kumulativno.

Uz korisnike dostupna su i izvješća po geografskim lokacijama.

7. ZAKLJUČAK

Xamarn je kroy novi proces donio nove alate za korisnike Xamarin tehnologije, no i za ostale koji razvijaju nativne i hibridne mobilne aplikacije.

Sam proces je samo prijedlog za “best practice” prema dosadašnjim iskustvima u razvoju aplikacija, koji se temelji na “feedback-u” samih korisnika alata i aplikacija.

40 CASE27

Podaci o autoru:

Miljenko Cvjetko

mcvjetko@holisticware.net

miljenko.cvjetko@xamarin.com

http://holisticware.net

http://xamarin.com

HolisticWare je startup firma koja se bavi razvojem mobilnih aplikacija sa .net tehnologijom. U 2011. godini dali smo naglasak na razvoj sa Mono-om (open source portom) .net tehnologije na ne-Windows platforme, pa tako i iOS i Android.

CASE27 41

AUTOMATIZACIJA DOMA KORIŠTENJEM RASPBERRY PI-A

HOME AUTOMATION USING RASPBERRY PI

Dragutin Kermek, Matija Novak

SAŽETAK:

Automatizacija doma jedan je od dijelova Internet Stvari (eng. Internet Of Things). Pojavom malih uređaja poput Raspberry Pi-a "Sam Svoj Majstor" automatizacija doma sve je popularnija. Korištenjem Raspberry Pi uređaja, prototipne pločice i nekoliko senzora (npr. senzor temperature, vlage, vlažnosti zemlje, senzor pokreta) moguće je na različite načine automatizirati dom. U ovom radu iskorištena je, uz same senzore, infracrvena kamera za snimanje po noći i napravljen kućni video nadzor. Iako sam uređaj i senzori nisu skupi kako bi još više uštedjeli primijenili smo tako zvani „zeleni pristup“. U svakom domu nalaze se uređaji poput televizora, radio prijemnika i sl. čiji se popravak ne isplati. No sami uređaji sadrže dijelove koje je moguće na inovativan način iskoristiti u automatizaciji doma. U ovom radu iskorišten je infracrveni senzor i tv daljinski upravljač kako bi se olakšalo upravljanje automatiziranim kućnim nadzorom. Kao programski jezik za osnovno testiranje i podešavanje rada senzora korišten je Python, dok je konačno rješenje razvijeno u Javi.

ABSTRACT:

Home automation is one part of Internet of Things. With the appearance of small devices such as raspberry Pi "Do It Yourself" home automation is becoming increasingly popular. Using the Raspberry Pi device, breadcrumb board and several sensors (e.g. Temperature sensor, moisture, humidity Earth, motion sensor) home automation can be done in different ways. In this paper, an infrared night vision camera is used with the sensors and home video surveillance was made. Although the device itself and the sensors are not expensive to further save some money so called "green approach" was used. In every home there are devices such as TVs, radios and so on whose repair is not profitable. But, the devices contain parts that can be sued in an innovative way when doing home automation. In this paper the infrared sensor and TV remote controller were used to facilitate the management of automated home surveillance. As for programing languages Python was used for basic testing and sensor configuration, and the final solution was developed in Java.

1. UVOD

Automatizacija doma obično je značila uključivanje profesionalca i nabava skupocjene opreme. Naravno takva automatizacija je još uvijek prisutna u slučajevima većih i složenijih oblika automatizacije doma. Danas postoje i druge mogućnosti, u kojima pojedinci mogu automatizirati svoj dom primjenom vlastitih vještina i rješenja. Pojavom malih uređaja poput Raspberry Pi-a (dalje u tekstu samo Raspberry), Banana Pi, Arduino i sl. „Sam svoj majstor“ automatizacija sve je popularnija. Raspberry i slični uređaji ne samo da su potaknuli samostalnu automatizaciju doma već su omogućili vrlo jeftinu automatizaciju. Za samo 30 dolara moguće je nabavit Raspberry uređaj i krenuti s vlastitim razvojem. Razni senzori, elektronički elementi i komponente mogu se nabaviti preko online trgovina (npr. eBay, Amazon, i sl.) od jedan do dva dolara pa do nekoliko desetaka dolara. Također online zajednica korisnika Raspberry uređaja prezentira na Web-u i u obliku knjiga vlastita rješenja uz detaljne upute i sheme za izgradnju vlastitih elektroničkih sklopova vrlo velike širine primjene. Naravno, uz njih su priloženi i programski kodovi potrebni za upravljanje tim sklopovima. Vlastita imaginacija i sposobnost kombiniranja postojećih rješenja otvaraju neograničene mogućnosti. Ukoliko se želi ići u smjeru uštede novca moguće je primijeniti takozvani „zeleni pristup“. „Zeleni pristup“ govori nam da iskoristimo postojeće uređaje, komponente i dijelove koji se nalaze u našem domu. U svakom domu nalaze se

uređaji poput televizora, radio prijemnika i sl. čiji se popravak ne isplati. No sami uređaji sadrže komponente i dijelove koje je moguće na inovativan način iskoristiti u automatizaciji doma.

U ovom radu prezentiran je primjer izrade vlastitog noćnog kućnog video nadzora. Također prezentirane su tehnologije i problemi koji su nastali u toku rada. Kao programski jezik za osnovno testiranje i podešavanje rada senzora korišten je Python, dok je konačno rješenje razvijeno u Javi. Ostatak rada strukturiran je na sljedeći način. Poglavlje 2 govori općenito o automatizaciji doma i samom Raspberry Pi uređaju. Poglavlje 3. opisuje prve korake u radu sa Raspberry Pi-om i GPIO sučeljem Poglavlje 4. daje složeni primjer kućnog video nadzora korištenjem zelenog pristupa. U Poglavlju 6. dan je zaključak.

2. AUTOMATIZACIJA DOMA I RASPBERRY PI

Internet Stvari (eng. Internet of Things) [1] govore da se svi uređaju međusobno povezuju preko interneta od naravno računala, tableta, mobitela i sl. pa sve do mikrovalne, kuhala, frižidera i sl. U tom kontekstu korištenje različitih senzora na uređajima daje posebnu dimenziju integraciji i interoperabilnosti. Automatizacija doma jedan je od dijelova Internet Stvari. Kako bi kontrolirati dom možemo uzeti stolno računalo, no ono je prilično veliki potrošač električne energije stoga je

42 CASE27

puno pogodniji manji uređaji koji maje troše. Jedan primjer dosadašnje prakse smanjivanja potrošnje električne energije u vlastitom domu ide u smjeru zamjene stolnog računala s medijskim centrom, NAS-om (eng. Network-attached storage) i sl. Time se omogućava 24/7 pristup do multimedijskih sadržaja i datoteka uz malu potrošnju električne energije. Stoga nije čudno da kao centralnu jedinicu za automatizaciju doma odabran Raspberry kao malen potrošač. Ideja da se iskoristi Raspberry Pi za automatizaciju doma nije nova. U članku “Raspberry Pi based interactive home automation system through E-mail” [2] autor daje primjer korištenja Raspberry-a u svrhu automatizacije doma.

U članku „A comparison of the popular home automation technologies“ [3] autori su usporedili razne tehnologije za automatizaciju doma. No te tehnologije su previše napredne i složene za početnika. Pod početnikom smatramo nekoga tko ima barem malo znanja o programiranju, radu sa elektroničkim sklopovima i računalima, ali dosad nije radio sa malim uređajima poput Raspberry-a. Stoga u ovom radu prikazane su tehnologije koje su dostupne početnicima i koje se mogu lako shvatiti. Prije nego se opišu same tehnologije opisat će se odabrani uređaj.

Raspberry Pi je računalo na jednoj ploči veličine kreditne kartice, čiji je vanjski spremnik SD kartica (standardna ili Micro), koje se može nabaviti za 30 dolara. Malen je potrošač (približno 1.5W, a ovisi o priključenim komponentama poput kamere, senzora i sl. [4]) no ima velike mogućnosti. Slika 1 prikazuje sam uređaj Model B+ koji je korišten u ovom radu, više o raznim modelima, ali i puno drugih mogućnosti moguće je pronaći na službenoj stranici [5]. Model B+ ima: 4 USB priključka, LAN priključak, 40 GPIO pinova, HDMI priključak, kombinirani 3.5mm audio i kompozitni video, sučelje za kameru i sučelje za display, utor za Micro SD karticu, 512 MB RAM-a i 1GHz procesor. Zadnja verzija je Raspberry Pi 2 Model B koji ima brži procesor i više RAM-a. Jako koristan priključak je GPIO (eng. General pourpose input output interaface) koji omogućuje komunikaciju sa bilo kakvim vanjskim modulima, senzorima i njihovo kontroliranje.

Sam uređaj je otvoren za razne operacijske sustave (OS) no na službenim stranicama pripremljene su razne Linux verzije. Dobra stvar kod samog Raspberry-a jest

da ima široku zajednicu i gotovo sav programski kod je je otvoren (eng. open source). Raspberry također podržava razne programske jezike kao što su Python i Java. U nastavku opisat će se osnovni koraci i počeci u radu s Raspberry koristeći Python i Java programske jezike.

Slika 1 Raspberry Pi

3. PRVI KORACI

Kako bi se započelo korištenje Raspberry-a potrebno je najprije instalirati OS i spojiti se na njega na neki način. Upute kako napraviti instalaciju te kako se spojiti mogu se pronaći u dokumentaciji

* na službenim stranicama.

Najjednostavnija varijanta je korištenjem instalacijskog managera NOOBS

† (eng. new out of the box software).

Za spajanje u ovom radu koristio se SSH pristup za rad na uređaju i FTP za prebacivanje datoteka na sam uređaj. Napredniji način je korištenje integrirane razvojne okoline (npr. NetBeans) i njenih mogućnosti udaljenog upravljana Raspberry-em. Također korištena je USB wireless adapter kako bi se uređaj mogao lakše koristiti bez fizičkog povezivanja na lokalnu mrežu. Sam Raspberry ima i grafičko sučelje ukoliko se HDMI priključkom spoji na monitor može se doći do grafičkog sučelja i raditi preko njega.

3.1 GPIO

Nakon uspješne instalacije i spajanja može se krenuti s radom. Kako je ideja ovog rada da se napravi kućno video nadzor korištenjem „zelenog pristupa“ potrebno se upoznati sa GPIO sučeljem. Na slici 2 prikazan je raspored pinova preuzet sa službene stranice, no moguće je pronaći na internetu razne sheme koje

* https://www.raspberrypi.org/documentation/ † https://www.raspberrypi.org/documentation/installation/noobs.md

Slika 2 Raspored pinova GPIO sučelja za Raspberry Pi Model B+*

CASE27 43

možda na prikladniji način (bojama) prikazuju raspored pinova.

Kako bi se koristili pinovi oni su preko paralelnog kabla i proširenja GPIO ploče spojeni na samu prototipnu pločicu. Na slici 3 prikazan je jednostavan primjer prototipne pločice koja je napravljena prema [6]. U tom primjeru koristi se jedna dioda, dva otpornika, jedno tipkalo i četiri preskočna kabla. Ideja je da se na pritisak tipke dioda pali i gasi. Sam primjer napravljen je u Javi. No prije nego se krene sa javom dobro je krenuti sa jednostavnijim primjerima i Python.

Slika 3 Primjer korištenja prototipne pločice i GPIO sučelja

3.2 Python

Iako je krajnji projekt napravljen u Javi sva testiranja prvo su rađena u Pythonu. Python je odabran za testiranja jer je on preinstaliran programski jezik na Raspberry-u i jednostavno se instaliraju dodatni moduli potrebni za rad. Također direktno se može raditi sa GPIO sučeljem bez nekakvih posebnih sigurnosnih mehanizama. Osim toga može se direktno na samom uređaju korištenjem omiljenog editora direktno pisati python programi. Za instalaciju potrebno je pokrenuti sljedeću komadnu:

sudo apt-get install python-dev python3-

dev

python-rpi.gpio python3-rpi.gpio

Nakon toga može se započeti s radom. Programski kod za recimo upravljanje pinom broj 4 izgleda ovako:

import RPi.GPIO as GPIO

GPIO.setwarnings(False)

GPIO.setmode(GPIO.BCM)

GPIO.setup(4,GPIO.OUT)

GPIO.output(4,False)

Iz prve linije primjera može se vidjeti da je potrebno učitati GPIO biblioteku. Javljanje grešaka može se uključiti ili isključiti no nije obavezno. Zatim je postavljen način rada na koji će se pozivati pinovi. Način rada GPIO.BOARD omogućuje da se pinovi referenciraju prema fizičkom redoslijedu kako se pojavljuju na samoj pločici, a GPIO.BCM znači da se pinovi referenciraju prema logičkom nazivlju. Tako je GPIO4 logički naziv za fizički pin 7. Detaljnije se mogu vidjeti veze na slici 2. Nakon toga postavlja se dali pin radi kao ulazni ili izlazni pin i na kraju se postavlja vrijednost na true/false. Postavljanje ove zadnje vrijednosti znači dali ima ili nema napona na samom pinu. I to je u principu sve što je potrebno da bi se kontrolirala većina pinova. Daljnji rad ovisi o idejama programera i što želi napraviti.

Samo pokretanje programa potrebno je napraviti kao root korisnik jer samo on ima pravo pisanja po datotekama vezane uz GPIO sučelje. Tako

pokretanje programa “pin4stop.py“ pokrećemo ovako:

sudo python pin4stop.py

3.3 Java SE Embedded & Java ME Embedded

Programski jezik Java korišten je za krajnji projekt u ovom radu. Instalacija Jave nešto je složenija od Pythona, također sam rad je nešto složeniji. Iako je moguće direktno pisati Java program na uređaju ipak je lakše pisati Java program na računalu u razvojnoj okolini i zatim prebaciti na Raspberry. Mogu se koristiti dvije verzije Jave na Raspberry-u. Java ima svoju pripremljenu verziju za male uređaje Java ME Embedded

‡ (kasnije u tekstu samo Java ME). No da bi

se programiralo u Java ME potrebno je instalirati Java ME SDK

§ na računalo. Za instalaciju Java ME potrebno

je samo prebaciti na uređaj i pokrenuti komandu:

sudo unzip oracle-jmee-8-1-rr-

raspberrypi-linux-bin.zip

-d /usr/lib/jvm/javame8

Nakon što se instalira SDK i može se krenuti programiranjem. Kao razvojno okruženje korišten je NetBeans 8.0.2. Za kreiranje projekta jednostavno se ide na kreiranje novog Java ME projekta (Java ME SDK mora biti instaliran). Primjer jednostavnog Java ME programa sastoji se od dvije klase. Prva klasa proširuje klasu MIDLet i izgleda na primjer ovako:

public class LedBlik extends MIDlet {

private LedBlinkTest pinTest;

@Override

protected void startApp() throws

MIDletStateChangeException {

System.out.println("Pokretanje

programa");

pinTest = new LedBlinkTest();

try { pinTest.start(); } catch

(IOException ex)

{ … notifyDestroyed(); }

}

@Override

protected void destroyApp(boolean

unconditional)

throws MIDletStateChangeException {

if (pinTest != null) {

try { pinTest.close(); } catch

(Exception ex) {…}

} } }

Druga klasa implementira sučelje PinListener i AutoClosable koja služi za upravljanje događajima na nekom pinu i izgleda ovako:

public class LedBlinkTest implements

PinListener, AutoCloseable {

public void start() throws

IOException {

GPIOPinConfig pinConfig = new

GPIOPinConfig(DeviceConfig.DEFAULT,

18,GPIOPinConfig.DIR_OUTPUT_ONLY,

GPIOPinConfig.MODE_OUTPUT_PUSH_PULL,

GPIOPinConfig.TRIGGER_NONE, false);

GPIOPin pin = null;

‡ http://www.oracle.com/technetwork/java/embedded/javame/embed-

me/downloads/java-embedded-java-me-download-2162242.html § http://www.oracle.com/technetwork/java/embedded/javame/javame-sdk/downloads/index.html

44 CASE27

pin = (GPIOPin)

DeviceManager.open( pinConfig);

System.out.println("Blinking

LED");

for (int x = 0; x < 10; x++) {

pin.setValue(x % 2 == 0);

try {

Thread.sleep(1000);

} catch (InterruptedException

ex) {…}

}

pin.close();

}

@Override

public void valueChanged(PinEvent

event) { … }

@Override

public void close() throws Exception

{…}

}

S druge strane Java ima Java SE Embedded verziju koju je moguće koristiti. Prednosti ove verzije jest da ima više mogućnosti na primjer klasa Runtime nije podržana u Java ME. No nedostatak je da je složeniji način rada. Dok Java ME u pravilu ne zahtjeva posebnu konfiguraciju sigurnosne politike da bi se radilo sa GPIO sučeljem, Java SE to treba. Također Java ME ima direktno virtualno okruženje koje je moguće koristiti za testiranje programa prije prebacivanja na uređaj, dok Java SE to nema. Prema iskustvu savjet je da se koristi Java ME, a da se prebaci na Java SE tek kada su potrebne neke klase koje Java ME ne podržava. Također Java ME se preporučuje za početnike u radu sa malim uređajima.

Instalacija Java SE verzije vrši se sljedećom komandom:

sudo tar zxvf jdk-8u6-linux-arm-vfp-

hflt.tar.gz -C /usr/lib/jvm

Kako bi Java SE mogla koristiti GPIO sučelje potrebno je koristiti DIO (eng. device input output) biblioteku. Da bi se skinuo dio.jar potrebno izvršiti sljedeću komandu:

hg clone http://hg.openjdk.java.net/dio/dev

i preuzeti dio.jar iz /dev/build/jar direktorija. Nakon toga može se kreirati klasična Java aplikacija u koju se uključi dio.jar biblioteka. No da bi Java SE mogla pristupiti GPIO sučelju potrebno je još podesiti sigurnosnu politiku. Sigurnosna politika definira se u novoj datoteci na primjer „gpio.policy“ sa sadržajem:

grant {

permission

jdk.dio.gpio.GPIOPinPermission "*:*";

permission jdk.dio.DeviceMgmtPermission

"*:*","open";

};

Nakon toga može se kreirati program u koji se importiraju sljedeće klase:

import jdk.dio.gpio.GPIOPin;

import jdk.dio.gpio.GPIOPinConfig;

Nakon toga može se kreirati instanca GPIOPinConfig klase koja služi za definiranje pina koji se koristi.

GPIOPinConfig pinConfig = new

GPIOPinConfig(

DeviceConfig.DEFAULT,18,

GPIOPinConfig.DIR_OUTPUT_ONLY,

GPIOPinConfig.MODE_OUTPUT_PUSH_PULL,

GPIOPinConfig.TRIGGER_NONE, false);

Nakon toga inicijalizira objekt GPIOPin klase preko kojeg se radi sva komunikacija. Klasa DeviceManager služi da bi se otvorio željeni pin. Sa komandama setValue može se postaviti vrijednost pina na true/false koji kao i u python programu znači dali ima ili nema napona na pinu. Na kraju obavezno treba zatvoriti pin. Taj dio koda prikazan je ovdje:

GPIOPin pin = null;

pin = (GPIOPin)

DeviceManager.open(GPIOPin.class,

pinConfig);

//GPIOPin pin = (GPIOPin)

DeviceManager.open(18);

System.out.println("Blinking LED");

pin.setValue(true);

Thread.sleep(500);

pin.setValue(false);

pin.close();

Ukoliko se ne zatvori pin on ostaje otvoren i onda prilikom sljedećeg pokretanja se dobiva error, te je potrebno pin ručno zatvoriti. U nastavku rada koristi se isključivo Java SE Embedded. Za pokretanje Java SE Embedded potrebno je uključiti sljedeće opcije virtualnog stroja:

-

Djdk.dio.registry=/home/pi/dev/config/dio

.properties-raspberrypi

-

Djava.security.policy=/home/pi/JavaProjec

ts/Pi/gpio.policy

-Djava.library.path=/home/pi/dev/build/so

Prva opcija služi da se uključi konfiguracija potrebna za rad sa GPIO sučeljem, koja se dobiva kloniranjem DIO projekta. Druga opcija uključuje sigurnosnu politiku koja se definirala za projekt. Treća daje putanju do kompiliranog c koda koji omogućuje komunikaciju sa GPIO sučeljem na najnižoj razini. Kao i kod Python programa i Java program mora se pokretati kao root korisnik. U sljedećem poglavlju opisat će se kako je izgrađen kućni video nadzor primjenom „zelenog pristupa“.

4. KUĆNI (NOĆNI) VIDEO NADZOR

Kao pokazni primjer odlučeno je da će se napraviti kućni video nadzor koristeći NoIR (eng. no infra red) kameru. NoIR kamera omogućuje snimanje po noći, a Raspberry ima predviđen poseban priključak za spajanje kamere. Na slici 4 prikazana je kamera. Da bi se olakšalo upravljanje kamerom ideja je da se primjeni infracrveni daljinski upravljač. No kako bi se uštedjelo uzet je daljinski upravljač sa starog Sony televizora čiji popravak više nije bio isplativ.

Slika 4 NoIR kamera za noćno snimanje

CASE27 45

4.1 Zeleni pristup

Danas postoji brdo elektroničkog otpada. Svatko ima u svome domu nekakvi uređaj koji se pokvario i čiji popravak nije isplativ. Umjesto da se takav uređaj baci on se može jako dobro iskoristiti za kućnu automatizaciju. Dijelovi unutar uređaja: kondenzatori, otpornici, transformatori i sl. su i dalje funkcionalni, barem većina njih. Tako su ovom primjeru izvađeni dijelovi iz starog Sony televizora (prikazani na slici 5), a senzor za infracrveno upravljanje je iskorišten kako bi se upravljalo Raspberry uređajem i kamerom.

H1 ploča na vrhu slike 5 sadrži spomenuti senzor. Taj senzor prikazan je uvećano na slici 6. A na slici 7 prikazano je finalno rješenje spojeno na Raspberry. Sa slike 7 vidljivo je da je H1 ploča uzeta sa televizora spojena na prototipnu pločicu i preko nje spojena na Raspberry uređaj. Klikom na tipku na daljinskom upravljaču aktivira se senzor koji šalje signal na pin na Raspberry uređaju. Zatim se taj signal obrađuje i hvata u aplikaciji koja onda pali/gasi kameru. U sljedećem poglavlju opisano je detaljnije kako je riješen dio za rad sa daljinskim upravljačem.

Slika 5 Izvađeni dijelovi pokvarenog Sony televizora

Slika 6 Infracrveni senzor za daljinsko upravljanje televizorom

Slika 7 Kompletno rješenje upravljana Raspberry Pi-om

korištenjem „zelenog pristupa“

4.2 Infracrveni daljinski upravljač

Da bi se mogao koristiti infracrveni daljinski upravljač korišten je LIRC projekt [7]. LIRC se može preuzeti izvršavanjem sljedeće komande:

sudo apt-get install lirc

nakon toga potrebno je programirati tipke na daljinskom upravljaču pokretanjem sljedećih komandi i praćenjem uputa koje se jave na ekranu:

sudo kill $(pidof lircd)

irrecord -d /dev/lirc0 ~/lircd2.conf

sudo mv lircd2.conf /etc/lirc/lircd.conf

sudo /etc/init.d/lirc restart

Nakon što je upravljač konfiguriran može se krenuti s programiranjem. Za rad korištena je Java LIRC biblioteka

**. Da bi se ona mogla koristiti potrebno je

kreirati datoteku npr. „command.lirc“ koja opisuje što se dešava kad se pritisne koja tipka:

begin

button = KEY_MUTE

config = mute

repeat = 1

End

U danom primjeru kada se pritisne tipaka “Mute” daljanski upravljač šalje signal „KEY_MUTE“ kojeg hvata IR senzor, a Java LIRC biblioteka na temelju opisa u datoteci šalje u aplikaciju opis „mute“. Opcija „repeat“ služi da se osigura da se u aplikaciju pošalje samo jedan signal da je tipka pritisnuta. Kada se pritisne tipka signal se generira više puta. Da bi se uhvatio signal u Java aplikaciji kositi se sljedeći kod koji koristi SimpleLIRCClient klasu:

private static SimpleLIRCClient client;

client = new

SimpleLIRCClient("/home/pi/JavaPro

jects/Pi/command.lirc");

client.addIRActionListener(new

ButtonListener());

Klijent treba novu klasu koja služi kao slušač pritiska tipke ButtonListener i ona izgleda ovako:

private static class ButtonListener

implements IRActionListener {

…

public void action(String command) {

System.out.println(command); //npr. mute

Date now = new Date();

long interval = now.getTime()-

last_time.getTime();

last_time=now;

System.out.println(interval);

if(interval<(long)3000)

{ return; }

… GPIO dio kako bi zasvijetlila LED

dioda kad se pritisne tipka …

if(command.equalsIgnoreCase(„mute"))

{ … }

}}

Obrada koja se vrši nakon pritiska tipke može biti bilo koja funkcionalnost. U ovom slučaju ubačen je kod za paljenje i gašenje LED diode kako bi se pokazalo da je

** http://jlirc.sourceforge.net/

46 CASE27

tipka pritisnuta. Za taj dio koristi se kod koji se prikazan u prošlom poglavlju. U prethodnom kodu ima mala specifičnost sa datumom koja osigurava da se tipka može pritisnuti svake tri sekunde. To je potrebno jer startanje kamere traje jednu do dvije sekunde pa kako ne bi došlo do preklapanja i pada sustava. U idućem poglavlju prikazat će se dio kako je pokrenuta sama kamera.

4.3 Upravljanje kamerom

Za samo pokretanje i zaustavljanje kamere koriste se klasične Linux komande. Za startanje koristi se sljedeće komande preuzete sa bloga [8]:

raspivid -o - -t 9999999 -w 800 -h 600 --

hflip --vflip |

cvlc –www stream:///dev/stdin --sout

'#standard{access=http,mux=ts,dst=:808

0}' :demux=h264

raspivid -o - -t 9999999 -w 800 -h 600 --

hflip --vflip |

tee test_video.h264 | cvlc -vvv

stream:///dev/stdin --sout

'#standard{access=http,mux=ts,dst=:808

0}' :demux=h264

Prva komanda samo starta tok podataka na Internet i pokreće snimanje, dok druga komanda radi i spremanje u datoteku. Pristup do snimke moguć je preko URL adrese koja pokreće HTML dokument u kojem su potrebni parametri za gledanje snimke u realnom vremenu. Za samo pokretanje korišten je sljedeći Java kod:

private void executeCommand(String cmd) {

Runtime r = Runtime.getRuntime();

Process p = null;

p = r.exec(cmd);

InputStream stdout =

p.getErrorStream();

/* Scanner scanner = new

Scanner(stdout);

while (scanner.hasNextLine()) {

System.out.println(scanner.nextLine()+

"\n");

}*/

}

Ovaj kod ne služi da bi se izvršila neka Linux komanda. Dio sa ispisom greški je komentiran jer u toku rada konstanto se generiraju neke greške koje u stvarnosti nisu greške već samo posljedica programa koji se koristi za snimanje. Kako se aplikacija ne bi zaustavila na tom dijelu ovaj dio se koristiti samo za test, a u produkciji je isključen.

U toku rada kamere dvije infracrvene (IR) diode koje su montirane na kameru se konstantno zagrijavaju kako bi se to ispravilo ideja je da se stave hladnjaci. No po danu ionako ne trebaju IR diode zbog toga je odlučeno da će se uz pomoć senzora svijetlosti kontrolirati te IR diode. IR diode su zato odvojene od kamere i spojene preko GPIO sučelja. U sljedećem poglavlju će se opisati taj dio.

4.4 Uključivanje senzora

Senzori koji su korištenje za upravljanje IR diodama, spojene preko releja, su senzor temperature i senzor svijetlosti. Sustav je prikazan na slici 8. Senzor svijetlosti reagira dali ima ili nema svijetla. Ukoliko nema

svijetla pale se IR diode i uključuje zelena dioda kao indikator rada IR dioda. Ukoliko ima svijetla IR diode se gase kao i zelena dioda. Uključena crvena dioda pokazuje da je temperatura previše porasla i opet se IR diode gase. IR diode su spojene preko releja na prototipnu pločicu čime se omogućava da se njima upravlja preko GPIO sučelja i da se koristi vanjsko napajanje električnom energijom bez Raspberry uređaja. Na taj način rasterećuje se Raspberry uređaj. Senzor temperature ima potenciometar kojim se može regulirati na kojoj temperaturi se IR diode gase.

Slika 8 Kontroliranje infracrvenih senzora preko GPIO sučelja i senzora svijetlosti i temperature

5. ZAKLJUČAK

U ovom radu prikazan je primjer i tehnologije za izradu vlastite automatizacije doma korištenjem Raspberry Pi uređaja. Time prikazuje da automatizacija doma ne mora nužno značiti veliku investiciju. Primjenom „zelenog pristupa“ sam iznos automatizacije može se još više umanjiti.

U prikazanom primjeru napravljen je noćni kućni video nadzor koji se može upravljati putem infracrvenog daljinskog upravljača preuzetog sa starog Sony televizora i pratiti putem Web preglednika. Same diode za infracrveno svijetlo kontrolirane su preko senzora svijetlosti i time se štedi na potrošnji električne energije kada ima dovoljno vanjskog svijetla i ujedno se produljuje vijek IR dioda. Moguće proširenje prikazanog sustava jest da se omogući upravljanje video nadzorom preko Web-a.

Automatizacija doma jest jedan dio Internet stvari i time pridonosi povezivanju svih uređaja preko interneta. Realizacija većih projekata automatizacije doma (npr. upravljanje garažnim vratima, klima uređajem, zvučnom sirenom, uređajima za navodnjavanje itd.) zahtjeva uključivanje složenijih sklopova (npr. modul sa većim brojem releja, motora, i sl.), senzora (npr. senzora kontakta, detekcije dima, detekcije pokreta, i sl.) i korištenje izmjenične električne struje. Zbog toga realizacija takvih projekata traži dodatna znanja i vještine kako bi se izbjegle ozbiljne nezgode.

Primjenom u projektima različite složenosti automatizacije doma uređaji poput Raspberry-a sve više dobivaju na značaju. Što dalje znači da programiranje za male platforme postaje sve više značajno. Programski jezici poput Jave već su to prepoznali i imaju svoju ediciju za male uređaje poput Java ME.

CASE27 47

Literatura

1 J. Gubbi, R. Buyya, S. Marusic, and M. Palaniswami, “Internet of Things (IoT): A vision, architectural elements, and future directions,” Futur. Gener. Comput. Syst., vol. 29, no. 7, pp. 1645–1660, Sep. 2013.

2 S. Jain, A. Vaibhav, and L. Goyal, “Raspberry Pi based interactive home automation system through E-mail,” in Optimization, Reliabilty, and Information Technology (ICROIT), 2014 International Conference on, 2014, pp. 277–280.

3 C. Withanage, R. Ashok, C. Yuen, and K. Otto, “A comparison of the popular home automation technologies,” in Innovative Smart Grid Technologies - Asia (ISGT Asia), 2014 IEEE, 2014, pp. 600–605.

4 “How Much Less Power does the Raspberry Pi B+ use than the old model B?,” 2014. [Online]. Available: http://raspi.tv/2014/how-much-less-power-does-the-raspberry-pi-b-use-than-the-old-model-b. [Accessed: 21-May-2015].

5 Raspberry Pi Foundation, “Raspberry Pi,” 2014. [Online]. Available: https://www.raspberrypi.org/. [Accessed: 17-Apr-2015].

6 T. McGinn and E. A. M. Cruz, “Working with GPIO by Using Java ME Embedded and a Raspberry Pi,” 2014. [Online]. Available: http://www.oracle.com/webfolder/technetwork/tutorials/obe/java/RaspberryPi_GPIO/RaspberryPi_GPIO.html. [Accessed: 17-May-2015].

7 A. Leamas, Christoph Bartelmus, Heinrich Langos, Karsten Scheibler, Jim Paris, and Milan Pikula, “LIRC - Linux Infrared Remote Control,” 2015. [Online]. Available: http://www.lirc.org/. [Accessed: 11-Mar-2015].

8 M. Horne, “Stream the #RaspberryPi camera module through your browser,” 2013. [Online]. Available: http://www.recantha.co.uk/blog/?p=4165. [Accessed: 17-May-2015].

Podaci o autorima:

dr.sc. Dragutin Kermek

Redoviti profesor

Fakultet Organizacije i Informatike, Pavlinska 2, 42000 Varaždin.

E-Mail: dragutin.kermek@foi.hr

Iskustvo i važniji projekti.: Dragutin Kermek doktorirao je 1999. godine u društvenom području, grana informacijske znanosti, na Fakultetu organizacije i informatike Sveučilišta u Zagrebu. Trenutno radi kao redoviti profesor na istom fakultetu. Nositelj je kolegija: Web dizajn i programiranje, Napredne Web tehnologije i servisi, Sustavi za elektroničko učenje, Uzorci dizajna. Objavio je više od 60 znanstvenih i stručnih članaka u različitim međunarodnim i domaćim časopisima, knjigama i konferencijama. Sudjelovao je na više znanstvenih projekata. Bio je voditelj više stručnih projekata dizajna, programiranja i uvođenja sustava za upravljanje sadržajem (CMS), za e-učenje (LMS), informacijskih sustava za evidenciju, planiranje i praćenje nastavnih programa (NPP) i sl. Član je predsjedništva vijeća korisnika CARNet-a od 2005. godine u 4 uzastopna mandata. Član je uređivačkog odbora časopisa Journal of Information and Organization Sciences (JIOS) od 2006. godine. Bio je član programskog odbora konferencije CARNet User Conference (CUC) od 2007. do 2013. godine.

mr.inf. Matija Novak

Asistent

Fakultet Organizacije i Informatike, Pavlinska 2, 42000 Varaždin.

E-Mail: matija.novak@foi.hr

Iskustvo i važniji projekti.: Matija Novak 2010. stekao je akademski naziv „Magistar Informatike“ sa visokom pohvalom na Fakultetu Organizacije i Informatike. U studenom 2013. upisuje doktorski studij na Fakultetu Organizacije i Informatike i radi kao asistent na istom fakultetu na predmetima: Web dizajn i programiranje, Napredne web tehnologije i servisi i Razvoj web aplikacija. Autor je nekoliko stručnih i znanstvenih članaka iz područja skladišta podatka na temu Web ETL alati. Po završetku diplomskog studija radio je dvije godine u NTH Grupi u Varaždinu kao Voditelj razvoja za produkte i poslovni savjetnik za mobilne aplikacije za švicarsko i njemačko tržište. Nakon toga, radio je jednu godinu u tvrtki MCS d.o.o u Strahonincu kao arhitekt programskih sustava za mobilne i web platforme. U toku rada u navedene dvije tvrtke stekao je iskustvo, znanje i razumijevanje u razvoju Web i mobilnih aplikacija te samom procesu potrebnom za njihov razvoj.

48 CASE27

CASE27 49

KORIŠTENJE RETROFIT RAZVOJNOG OKVIRA PRI IMPLEMENTACIJI ANDROID REST KLIJENTA

USING RETROFIT FRAMEWORK IN IMPLEMENTATION OF ANDROID REST CLIENT

David Ante Macan, Zlatko Stapić, Milan Pavlović

SAŽETAK

Velik broj današnjih mobilnih aplikacija često ima potrebu za dohvaćanjem ili spremanjem podataka pohranjenih na udaljenim mrežnim lokacijama. U većini slučajeva aplikacija zapravo komunicira s web servisom koji prima zahtjeve i vraća odgovore. Jedna od danas popularnih softverskih arhitektura za implementaciju web servisa je REST (eng. Representational State Transfer). Implementacija nativnih REST klijentskih aplikacija u Android operacijskom sustavu obično oduzima dosta vremena, a u slučaju da nije korišten nikakav uzorak dizajna vrijeme potrebno za naknadnu nadogradnju proporcionalno raste sa složenošću aplikacije. Industrija je prepoznala Retrofit, jedan od razvojnih okvira koji olakšavaju i ubrzavaju implementaciju spomenutih klijenata, kako bi razvojni inženjeri mogli više vremena posvetiti drugim važnijim aktivnostima tijekom procesa razvoja. Kako bi smanjio količinu potrebnog koda i dodatno ubrzao razvoj, Retrofit koristi Java anotacije. U ovom radu prikazat ćemo prednosti korištenja Retrofit razvojnog okvira i usporediti taj pristup s onim u kojem se ne koristi nikakav pomoćni razvojni okvir prilikom implementacije REST klijentskih Android aplikacija.

ABSTRACT

Most of today’s mobile applications use one or more communication technologies to send and retrieve data stored online. In majority of these cases applications actually communicate with backend web service which sends and receives the data. Today’s most popular architecture that deals with this functionality, is called REST (Representation State Transfer) architecture, but, implementing REST client in native Android applications usually takes a lot of time, and if it is not implemented by using some architectural pattern, time needed to modify the implementation grows proportionally with application complexity. Industry recognized one helpful framework, Retrofit, which aims to speed up the process and leaves developers more time to focus on the other important activities in the system development process. To reduce even more boilerplate code, Retrofit uses Java annotations which speed up the development process even more. Thus, in this paper we present Retrofit framework and we compare it with native implementation of Android REST client.

1. INTRODUCTION

Today’s mobile applications are Internet dependent. It doesn’t matter what kind of mobile application one would observe, the outcome is almost always the same: the app needs Internet connection to work properly. The newest statistics on mobile apps usage [1]–[3] do not include information on percentage of mobile apps using the Internet as this number is expected to be more than 90% in 2017 [3]. In 2014 we experienced the point in time when the global number of mobile users exceeded the number of desktop users.

Combining the two mentioned information, it is clear that companies are now focusing on publishing mobile apps that can count on available Internet connection. This brings different and new opportunities and nobody wants to lose portion of this big cake.

The reasons for publishing Internet enabled mobile applications are different, but include important drivers that make publishers use web services to support mobile application functionalities. First of all, all monetization models are highly internet dependent. Thus, either you count on having commercials or selling in-app products, you would need internet connection. Also, gathering some information on mobile app usage, synchronizing data among different users, creating social component in the app, having score table in

games and many other functionalities are requiring internet connection.

Although there are different mechanisms that can be used, the most common way of supporting the app’s functionality with backend server is by using push notifications [4], [5] and web services. In this paper we will focus on web services.

According to W3Schools [6], web service can be defined as self-contained and self-describing application component that can be used by other applications and can be communicated with by using open protocols.

After service oriented architectures became widely used for mobile and other applications, the dominant way of exchanging the data with web services was by using SOAP protocol (eng. Simple Object Access Protocol) [7]. Although SOAP is extensible and standardized protocol, the XML used to make requests and receive responses was rather complex and in some languages (including Android) the requests had to be built manually which was problematic due to protocols intolerance on any errors. On the other hand, REST (eng. Representational State Transfer) provides a light-weight alternative [8], and instead of using XML to make a request it relies on simple URL approach that can output the data in any format (for example in CSV, JSOJ or RSS.

50 CASE27

The SOAP and REST-full services have their advantages and disadvantages (see e.g. [9] or [10]) and there are many sources available describing when to use first or second, this debate is out of scope of this paper.

In this paper we will focus on possibilities in implementing mobile clients communicating web services by using REST architecture style. Second chapter describes REST architecture, in third chapter we describe demo system (mobile application and web service) developed for the purpose of this work. In fourth chapter we bring details of web service consumption by native Android implementation while in fifth chapter we do the same by using industry standard, third-party, Retrofit framework. Finally in the last chapter we discuss both implementations and conclude our work.

2. REST ARCHITECTURE

REST stands for Representational State Transfer, an architectural style for distributed hypermedia systems, as Roy Fielding originally described it in his doctoral dissertation in 2000 [8]. The style is derived from several network based styles, such as client-server or peer-to-peer, and includes six main constraints. These constraints were and should be applied in order to build REST style Web architecture.

First constraint is the uniform interface, which defines

the interface between clients and servers. This constraint makes the architecture flexible in a way that each participant can be developed independently.

There are four guiding principles defining the uniform interface constraint [11]. First one defines that it should be resource-based, which means that individual resources should be identified in requests using URIs as their identifiers. For example, a server receives request sent from the client to some URI which identifies a database resource. After processing the request, server sends response to the client in the form of JSON (Javascript Object Notation) string, which is actually a representation of some database record. REST conceptually separates the resources themselves and their representations that are returned to the client.

Second principle is manipulation of resources through representations. If a client owns some representational metadata about particular resource and has permission, it can modify or delete resource on the server.

Third principle is the usage of self-descriptive messages, which include enough information on how to

process themselves. Fourth principle of uniform interface constraint is hypermedia as the engine of application state. Servers deliver state to the clients via body content, response codes and headers, while clients send state representations via request headers, query based parameters, body content and the requested URI [11].

Second major constraint is statelessness. All

communication between client and the server should be stateless, which means that every client’s request should contain enough information for server’s understanding of the request, without any need for retrieving data stored in server context. Consequently, client keeps entire session state. [8]

Third constraint is caching. Clients can cache

responses in order to improve network efficiency, performance and scalability. If a response is cacheable,

it should explicitly or implicitly include that information so the client could know when to cache the response [8], [11].

Client-server separation is the fourth constraint which

fits with separation of client and server concern described in uniform interface constraint. This constraint enables independent development of client and server, as long as uniform interface is not changed. Client can be portable across multiple platforms, not concerned, for example, about data storage which is located on and maintained by the server. On the other side, server is not aware of user interface or state on the client, which is good for improving scalability and lowering required number of server components.

Fifth constraint says that between client and server may be more layers, so the client can never know is it

communicating with end server or some component between them. Layered systems may also improve scalability with the help of shared caches and load balancers. Security policies can also be realized through layers. Although it can improve performance, there should also be some caution because a lot of intermediary components may increase latency to the processing of data.

Last and according to [11], only optional constraint is code on demand. This means that clients can

download generated and/or compiled code for local execution. Scripts and applets can be used as an example. According to [8], allowing features to be downloaded after deployment improves system extensibility, but also reduces visibility. This is the main reason why only this constraint is optional.

2.1 HTTP requests semantic

HTTP request methods, or verbs, as it is written in [11], are used for describing how a server needs to process received request. HTTP POST, GET, PUT and DELETE requests are used the most, since any REST client is able to send such requests. Moreover, that four methods are enough for implementing CRUD (create, retrieve, update, delete) operations respectively. It is important to notice that GET requests must not be used for changing any resource data, only to retrieve it. These verbs also fulfill the uniform resource constraint. OPTIONS and HEAD methods are used less frequently, but more often than others.

As it is mentioned in [11], GET method is used for retrieving (or read) a representation of a resource. If everything works, HTTP GET response contains a representation in XML or JSON with response code of 200 (OK). If an error occurs, 404 (NOT FOUND) or 400 (BAD REQUEST) error message is returned.

HTTP PUT request method is very often used for update operations. Request body should contain newly-updated representation of the original resource which is identified by a known resource URI. In rare cases POST can be used for updating resources and this is when the resource ID is chosen on the client, not on the server. Response on POST request should contain 200 or 204 (if body is empty) response codes. Response body is not strictly defined, but returning a lot of data may affect the network bandwidth [11].

For creation of new resources HTTP POST request method is most often used. It is actually used to create subordinate or child resource of some other (parent) resource. When server receives POST request, it creates new resource and assigns it a new ID.

CASE27 51

Response code “201” should be returned for successful creation, as well as a Location header with a link to the newly-created resource [11].

Finally, DELETE verb is used to delete URI-identified resource. HTTP status 200 (OK) along with response body can be returned (again, with the influence on bandwidth) or 204 (NO CONTENT) is returned [11].

3. EXAMPLE SYSTEM

3.1 System functionality and architecture

For the purpose of this paper we developed simple demo Android application called “Address Manager”. The screenshots of final version of the mobile application are shown in Figure 1. Address manager consists of mobile application and supporting web service. The functional requirement of the application is to enable users to get geographical location (latitude and longitude) of any user defined address.

The geographical location is determined by backend service which also feeds the application with data (returning all addresses stored in remote database). Mentioned web service is implemented in REST architectural style.

The mobile application has modular architecture and for the purpose of this paper we developed two modules communicating the backend services: Native module to communicate web services natively and Retrofit module which uses Retrofit framework [12] for communicating the web service. Both modules are capable of executing GET, PUT and POST requests.

Figure 4. Address manager application screenshots

3.2 Web service specification

The main resources stored on server’s database were geographical addresses. Each address has an ID, name (i.e. location), latitude and longitude. Our service supports creation, retrieval and update of addresses. Services were implemented on Java EE platform, with the help of JAX-RS API.

A client can retrieve current addresses (or locations) by sending the HTTP GET request to base URL http://tinyurl.com/case27-locations. Server will return JSON array with all locations and their geographical coordinates stored in database: [{"id":1,"location": "Ivanec","lat":"46.2228422","lon":"16.1246793"},…].

Creation of new address is enabled by sending HTTP POST request to http://tinyurl.com/case27-locations URL. One form parameter named “location” is required and must contain a name of the place. Although not strictly by the recommendations in [11], POST response body contains JSON object with all data about newly created resource, such as {"id":1,"location":"Ivanec","lat":"46.2228422","lon": "16.1246793"}. Latitude and longitude should not be sent as they are automatically fetched from third-party web service before new address is created.

A client can update address by sending HTTP PUT request to http://tinyurl.com/case27-locations/id URI. Id in the URI path is a path parameter, and request should contain another “location” form parameter. This parameter is new name of the address which wants to be updated. A whole JSON object is returned by the server, including new location and coordinates: {"id":1,"location":"Ivanec New","lat":"47.2228422","lon":"15.1246793"}.

4. ANDROID CLIENT IMPLEMENTATION

4.1 Native Android web-service consumption

The implementation of REST-full service consumption in Android includes development of web-service communication layer, the response parsing layer and manual threading. Although all of these requirements are supported by native set of Java or Android classes, in web-service consumption intensive applications the developers should put serious amount of time in developing the communication and parsing algorithms.

The experienced Android developers usually tend to help themselves by developing their own set of reusable classes (or even framework) or using design patterns in communicating with web services. However, as the web communication in Android should be performed in separate thread, and should be executed asynchronously, the necessity of creating callback mechanism makes this problem even more complex.

The Figure 2 shows our solution that proved to be very handy in several of our projects. Our plugin architecture is composed of four main classes: Repository, Service, Callback and Parser.

Figure 5 – Native plugin class diagram

52 CASE27

- Repository – consists of set of methods that are leaning on web services

- Service – represents web-service communica-tion layer. This class should be flexible to be able to execute any web service request.

- Callback – interface to be implemented by any callback object containing logic for receiving web-service response.

- Parser – static class containing knowledge on parsing the responses.

Other classes presented in Figure 2 are part of application architecture and actually use described implementation.

In our example, NativeRepositoy class realizes

defined interface in order to implement requests for communication with web services. The following code fragment executes POST request and receives response in nativePostCallback object.

public class NativeRepository implements

AddressRepository {

private String ServiceURL =

"http://tinyurl.com/case27-locations";

private OnAddressCreatedListener

onAddressCreatedListener = null;

...

@Override

public void createAddress(Address

address, OnAddressCreatedListener

onAddressCreatedListener,

OnErrorListener onErrorListener) {

this.onAddressCreatedListener =

onAddressCreatedListener;

NativeServices ws = new

NativeServices();

String data = address.getLocation();

ws.execute(ServiceURL, "POST",

nativePOSTCallback, data);

}

private NativeCallback

nativePOSTCallback

= new NativeCallback() {

@Override

public void acceptNotification(String

result) {

try {

onAddressCreatedListener.

onAddressCreated ((

NativeParser.getAddresses

(result)).get(0));

} catch (Exception e) {

e.printStackTrace();

}

}

};

...

}

The previous code fragment implicitly shows the definition of the NativeCallback interface, but to

remove any doubts, this simple interface is presented in the following code:

public interface NativeCallback {

void acceptNotification(String

result);

}

Depending on the complexity of application and web-service layer, it is good to consider making acceptNotification method capable of receiving

more parameters from web-service layer, including response code or other information.

The class that asynchronously contacts backend service is NativeService. Due to its complexity it is not possible to put its whole content here, but the most important part is below:

public class NativeServices extends

AsyncTask<Object, Void, Object[]> {

@Override

protected Object[]

doInBackground(Object... params) {

//parse input parameters

...

HttpURLConnection urlConnection;

try {

URL url = new URL(serviceName);

urlConnection = (HttpURLConnection)

url.openConnection();

urlConnection.setRequestMethod

(serviceMethod);

if (serviceMethod.equals("POST") ||

serviceMethod.equals("PUT")){

urlConnection.setDoOutput(true);

String content = "location=" +

URLEncoder.encode (location,

"utf-

8");

urlConnection.setRequestProperty

("Content-Type", "application/x-

www-form-urlencoded");

urlConnection.setRequestProperty

("Content-

Length",Integer.toString

(content.getBytes().length));

OutputStream output =

urlConnection.getOutputStream();

output.write(content.getBytes());

output.close();

}

//get response

InputStream in = new

CASE27 53

BufferedInputStream(urlConnection.

getInputStream());

BufferedReader rd = new

BufferedReader

(new InputStreamReader(in));

String line;

StringBuilder response = new

StringBuilder();

while((line = rd.readLine()) !=

null){

response.append(line);

response.append('\r');

}

rd.close();

result[0] = response.toString();

} catch (IOException e) {

//notify on exception

} finally {

if (urlConnection != null) {

urlConnection.disconnect();

}

}

return result;

}

@Override

protected void onPostExecute(Object[]

result) {

if (result[1] != null) {

((NativeCallback)

result[1]).acceptNotification(

(String) result[0]);

}

}

}

As it can be seen, we used AsyncTask to implement

asynchronous execution of communication. This determined the class as a whole, as AsyncTask

received only one Object (in our case set of values in

array) and also returns only one object. We used these two objects to encapsulate all information necessary for request and response functionality.

Finally, NativeParse is the last class we used to

interpret the web-service response in JSON format.

public class NativeParser {

public static List<Address>

getAddresses(String jsonString)

throws Exception {

List<Address> addresses = new

ArrayList<>();

//ensure object is json array

...

JSONArray jsonArr = new

JSONArray(jsonString);

int size = jsonArr.length();

for (int i = 0; i < size; i++) {

JSONObject jsonObj =

jsonArr.getJSONObject(i);

Address address = new Address();

address.setId(jsonObj.getLong("id"));

...

addresses.add(address);

}

return addresses;

}

}

Once completed and if implemented correctly, the Service class will probably not grow if dements on layer will increase. However, supporting classes including our Repository and Parser will grow rapidly and will demand lots of developers’ time.

Event by taking into account that presented implementation is created highly modularly and is partially resistant on increase of application complexity we can conclude that this approach is not easy to understand, implement or adjust to other necessities. Thus, the next chapter will bring the much simpler implementation with Retrofit framework.

5. RETROFIT IMPLEMENTATION

Retrofit is a Type-safe REST client for Android and Java by Square, Inc. It turns your REST API into a Java interface to achieve maximum simplicity. This library makes downloading JSON or XML data from a web API fairly straightforward. Once the data is downloaded then it is parsed into a Plain Old Java Object (POJO) which must be defined for each "resource" in the response [12].

Figure 6. Retrofit plugin class diagram

Unlike native approach, Retrofit allows developers to focus more on functionalities than on REST client implementation itself. By default, Retrofit uses JSON formatted messages and GSON [13], [14] for serialization and deserialization of those messages. Of course, those preferences can be changed. Retrofit is flexible enough to allow developers to use different message formats, as well as different parsers for serialization and deserialization of those messages.

54 CASE27

5.1 Concept

Retrofit uses compile-time annotation processor for simpler declaration and boilerplate code reduction of REST client implementation. Simple GET-consuming method can be declared using only @GET annotation above that method. The same thing goes for other REST type services (POST, PUT, etc.). If additional parametrization is needed (for instance, setting content type to x-www-form-urlencoded, there is annotation for that as well.

Sample retrofit service and method for adding a new address to the repository from our API:

@FormUrlEncoded

@POST("/locations")

public Address

postAddress(@Field("location")

String address);

This sample shows how straightforward service and

method declaration could be. The postAddress

method uses POST to send a String with address name (key “location”) to the server and in return retrieves an Address POJO with geolocation data for that address. POJO Address contains attributes from JSON object

„address“. Developers have to create POJO object classes for every such response if needed. Fortunately, there are services that can generate POJO objects from JSON response. One of such services is „jsonschema2pojo“. Method above can POST address name anywhere it is called within the code. Since Android forbids usage of such methods within the main thread, developers would need to create new thread (usually by using AsyncTask, RxJava task etc.) in order to perform wanted operation. Fortunately, Retrofit has an answer for that as well.

If the application needs to be modified to add new address and get response in a callback method, using Retrofit it is very simple:

@FormUrlEncoded

@POST("/locations")

public void

postAddress(@Field("location")

String address, Callback<Address>

callback);

Now the method has a void return type and takes another parameter. Callback parameter above is actually an interface that developers need to implement somewhere in their code where they wish to receive address POJO response. The Callback interface has two methods: onSuccess and onError. If

communication with REST service goes wrong, the second method is triggered. Otherwise, first method is triggered and it has two arguments: generic (T) object for our POJO and Response which is actually a Retrofit response class, containing body, header, status etc.

But the question that remains here is: how can we call those methods if they are defined within an interface without actually implementing that interface?. The answer is very simple: Retrofit uses OkHttp library for HTTP protocol communication. Developers first have to define RestAdapter class instance and then create the

AddressAPI using reflection from that adapter. After

the service has been instantiated, REST services are a simple method call away. Example:

RestAdapter restAdapter =

new RestAdapter.Builder()

.setEndpoint("http://tinyurl.com/

case27-locations").build();

AddressAPI api =

restAdapter.create(AddressAPI.class);

This approach may seem strange at first, but it is the preferred approach in Android development community. It is noteworthy that this approach is highly flexible. If developers need to add more methods for the client, they only need to update their API interface with those methods and use them throughout the application.

5.2 Example

In order to explain how simple Retrofit usage is, we have implemented REST client in our sample application using it. REST service provides us with three methods: GET addresses, POST address and PUT address. For start, we have defined our API interface for Retrofit:

public interface AddressAPI {

public static final String ENDPOINT =

"http://tinyurl.com/case27-

locations";

@GET("/locations")

public void

getAddresses(Callback<List<Address>>

callback);

@FormUrlEncoded

@POST("/locations")

public void

postAddress(@Field("location")

String address, Callback<Address>

callback);

@FormUrlEncoded

@PUT("/locations/{id}")

public void

putAddress(@Field("location"),

@Path("location") String

address, Callback<Address>

callback);

}

If we were to add some other functionality (service methods) for our Address API, best practice would be to add those methods in the interface above as well.

After we have defined the interface, we have to instantiate our RestAdapter object. It is common to

create custom RetrofitHelper utility class for

instantiation of adapter and interfaces. But to keep it simple, we will show only the code snippets we need.

Instantiation of such RestAdapter would look

something like this:

RestAdapter restAdapter = new

RestAdapter.Builder()

.setEndpoint(AddressAPI.ENDPOINT)

.build();

}

We have used RestAdapter with standard

configurations, but thanks to the Builder design pattern by which the RestAdapter class is defined, we can

put additional configuration settings such as: custom converter / parser, custom logging settings etc.

CASE27 55

After the adapter has been defined, we only need to instantiate our defined interface and call the methods we need. We have instantiated our API interface like this:

AddressAPI api =

restAdapter.create(AddressAPI.class);

Now it is only a matter of calling those methods when we need them via API object. For that, we have defined our RetrofitRepository class which handles all

method calls for Retrofit. Snippets from that class are below:

public class RetrofitRepository

implements AddressRepository {

//...

@Override

public void createAddress(String

address, Callback<Address> callback)

{

api.postAddress(address,

callback);

}

//...

@Override

public void updateAddress(String

address, Callback<Address> callback)

{

api.putAddress(address,

callback);

}

//...

@Override

public void

getAddresses(Callback<List<Address>>

callback) {

api.getAddresses(callback);

}

}

The only remaining mystery with this implementation remains with Callbacks. We have used Retrofit's callback approach. For that, we have to define our callbacks somewhere. To improve modularity, we have created separate callback classes which implement Retrofit Callback interface as needed. Simple example of a Callback which receives Address object as a response is implemented like this:

public class AddressCallback implements

Callback<Address> {

//...

@Override

public void success(Address address,

Response response) {

// Success response handling

implementation goes here ...

}

//...

@Override

public void error(RetrofitError

error){

// Error handling implementation

goes here ...

}

}

As it can be seen, Callback interface has two

methods: success and error. After the method from API interface is called, Retrofit handles all request and response mapping, thread execution etc. After the response is returned from the service, Retrofit calls a method from the provided callback object. If the response was successful (status code correct, whole response received within the timeout range etc.), success method is called and the developers can implement their further functionality within that method. Likewise, if an error has occurred with service communication or an error response has been received, Retrofit calls the error method from callback object.

That is basically it regarding our REST client implementation with Retrofit. As you can see, a lot of unnecessary boilerplate is reduced and developers only need to write the code they need.

6. CONCLUSION

In this paper we presented REST application architectural style and two approaches in implementing web-service communication layer in Android applications.

First approach we used was implementation of web-service layer with native Java and Android classes, particularly HttpURLConnection class and connected

specific classes to handle writing the request, reading the responses, handing threading and asynchronous callback.

Second approach we used was implementation with the help of third party framework – Retrofit. This framework is currently recognized as industry standard, is used in many development teams and is actively developed and improved. Retrofit covers almost all web-service communication use cases and specific requirements, and above all it is very easy to use.

In the paper we presented architectural design for both approaches and we consider it as the main contribution of this paper.

Although native approach is robust, it is also hard to adapt to other requirements. On the other hand, approach with Retrofit is very easy to adapt and use. Above all, the quantity of code in second approach will not increase dramatically not even for very demanding and complex applications in terms of web-service communication. The native approach behaves rather oppositely and the quantity of code could increase significantly in demanding applications.

The full source code of this project is available at http://tinyurl.com/case27-code.

References

1 D. Bosomworth, “Mobile marketing statistics 2015” Smart Insights, 2015. Available at: http://www.smartinsights.com/mobile-marketing/mobile-marketing-analytics/mobile-marketing-statistics/ [Accessed: May-2015]

2 ComScore Inc., “The U.S. Mobile App Report” 2014. Available at: http://www.comscore.com/Insights/Presentations-and-Whitepapers/2014/The-US-Mobile-App-Report

56 CASE27

3 Statista, “Statistics and facts on Mobile Internet Usage,” Statista.com, 2015. [Online]. Available at: http://www.statista.com/topics/779/mobile-internet/ [Accessed: May-2015].

4 Android Developers, “Google Cloud Messaging for Android | Android Developers” Google Services, 2015. [Online]. Available at: https://developer.android.com/google/gcm/index.html [Accessed: May-2015].

5 Apple inc., “Local and Push Notifications for Developers - Apple Developer” Developer Apple.com, 2015. [Online]. Available at: https://developer.apple.com/notifications/ [Accessed: May-2015].

6 W3Schools.com, “Introduction to Web Services” Introduction to Web Services, 2015. [Online]. Available at: http://www.w3schools.com/webservices/ws_intro.asp [Accessed: May-2015].

7 W3Schools.com, “SOAP Introduction”, 2015. [Online]. Available at: http://www.w3schools.com/ webservices/ws_soap_intro.asp [Accessed: May-2015].

8 R. T. Fielding, “Architectural Styles and the Design of Network-based Software Architectures” UNIVERSITY OF CALIFORNIA, Irvine, 2000.

9 A. Nene, “Web Services Architecture – When to Use SOAP vs REST” Javalobby, 2014. [Online]. Available at: http://java.dzone.com/articles/web-services-architecture [Accessed: May-2015].

10 J. Mueller, “Understanding SOAP and REST Basics” Software Quality Matters Blog, 2013. [Online]. Available at: http://blog.smartbear.com/apis/understanding-soap-and-rest-basics/ [Accessed: May-2015].

11 F. Todd, “RESTful Service Best Practices, Recommendations for Creating Web Services” RestAPITutorial.com, 2013.

12 CodePath.com, “Consuming APIs with Retrofit” CodePath Android Cliffnotes, 2015. [Online]. Available at: https://guides.codepath.com/android/Consuming-APIs-with-Retrofit#setup [Accessed: May-2015].

13 StudyTrials, “Java Google Json (Gson) Introduction” StudyTrials.com. [Online]. Available at: http://www.studytrails.com/java/json/java-google-json-introduction.jsp [Accessed: May-2015].

14 “Google Gson” Google Gson Home, 2011. [Online]. Available at: https://sites.google.com/ site/gson/Home [Accessed: May-2015].

Information on authors:

David Ante Macan, univ.bacc.inf.

e-mail: amacan@foi.hr

Student at Faculty of Organization and Informatics

David Ante Macan is a first year full time graduate student of Information and Software Engineering at Faculty of Organization and Informatics, University of Zagreb, Croatia. He worked as a junior software developer at Asseco SEE. He has also participated in various competitions, including the Croatian Microsoft Imagine Cup finals, won the best design award at IEEEmadC contest, won the third place at Infinum student Hackathon 2014, etc. His main area of interest is mobile development, especially Android. He is actively working on several projects, including the Personal Exam Assistant (PEAS) project at Faculty of Organization and Informatics. He is also a member of IEEE Institute and is one of the student coordinators and founders of the Group for mobile technologies at Faculty of Organization and Informatics.

Zlatko Stapić, Ph.D.

e-mail: zlatko.stapic@foi.hr

Faculty of Organization and Informatics

Pavlinska 2, 42000 Varaždin

Tell: +385 42 390 820, Fax: +385 42 213 413

Zlatko Stapić is Head of Group for Development and Transfer of Mobile Technologies at University of Zagreb, Faculty of Organization and Informatics. Zlatko obtained his PhD in computer sciences from University of Alcalá (Spain) and in information sciences from University of Zagreb (Croatia) in cotutelled doctorate program. His scientific and research interests include software- and mobile applications development methodologies.

He participated in more than 15 scientific and professional projects and published more than 30 scientific and professional papers. Zlatko is putting a special focus in bringing academia closer to industry with cooperation with industry and inclusion of students in his scientific and professional activities.

Milan Pavlović, univ.bacc.inf.

e-mail: mpavlovi2@foi.hr

Student at Faculty of Organization and Informatics

Milan Pavlović is a first year full time graduate student of Information and Software Engineering on Faculty of Organization and Informatics, University of Zagreb, Croatia. His main fields of interest are software engineering and development. He is also interested in Java application development and mobile application development (Android platform). His second field of interest is networking. Milan is a member of Group for Development and Transfer of Mobile Technologies at University of Zagreb, Faculty of Organization and Informatics.

CASE27 57

MOBILNA APLIKACIJA ZA PRONALAZAK LJEKARNI

Jasmin Abou Aldan, Mario Lončar, Marina Ivašić – Kos

SAŽETAK

Vizualnim prikazom podataka se na jednostavan, lako razumljiv i zanimljiv način mogu predstaviti različiti sadržaji velikom broju korisnika. Jedan od u danas najraširenijih načina prikaza vizualnih podataka na mobitelima je putem mapa koristeći geolokacije. Primjena mapa i geolokacija može biti raznolika, od prikazivanja točno definiranih i odabranih podataka (poput pozicija autobusnih stanica, bolnica, poštanskih ureda), prikaza rute i kalkulacije udaljenosti za odabrani način prijevoza (npr. do odabranog bankomata) pa sve do složenijih aplikacija koje imaju integrirane mape i servise sa mapama.

Problem koji se javlja u razvoju aplikacija koje podržavaju vizualni prikaz podataka je dostupnost i ažurnost informacija koje još uvijek nisu na zadovoljavajućoj razini, kao i činjenica da se ne ulaže dovoljno niti u njihov razvoj niti u održavanje i nadogradnju, a jasno je da je njihov cilje prikazivanje točnih podataka i ažurnih informacija.

U prezentaciji ovoga rada demonstrirati će se mobilna iOS i Android aplikacija koja, koristeći geolokacije, na mapi vizualno predstavlja pozicije ljekarni u Hrvatskoj zajedno sa njihovim relevantnim javnim informacijama. Detaljnije će se usporediti i objasniti razlike implementacija za iOS i za Android platformu.

1. UVOD

Uvidjeli smo da je se za sve više različitih objekata u prostoru osim adrese poznata i njihova geografska širina i dužina. Podaci o geografskoj širini i dužini, npr. za Rijeku 45.3270630, 14.4421760 ili 14° 26' 31.83'' E, 45° 19' 37.43'' N uglavnom nisu praktični za direktno korištenje pa smo takve podatke odlučili predočiti u obliku Geo lokacija na mapama kako bi omogučili korisniku jdnostavnije i intuitivnije korištenje. U ovom radu, demonstriramo aplikaciju koja na mapi prikazuje lokaciju ljekarni u Rijeci i sve javno dostu pne informacije koje bi mogle biti relevantne za korisnika (brojevi telefona, email, radno vrijeme, itd.). Podaci o ljekarnama preuzete su sa registra ljekarni u RH.

Aplikacija je razvijena za dvije mobilne platforme – Android i iOS. U radu detaljnije opisujemo faze razvoja

aplikacije i uspoređujemo razvoj na dvije platforme posebno se osvrčući na razliku između sučelja za razvoj, programskog jezika, paketa koji sadrže klase (API, Framework), te samog testiranja i distribucije gotovog proizvoda.

2. OPIS APLIKACIJE

Glavna funkcionalnost ove aplikacije je pružanje korisniku korisnih informacija o ljekarnama u okolici na jednostavan i praktičan način i navigacija do odabrane ljekarne. Kako bi aplikacija bila jednostavna za korištenje, na početku se prikazuje prikaz svih ljekarni u gradu Rijeci na mapi (Slika 1).

Nakon što korisnik odabere neku ljekarnu, dobiva kratku informaciju o nazivu te ljekarne i o adresi na kojoj se ta ljekarna nalazi (Slika 2).

Slika 1: Prikaz svih lokacija na mapi u verziji ua iOS i

Android

Slika 2: Prikaz naziva i adrese ljekarne za obje verzije

aplikacije

58 CASE27

Ukoliko korisnika zanimaju neke detaljnije informacije, potrebno je odabrati "info gumb" nakon čega mu se otvara novi prozor. U novom prozoru korisnik može vidjeti fotografiju ljekarne, njen naziv i adresu. Nadalje, u tom istom prozoru prikazani su mu kontakt podaci (telefonski broj te e-mail adresa), radno vrijeme ljekarne i datumi kada su odabrane ljekarne dežurne (Slika 3).

Unutar aplikacije, dodani su interaktivni gumbi koji korisniku daju mogućnost slanja e-maila, pozivanja kontakt broja, te pokretanja navigacije.

3. IMPLEMENTACIJA

3.1 Općenito

Platforme koje su korištene za izgradnju aplikacije su Apple-ov iOS i Google-ov Android. Glavna značajka ove aplikacije je manipulacija sa servisima mapa koji omogućavaju "turn-by-turn" navigaciju za automobile i pješake.

Za razliku od Androida, iOS ima podršku za Google i Apple mape. Iako su Google mape bile do nedavno glavne i za iOS, odlučili smo ipak koristiti Apple mape kako bismo mogli prikazati neke od razlika između ta dva servisa. Google mape su jednostavnije za uporabu i imaju podršku za glasovne naredbe. S druge strane, "turn-by-turn" navigaciju u Google mapama je potrebno doraditi. Apple mape imaju impresivan 3D pogled i točnu "turn-by-turn" navigaciju. Nedostatak ovih dvaju mapa je intenzivna potrošnja baterije.

Jezici koji su se koristili u izradi aplikacije bili su (za Android) Java i (za iOS) Swift. Javu možemo koristiti za razvoj aplikacija na raznim platformama, dok je Swift namijenjen isključivo samo za Apple aplikacije. Swift je još uvijek novi programski jezik koji se razvija, no svakom novom verzijom postaje sve bolja zamjena za dugogodišnji Objective-C.

U sintaksi postoje sitne razlike kao primjerice kod

nasljeđivanje gdje kod Jave ono izgleda: class Child

Slika 4: Android Studio

Slika 3: Detaljan prikaz informacija o odabranoj ljekarni

Slika 5: Xcode

CASE27 59

extends Parent{//code}, dok je to kod Swift-a

class Child: Parent{//code}. Deklaracija

varijable je slična onoj kod C++: int myVariable;,

kod Swifta je sintaksa: var myVariable: Int. No

ima i sličnosti koje su izražene kod pozivanja metoda gdje je to u oba slučaja: obj.doWork(arg).

Okoline koje se koriste za programiranje su Android Studio i Xcode. Iako se do nedavno za programiranje Android aplikacija koristio Eclipse, zamijenio ga je novo predstavljeni Android Studio (Slika 4) kojeg smo koristili u razvoju ove aplikacije.

Što se tiče okruženja Xcode (Slika 5) za iOS, ono daje podršku za izgradnju aplikacija za iOS i Mac OS. Zbog svoje brzine i jednostavnosti rada, kao i zbog činjenice da pomaže developerima oko certifikata i profila za njihove aplikacije, smatra se jednim od najboljih okruženja za razvoj aplikacija. Jedna od razlika između navedenih okruženja, je u tome što developer gotovu aplikaciju unutar Xcode-a automatski može postaviti na App Store (Apple trgovina za aplikacije), dok se kod Android Studio-a cijeli postupak odvija na način da okruženje izradi gotov .apk koji developer naknadno sam objavljuje.

Za oba okružja možemo reći da imaju bogate alate za razvoj grafičkih sučelja (Slika 6), jednostavan drag and drop komponenata, pregled na različitim razlučivostima i dobru integraciju sa alatima poput GitHuba.

Glavni "core" framework koji se koristi kod izrade ove aplikacije, a odnosi se na iOS platformu je FoundationKit unutar kojega se nalaze klase za manipulaciju stringovima (klasa NSString), brojevima (klasa NSNumber), nizovima (klasa NSArray), itd. Sve te klase su podklase klase NSObject i naslijeđuju njezina svojstva. Hijerarhija klasa prikazana je na slici 7.

Framework UIKit sadrži sve klase koje se koriste za izgradnju korisničkog sučelja. Taj framework daje arhitekturu za izgradnju prozora (tj view controller-a) i opcije pomoću kojih se korisniku prikazuju svi potrebni podaci na ekranu. On je zaslužan i za interakciju s korisnikom s obizom da prepoznaje korisnikov dodir u interakciji sa sustavom.

MapKit je framework koji se koristi kako bi se dobila puna funkcionalnost karata. Neke od funkcionalnosti koje ovaj framework pruža uključuju standardan prikaz (street-level) karata, evente za zumiranje mapa, prikaz pinova, itd., dok je CoreLocation framework zaslužan za prikaz korisnikove pozicije, te za pokretanje GPS navigacije.

Slično tome kod Androida se koriste APIi (Slika 8) od kojih su u izradi ove aplikacije korišteni osnovni "java.lang" zaslužan za manipulaciju stringovima, integerima, float i double vrijednostima.

Idući API je "android" unutar kojega se nalaze klase za

upravljanje dozvolama i za dodavanje referenci na XMLu unutar kojega je definirano korisničko sučelje,

Slika 6: Layout editor

Slika 7: iOS dijagram klasa

Slika 8: Android dijagram klasa

60 CASE27

kao i "android.content" za komunikaciju između aktivnosti.

Kod korištenja i manipulacijom Google mapama unutar aplikacije (s obzirom da Google Maps- može biti na više platformi), potrebno je importati njegov API "com.google.android.gms.maps" zasebno (Slika 9).

3.2 Mape

Za prikaz mapa i manipulaciju s njima koristila se klasa MapsActivity kod Androida, te MapsViewController kod iOS-a. Kod iOS-a, na početku je potrebno odrediti kakvu mapu želimo koristiti te koje postavke želimo pridodati mapi (u našem primjeru stavili smo standardne mape sa mogućnošću prikazivanja 3D i zumiranja "pitch"):

mapView.mapType = MKMapType.Standard

mapView.showBuildings = true

mapView.pitchEnabled = true

Kod Androida to nije bilo potrebno s obzirom da po

standardu ima predodređene te opcije. Još jedna od prednosti kod Google karata je što gumb koji zumira na korisnikovu lokaciju može biti jednostavno pozvan pomoću:

mMap.setMyLocationEnabled(true);

Kod Apple mapa, taj gumb mora biti dodan u obliku ImageButton-a koji se programira zasebno na način da uzima korisnikovu lokaciju, te dodatno zumira na nju, pa na kraju imamo i po nekoliko linija koda:

@IBAction func myLocation(sender:

AnyObject) {

var newRegion =

MKCoordinateRegion(center:

mapView.userLocation.coordinate,

span:

MKCoordinateSpanMake(0.007, 0.007))

mapView.setRegion(newRegion, animated:

true)

}

Na obje platforme, na početku je stavljeno da zumira na grad Rijeku. Kako bismo odredili područje oko kojega ide zumiranje, kod iOS-a pozivamo CLLocationCoordinate2DMake:

Let zoomLocation = CLLocationCLLocationCoordinate2DMake(4

5.3375, 14.4262)

dok kod Androida pozivamo LatLng:

LatLng rijeka = new LatLng(45.335290,

14.425790);

Na kraju da bismo izvršili zumiranje pozivamo:

mMap.animateCamera(CameraUpdateFactory.n

ewLatLngZoom(rijeka, 12));

za Android, tj kod iOS-a:

mapView.setRegion(MKCoordinateRegion(cen

ter: zoomLocation, span: 0.15),

animated: true)

Prije samog crtanja pinova na mapi, potrebno je predodređene pinove (crvena pribadača) promijeniti na custom sličice (zeleni pin). Kod iOS-a pridodali smo ga

iOS Android

for pharmacy in pharmacies{

//razlamanje svakog string elementa na

pod niz

let tmp =

pharmacy.componentsSeparatedByString(";")

let naziv = tmp[0]

let adresa = tmp[1]

let latitude = tmp[2] as NSString

let longitude = tmp[3] as NSString

//pretvorba string u double vrijednost

let lat = latitude.doubleValue

let lng = longitude.doubleValue

//inicijalizacija pin-a za kartu

let pharm = MKPointAnnotation()

let pharm_coordinates =

CLLocationCoordinate2DMake(lat, lng)

pharm.title = naziv

pharm.subtitle = adresa

pharm.coordinate = pharm_coordinates

//dodavanje pina na kartu

self.mapView.addAnnotation(pharm)

}

for (String s : ljekarne){

//razlamanje svakog string elementa na

pod niz

String[] s2 = s.split(";");

final String naslov = s2[0];

final String adresa = s2[1];

//pretvorba string u double vrijednost

final Double lat =

Double.parseDouble(s2[2]);

final Double lng =

Double.parseDouble(s2[3]);

final LatLng koo = new LatLng(lat, lng);

//inicijalizacija i crtanje pin-a za

kartu

mMap.addMarker(new MarkerOptions().

icon(BitmapDescriptorFactory.fromResourc

e(R

.drawable.zeleni))

.title(naslov)

.snippet(adresa)

.position(koo));

}

Slika 9: Google Maps dijagram klasa

CASE27 61

preko UIImage na način pinView.image = UIImage(named: "green"),

tj.

MarkerOptions().icon(BitmapDescriptorFac

tory.fromResource(R.drawable.zeleni)));

za Android.

Na posljetku ide samo crtanje pinova na kartu. S obzirom da se radi o demo aplikaciji sa malo podataka, podaci su spremljeni u niz i to u obliku ["Naziv ljekarne1; Adresa 1; lat1; lng1","Naziv

ljekarne2; Adresa 2;la2;lng2"], no ukoliko bi

se radilo o većem broju podataka za verziju koja bi išla u distribuciju, takvi podaci bi bili pohranjeni u nekoj bazi podataka (primjer SQLite, tj CoreData). Crtanje se odradilo pomoću for-each petlje:

3.3 Informacije o lokaciji

Nakon odabira željene ljekarne (odabir pin-a), korisnik otvara novi prozor unutar kojega se nalaze sve informacije o odabranoj lokaciji. Klase koje se koriste u ovom dijelu su InfoViewController (iOS) i Info (Android). Da bi klasa znala koje informacije mora otvoriti, iz prijašnje klase MapsActivity/MapsViewController proslijeđuje se podatak naziva ljekarne, te koordinata pina u idući prozor i to na slijedeći način:

Unutar MapsActivity/MapsViewController poziva se

Proslijeđene vrijednosti, spremaju se u varijable u idućem prozoru (klasi) InfoViewController/Info

Novi prozor se otvara te se polja (UILabel (iOS), TextView(Android)) popunjavaju podacima koji su spremljeni unutar switch-a, ovisno o nazivu ljekarne koji je odabran.

Unutar tog prozora pridodani su i interaktivni gumbi pomoću kojih korisnik može nazvati odabranu ljekarnu, korištenjem poziva:

UIApplication.sharedApplication().openUR

L(NSURL(string:

"tel://\(pharmacyTelefon)")!)

tj. za Android:

Intent intent = new

Intent(Intent.ACTION_DIAL,

Uri.fromParts("tel", tele, null));

Na sličan način pokreće se i otvaranje programa za slanje maila ukoliko korisnik odabere interaktivni gumb za slanje maila, jedina razlika je što se kod iOS-a umjesto tel:// koristi mailto:, a kod Androida umjesto Intent.ACTION_DIAL koristi se Intent.ACTION_SENDTO.

3.4 Navigacija

Osim mogućnosti slanja e-maila i telefonskog poziva, korisnik ima mogućnost pokrenuti navigaciju do željene ljekarne. Za pokretanje navigacije koriste se programi koje daje Apple (Apple Maps), odn. Google (Google Maps).

API koji se koristi za pokretanje navigacije je Googleov "google.navigation", dok se za iOS koristi MKDirections sadržan unutar MapKit framework-a. I jedan i drugi rade tako da svojim serverima šalju koordinate korisnika i koordinate pina, te od servera kao odgovor dobivaju step-by-step rutu za pješaka ili automobil, vrijeme koje je potrebno da korisnik dođe do cilja, alternativne rute, itd. Razlika je u tome što taj odgovor kod Androida direktno dobiva Google Maps aplikacija pa se pokretanje poziva jednostavno preko naredbe:

Intent intent = new

Intent(Intent.ACTION_VIEW,

Uri.parse("google.navigation:q=" + lat

+ ", " + lng));

startActivity(intent);

dok kod iOS-a taj odgovor dobiva aplikacija, te pomoću njega onda otvara Apple Maps. Da bi se izveo poziv, poziva se CLPlacemark unutar kojega su spremljene koordinate:

let placemark = placemarks[0] as!

CLPlacemark

let destinationCoordinates =

placemark.location.coordinate

let destination =

MKPlacemark(coordinate:

destinationCoordinates,

addressDictionary: nil)

var mapItem = MKMapItem(placemark:

destination)

self.userLocation.setDestination(mapItem)

iOS Android

override func prepareForSegue(segue:

UIStoryboardSegue, sender: AnyObject?) {

if segue.identifier == "pharmDetail"{

let sender: InfoViewController =

segue.destinationViewController

as!

InfoViewController

sender.pharmacyName = sendObject

sender.pharmacyCoordinates =

destination

sender.userLocation = userLoc

}

}

mMap.setOnInfoWindowClickListener(new

GoogleMap.OnInfoWindowClickListener() {

@Override

public void onInfoWindowClick(Marker

marker)

{

Intent info = new

Intent("com.jamaco.casepharmacy.INFO");

info.putExtra("naslov",

marker.getTitle());

Bundle extras = new Bundle();

extras.putDouble("lat",

marker.getPosition().latitude);

extras.putDouble("lng",

marker.getPosition().longitude);

info.putExtras(extras);

startActivity(info);

}

});

62 CASE27

zatim opcije za pokretanje mape (tip mape koji želimo pokrenuti, te prijevozno sredstvo za koje želimo prikaz rute):

let launchOptions =

[MKLaunchOptionsDirectionsModeKey:

MKLaunchOptionsDirectionsModeDriving,

MKLaunchOptionsMapTypeKey:

MKMapType.Standard.rawValue]

da bismo na posljetku sve to proslijedili aplikaciji Apple Maps i pokrenuli ju:

MKMapItem.openMapsWithItems([response.de

stination], launchOptions:

launchOptions as

[NSObject : AnyObject])

4. ZAKLJUČAK

Kako je demonstrirano u radu, razvoj jednostavnijih aplikacija za iOS i Android platforme se ne razlikuje previše. Slično su i jezik koji se koristi za razvoj aplikacija i sučelje za razvoj. Neke stvari su jednostavnije za programirati kod Apple-a, a neke kod

Google-a. Jedina veća razlika može se vidjeti kod distribucije gotovog proizvoda kod kojega Apple developer prvo mora pustiti aplikaciju na review od strane Apple support tima, kako bi on dozvolio daljnju prodaju aplikacije preko Apple App Store, što kod Google-a nije slučaj, već developer odmah po završetku izrade aplikacije, istu može postaviti na Google Play Store.

Što se tiče otvorenosti podataka, ona nažalost još uvijek nije na onoj razini koja bi trebala biti da bi se ovakvih aplikacija radilo sve više. Većina podataka nalazi se u formatima poput PDF-a ili tabličnih prikaza dostupnih preko web sučelja, manje ih ima u xls, dok ih u cvs formatu koji bi bio najpoželjniji za korištenje unutar neke aplikacije, ima izrazito malo. Uz veću otvorenost, vjerojatno bi i broj aplikacija ovoga tipa bio veći.

Naravno, ovdje ne završava razvoj aplikacije, svaka aplikacija u svom životnom ciklusu nastavlja svoj daljnji razvoj, tako da bismo mogli reći i da ova aplikacija u nekim idućim verzijama može dobiti i podršku za crowd sourcing kako bi sami korisnici mogli dodavati ili brisati one lokacije i podatke koji su se izmijenile.

Literatura:

1 Apple Inc.; About Location Services and Maps; Updated: 2014-03-10; https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/LocationAwarenessPG/Introduction/Introduction.html; (Accessed 2014-06)

2 Apple Inc.; The Swift Programming Language (Book 1,Swift Programming Series);2014-06-02; https://itunes.apple.com/us/book/swift-programming-language/id881256329?mt=11; (Accessed 2014-06)

3 Apple Inc.; Cocoa Touch Framworks; https://developer.apple.com/technologies/ios/cocoa-touch.html; (Accessed 2014-06)

4 Apple Inc.; The Foundation Framework; 2013-10-22; https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/ObjC_classic/index.html; (Accessed 2014-07)

5 Apple Inc.; The UIKit Framework Reference; 2014-09-17; https://developer.apple.com/library/ios/documentation/UIKit/Reference/UIKit_Framework/; (Accessed 2014-07)

6 Apple Inc.; The MapKit Framework Reference; 2013-09-18; https://developer.apple.com/library/ios/documentation/MapKit/Reference/MapKit_Framework_Reference/; (Accessed 2014-08)

7 Apple Inc.; The Core Location Framework Reference;2013-09-18; https://developer.apple.com/library/ios/documentation/CoreLocation/Reference/CoreLocation_Framework/; (Accessed 2014-08)

8 Apple Inc.;UIViewController Class Reference; 2014-09-17; https://developer.apple.com/library/ios/documentation/UIKit/Reference/UIViewController_Class/ ; (Accessed 2014-08);

9 gis.stackexchange.com; questions; Geographic Information Systems; http://gis.stackexchange.com/questions; (Accessed 2014-12)

10 developers.google.com; Google Maps Android API v2; https://developers.google.com/maps/documentation/android/; (Accessed 2014-12)

11 developer.android.com; Tools; http://developer.android.com/sdk/index.html; (Accessed 2014-08)

12 IntelliJ IDEA, https://www.jetbrains.com/idea/ (Accessed 2014-12)

13 ArcGIS Runtime SDK for Android, https://developers.arcgis.com/android/ (Accessed 2014-12)

14 I. F. Darwin, Android Cookbook, http://androidcookbook.com/home.seam (Accessed 2014-12)

Podaci o autorima:

Jasmin Abou Aldan

jasmin.abou.aldanm@uniri.hr

Mario Lončar

mario.loncar@uniri.hr

CASE27 63

Marina Ivašić – Kos

marina@uniri.hr

Department of Informatics University of Rijeka, Rijeka, Croatia

64 CASE27

CASE27 65

POVEZIVANJE BEŽIČNOG SENZORSKOG ČVORA S POSLUŽITELJEM U OBLAKU

CONNECTING A WIRELESS SENSOR NODE TO THE SERVER IN THE CLOUD

Tonko Kovačević, Mario Čagalj, Toni Perković, Ivan Vuković

SAŽETAK

Koncept Interneta stvari (eng. Internet of Things, IoT) predstavlja novu paradigmu koja se odnosi na prožimajuće ili sveprisutno računarstvo koje nastoji unaprijediti tradicionalni Internet međusobnim povezivanjem različitih objekata iz fizičkog svijeta u inteligentne mrežne sustave. Ovaj koncept omogućuje interakciju ljudi s uređajima i uređaja s uređajima, integrirajući ih u jedinstvenu mrežu kojom se upravlja putem web aplikacija. Povezivanje bežičnog senzorskog čvora s poslužiteljem u oblaku predstavlja veliki izazov jer čvor ne posjeduje tradicionalna korisnička sučelja (tipkovnica, serijsko ili ethernet mrežno sučelje, zaslon). U ovom radu se prezentira aplikacija za povezivanje bežičnog senzorskog čvora ograničenih resursa s poslužiteljem u oblaku. Ključne riječi: Internet stvari, bežični senzorski čvor, korisnička sučelja, poslužitelj u oblaku.

SUMMARY

The concept of the Internet of things is a new paradigm related to pervasive and ubiquitous computing that seeks to enhance the traditional Internet by creating intelligent interconnections of diverse objects in the physical world. This concept allows people to interact with devices, and devices with devices, integrating them into a single network, controlled by a web application. Connecting a wireless sensor node to the server in the cloud is a major challenge because the sensor node does not have traditional user interfaces (keyboard, serial, or Ethernet network interface, screen). This paper presents an application for connection of a resource-constrained wireless sensor node to the server in the cloud. Key words: Internet of things, wireless sensor node, user interfaces, the server in the cloud.

1. UVOD

Koncept Interneta stvari (eng. Internet of Things, IoT) predstavlja novu paradigmu koja se odnosi na prožimajuće ili sveprisutno računarstvo koje nastoji unaprijediti tradicionalni Internet međusobnim povezivanjem različitih objekata iz fizičkog svijeta u inteligentne mrežne sustave. Ovaj koncept omogućuje interakciju ljudi s uređajima i uređaja s uređajima, integrirajući ih u jednu mrežu kojom se upravlja putem web aplikacija. Ta se mreža sastoji od velikog broja bežičnih uređaja ograničenih resursa koji ne posjeduju tradicionalna korisnička sučelja (tipkovnica, serijsko ili ethernet mrežno sučelje, zaslon) i imaju ograničenja u vidu proračunskih mogućnosti (procesorska snaga i veličina memorije) te ograničenu raspoloživu energiju (baterije su često izvori napajanja). Godine 2011. broj povezanih uređaja na Zemlji premašio je broj ljudi, a očekuje se da će taj broj doseći 50 milijardi do 2020. godine. Mogućnosti primjene Interneta stvari su široke i raznolike, a prožimaju gotovo svaki aspekt našeg života poput opskrbe, transporta i logistike, zrakoplovne, brodske i automobilske industrije, telekomunikacija, telemedicinskih sustava i zdravstvene njege, brige za starije i nemoćne, energetskih sustava, pametnih zgrada, kuća i ureda, pametnih gradova, poljoprivrede, alarmiranja katastrofa, praćenja stanja okoliša, edukacije i drugo.

Bežični senzorski uređaji mogu komunicirati međusobno i s osobnim uređajima (gadgetima) poput pametnih telefona, tableta, pametnih televizora itd., preko bežičnih mrežnih tehnologija kratkog dometa kao što su Bluetooth, ZigBee ili WiFi. Ovi uređaji također mogu

razmjenjivati podatke s udaljenim web poslužiteljima izravno, primjerice pomoću GSM/UMTS/LTE tehnologije, ili neizravno pomoću različitih WiFi proksija (WiFi pristupne točke, hotspotovi na pametnim telefonima itd.). Međutim, prije svake komunikacije potrebno je inicijalizirati senzorski čvor za pouzdanu i sigurnu komunikaciju s drugim uređajima. Ovdje se pod pojmom inicijalizacije senzorskog čvora misli na informacije koje je potrebno unijeti u sam čvor za njegovo ispravno funkcioniranje (njegov identitet, vrste i broj senzora), na unos komunikacijskih parametara (adrese uređaja i poslužitelja) i tajnih informacija (zaporke, ključevi, certifikati). Ovaj proces je veoma

bitan jer je u bežičnoj senzorskoj mreži bitno osigurati pouzdanu i sigurnu komunikaciju kao i privatnost i integritet informacija [1].

Problem inicijalizacije bežičnih senzorskih uređaja predstavlja veliki izazov, posebno za uređaje kao što su iBeacons [2] ili LIFX pametne žarulje [3], koji nemaju tradicionalna korisnička sučelja (tipkovnice ili zasloni). Pri tome metode za inicijalizaciju senzorskih uređaja i njihovo međusobno povezivanje, za povezivanje tih uređaja s pametnim telefonima/tabletima i/ili s udaljenim poslužiteljima u oblaku (eng. remote cloud servers) trebaju biti vrlo jednostavne i intuitivne za krajnje korisnike. Ove metode ne smiju zahtijevati da krajnji korisnik obavlja složene i na pogreške osjetljive konfiguracijske postupke (procedure) uključujući potrebu za dodatnom opremom, odabirom i upisivanjem lozinki za svaki mrežni uređaj, čitanjem dugih uputa i sl. Skalabilnost je također jedan od bitnih zahtjeva koji trebaju zadovoljiti sigurne metode za inicijalizaciju

66 CASE27

razumno velikog broja bežičnih uređaja (deseci, stotine ili čak tisuće uređaja).

Osnovni koncepti koji se odnose na bežične senzorske mreže dani su u drugom poglavlju rada. U trećem poglavlju se opisuje problem inicijalizacije bežičnog senzorskog čvora i njegovog povezivanja s drugim uređajima. Povezivanje bežičnog senzorskog čvora s poslužiteljem u oblaku opisuje se u četvrtom poglavlju, a zaključci su izvedeni u petom poglavlju rada.

2. BEŽIČNE SENZORSKE MREŽE

Bežična senzorska mreža (BSM) se sastoji od prostorno distribuiranih autonomnih uređaja koji koriste različite vrste senzora (osjetila), a međusobno su povezani komunikacijskom mrežom. Pod pojmom bežičnog senzorskog čvora podrazumijeva se uređaj koji se sastoji od 4 glavne komponente:

senzora (osjetila), mikrokontrolera, komunikacijskog sustava i sustava za napajanje (uglavnom baterije).

Bežični senzorski čvorovi prikupljaju različite informacije iz okoline ovisno o aplikaciji u kojoj se koriste. Tako se u senzorskoj mreži za nadzor kvalitete zraka prikupljaju podaci o temperaturi, vlažnosti, tlaku, raznim vrstama plinova (zagađivača). Na slici 1. je prikazana bežična senzorska mreža za nadgledanje stanja pacijenta. Senzori prikupljaju podatke o temperaturi, krvnom tlaku i razini glukoze u krvi. Na osnovu prikupljenih podataka inzulinska pumpa isporučuje određenu dozu inzulina u organizam. U isto se vrijeme prikupljeni podaci mogu slati putem javne telekomunikacijske mreže u telemedicinski sustav. Liječnik na osnovu tih podataka može poduzeti odgovarajuću akciju kao što je promjena doze inzulina.

Bežična senzorska mreža omogućava prikupljanje raznih vrsta podataka u realnom vremenu, pohranjivanje prikupljenih podataka i poduzimanje odgovarajuće akcije na osnovu prikupljenih informacija. Jedna od bitnih prednosti bežičnih senzorskih mreža u odnosu na standardne ''žičane'' mreže je pružanje mobilnosti čime se omogućava kretanje korisnika unutar mreže.

Bežične senzorske mreže su organizirane za rad na

sljedeća dva načina:

ad-hoc – ne postoji središnji čvor, nego samo niz ravnopravnih i međusobno povezanih čvorova, a direktna komunikacija je moguća samo s onim čvorovima koji se nalaze u dometu tog čvora,

infrastrukturni – podrazumijeva postojanje središnjeg čvora s kojim su povezani svi ostali čvorovi u mreži, a ujedno ovaj čvor može služiti za povezivanje s drugim mrežama (gateway).

Za komunikaciju unutar bežične senzorske mreže uglavnom se koriste ZigBee, Bluetooth i 6LoWPAN tehnologije, slika 2. Za povezivanje bežične senzorske mreže s javnom mrežom i Internetom uglavnom se koriste WiFi i GSM/UMTS/LTE tehnologije.

Iako karakteristike bežičnih senzorskih mreža ovise o konkretnoj primjeni mogu se izdvojiti sljedeće glavne karakteristike:

mala potrošnja energije (baterijska napajanja), nedostatak korisničkih sučelja, ograničena procesorska snaga i raspoloživa

memorija, mobilnost čvorova, mogućnost popravka kvara na čvoru, skalabilnost u velikom rasponu implementacije, sposobnost rada u specifičnim uvjetima, sigurnost podataka i komunikacije i jednostavnost primjene za krajnjeg korisnika.

Slika 2. Radio tehnologije koje se koriste unutar BSM kao i za povezivanje s javnom telekomunikacijskom mrežom

Slika 1. Bežična senzorska mreža na tijelu pacijenta

CASE27 67

3. PROBLEM INICIJALIZACIJE BEŽIČNOG SENZORSKOG ČVORA

Za pouzdanu i sigurnu komunikaciju unutar bežične senzorske mreže veoma je bitna ispravna konfiguracija senzorskog čvora. To znači da je prije same komunikacije potrebno unijeti odgovarajuće informacije u senzorski čvor koje se odnose na njegov identitet, funkcionalnost, komunikacijske i sigurnosne parametre. Kao što je već u uvodu napomenuto ovaj proces nazivamo inicijalizacijom senzorskog čvora. Pri tome jedan od glavnih problema predstavlja nedostatak korisničkih sučelja kao što su serijska ili mrežna (ethernet) sučelja, tipkovnice i zasloni za unos informacija u sam čvor.

Postoje brojna rješenja koja se bave ovom problematikom, a neka od njih pretpostavljaju da su senzorski čvorovi prethodno instalirani od strane proizvođača što značajno umanjuje jednostavnost primjene za krajnje korisnike i ugrožava sigurnost cijele mreže [4, 5]. Ova pretpostavka nije razumna i predstavlja veliki rizik za sigurnost mreže što pokazuje i primjer otkrivenih slabosti kod LIFX pametnih žarulja. Rješenja poput Message-in-a-Bottle [6] i KALWEN [7] temelje se na primjeni specijaliziranog hardvera (Faradayev kavez) u fazi inicijalne konfiguracije mreže. Ova su rješenja dosta sigurna, ali su prilično skupa i zahtjevna za krajnjeg korisnika jer se oslanjaju na primjenu specijaliziranog hardvera. Brojna su rješenja za sigurnu inicijalizaciju mreže bežičnih uređaja koja se temelje na primjeni višekanalnih protokola (multichannel protocols), gdje se komunikacija između mrežnih uređaja obavlja preko dva kanala. Jedan kanal je nesigurni širokopojasni radio kanal, a drugi je specijalni uskopojasni OoB (Out-of-Band) kanal kao što su kanal s vidljivom ili infracrvenom svjetlošću ili akustični kanal. Međutim još uvijek ne postoji jedinstveno rješenje koje zadovoljava korisničke zahtjeve kao što su:

jednostavnost primjene za krajnjeg korisnika, skalabilnost u odnosu na relativno veliki broj

čvorova, sigurnost informacija i komunikacije i robusnost na pogreške.

Komercijalno rješenje BlinkUp razvijeno od strane Electric Imp [8] koristi bljeskajući zaslon (flashing screen) za prijenos informacija koje bežični uređaj prima preko fotodetektora. Glavni je nedostatak ovog rješenja

što napadač može jednostavnim promatranjem kanala vidljive svjetlosti (primjenom video kamere) saznati tajne informacije, mala brzina prijenosa informacija preko kanala vidljive svjetlosti te potreba za primjenom specijaliziranog hardvera (imp module).

U radu [9] predstavljeno je rješenje LIRA koje rješava problem inicijalizacije bežičnih senzorskih čvorova i sigurne komunikacije unutar bežične senzorske mreže, a krajnje je jednostavno za primjenu i intuitivno za krajnjeg korisnika. Ovo rješenje također koristi kanal vidljive svjetlosti za inicijalizaciju senzorskih čvorova i radio kanala za autentikaciju. Rješenje LIRA je vrlo jednostavno i intuitivno za krajnjeg korisnika. Korisnik jednostavno postavi bežične senzorske uređaje na horizontalno postavljen zaslon i pokrene proceduru za inicijalizaciju. Ostatak procesa se automatski odvija i završetak procesa se signalizira korisniku pomoću upaljene zelene svjetleće diode (LED). U slučaju da je došlo do pogreške u procesu inicijalizacije određenog senzorskog čvora to se signalizira korisniku bljeskanjem svjetleće diode i on treba jednostavno ponoviti proceduru. Ovo rješenje dobro skalira u odnosu na broj senzorskih čvorova, a glavni nedostatak mu je mala bitska brzina prijenosa preko kanala vidljive svjetlosti koja iznosi 10 bit/s. Također ovo rješenje nije prilagođeno za povezivanje senzorskog čvora s drugima čvorom putem javne telekomunikacijske mreže ili s poslužiteljem u oblaku.

4. POVEZIVANJE SENZORSKOG ČVORA S POSLUŽITELJEM U OBLAKU

U ovom poglavlju se opisuje kompletno rješenje za inicijalizaciju bežičnog senzorskog čvora, povezivanje na Internet i slanje podataka na poslužitelj u oblaku, slika 3. Ovo rješenje se sastoji od dva dijela. U prvom se dijelu inicijalizira senzorski čvor preko kanala vidljive svjetlosti, a zatim putem radio kanala povezuje s poslužiteljem u oblaku. Na slici 4. Prikazan je izgled razvijenog senzorskog čvora.

Za inicijalizaciju senzorskog čvora putem kanala vidljive svjetlosti razvijena je web aplikacija prikazana na slici 5. Korisnik jednostavno unese informacije koje služe za inicijalizaciju senzorskog čvora. Nakon toga korisnik postavi senzorski čvor na označeno područje na ekranu i pokrene proceduru ''Start Flash'' prijenosa informacija putem bljeskajućeg zaslona, slika 6. Završetak

Slika 3. Inicijalizacija senzorskog čvora preko kanala vidljive svjetlosti i povezivanja s poslužiteljem u oblaku

68 CASE27

prijenosa informacija preko kanala vidljive svjetlosti je signaliziran korisniku pomoću svjetleće diode (LED) s tri plava bljeska.

Slika 5. Aplikacija za inicijalizaciju senzorskog čvora

Slika 6. Proces inicijalizacije senzorskog čvora

Nakon toga slijedi procedura spajanja senzorskog čvora preko radio kanala (WiFi) na pristupnu točku koja je povezana s Internetom. Ako se senzorski čvor uspješno spoji na pristupnu točku to je signalizirano korisniku s dva zelena bljeska, a ako povezivanje nije bilo uspješno to je signalizirano s dva crvena bljeska. Zatim slijedi prijenos podataka koji se pohranjuju na poslužitelju u oblaku. Ukoliko su podaci uspješno preneseni zeleno

svjetlo traje dvije sekunde kao signalizacija korisniku, a u slučaju pogreške crveno svjetlo traje dvije sekunde. Nakon toga slijedi režim rada u kojem senzorski čvor periodički šalje podatke poslužitelju svaku minutu (slika 7.), a to je signalizirano korisniku bljeskanjem plavog svjetla.

Slika 7. Proces slanja informacija sa senzorskog čvora na poslužitelj

Aplikacija za prijenos informacija kanalom vidljive svjetlosti prikazana je na slici 5. Podaci koji služe za inicijalizaciju senzorskog čvora unose se u polje za unos podataka u formatu:

X:id:ssid:pwd:API:IP:txt;

Značenje pojedinih podataka je sljedeće:

X – vrsta čvora (samo senzorski čvor, WiFi gateway, GSM modul)

id – identitet čvora ssid – ''service set identifier'' pristupne točke pwd – zaporka API – ključ za slanje informacija na poslužitelj IP – IP adresa poslužitelja txt – tekst polje za unos podataka koji se odnose na

senzore.

Slika 8. Primijenjene nijanse sive za kodiranje informacija

Ovi podaci se prenosi senzorskom čvoru putem bljeskajućeg zaslona. U razvijenoj aplikaciji ''Flash'' podaci se kodiraju s 8 razina za što se koristi spektar od

Slika 4. Bežični senzorski čvor

CASE27 69

8 nijansi sive boje prikazanih na slici 8. Informacija predstavljena „crnom“ nijansom (delimiter) ne prenosi podatke nego služi za razdvajanje pojedinih podatkovnih simbola kako bi se smanjile greške u prijenosu informacija kanalom vidljive svjetlosti.

Većina zaslona današnjih računala, pametnih telefona ili tableta ima frekvenciju osvježavanja (refresh rate) od 60 Hz što znači da je moguće prenijeti 60 okvira (frames) u sekundi, a trajanje jednog okvira iznosi 16,6 ms. Kada bi se koristile samo dvije razine signala maksimalna teoretska brzina prijenosa iznosila bi 60 bit/s. Međutim zbog raznih ograničenja prouzrokovanih karakteristikama zaslona i uvjetima u kanalu vidljive svjetlosti (šum i intersimbolna interferencija ) realno je očekivati brzinu od 30 bit/s. U razvijenoj aplikaciji korišteno je 8 razina (3 bita po simbolu) za kodiranje informacija. Maksimalna teoretska brzina prijenosa na ovaj način iznosi 90 bit/s a u primjeru na slici 9. ostvarena je brzina od 84 bit/s. Ostvarena bitska brzina je manja od maksimalne teoretske zbog početne sekvence za ''učenje'' kao i zbog prelijevanja okvira (frame overflow). Ovo prelijevanje okvira ima za

posljedicu da se trajanje simbola protegne na dva okvira (33,32 ms) umjesto da traje jedan okvir (16,66 ms).

Prijemna strana bežičnog senzorskog čvora se sastoji od vrlo jeftinog, jednostavnog i pouzdanog prijemnika koji se sastoji od fotodiode i otpornika, slika 10.a). Upotrijebljena PIN fotodioda BPW34 je vrlo lako dobavljiva i predstavlja komponentu COTS (Commercial Off-The-Shelf). Ova fotodioda radi u području valnih

duljina vidljivog i infracrvenog svjetla (=430-1100 nm) i ima vrlo malo vrijeme porasta i pada signala (tr=tf=100 ns). Karakteristika ovisnosti reverzne struje fotodiode o osvjetljenju i narinutom reverznom naponu prikazana je na slici 10.b).

Naponski signal primljen pomoću fotodiode se vodi na analogni ulaz mikrokontrolera (Arduino platforma) koji koristi 10 bitni analogno-digitalni konverter, slika 9.

Ovaj signal se uzrokuje s frekvencijom od 1kHz, odnosno uzorci se uzimaju svaku milisekundu. Nakon toga se signal kvantizira na osnovu sekvence za ''učenje''. U razvijenoj aplikaciji se koristi osam kvantnih razina prikazanih na slici 9. Za određivanje pojedinih razina i eliminaciju šuma primijenjen je filtar s pomakom

Slika 10. a) Prijem signala pomoću fotodiode; b) Ovisnost reverzne struje upotrijebljene fotodiode o reverznom naponu i osvjetljenju

Slika 9. Primljeni signal na fotodetektoru

70 CASE27

sredine (moving average filter) s 16 članova dan formulom:

Nakon što su određene naponske razine za pojedine simbole vrši se dekodiranje primljenih informacija. Primijenjeni kanal vidljive svjetlosti je jednosmjerni komunikacijski kanal jer bljeskajući zaslon odašilje informacije koje se primaju pomoću fotodetektora. To znači da ukoliko je došlo do pogreške u prijenosu informacija preko ovoga kanala to se ne može detektirati, nego tek za vrijeme radio komunikacije prilikom povezivanja na bežičnu pristupnu točku ili prijenosa informacija na poslužitelj. Primijenjena metoda dekodiranja informacija je vrlo jednostavna i ''jeftina'', odnosno ne troši puno resursa senzorskog čvora i odvija se u stvarnom vremenu. Zbog navedenih razloga ne primjenjuje se zaštitno kodiranje (CRC kodovi, Hammingovi kodovi), nego ukoliko je došlo do pogreške prilikom prijenosa informacija preko kanala vidljive svjetlosti to se otkriva kasnije u procesu radio komunikacije. Ukoliko je došlo do pogreške to se signalizira korisniku pomoću bljeskanja crvene LED. U ovom slučaju korisnik treba ponoviti kompletnu proceduru inicijalizacije senzorskog čvora. Nakon što su informacije uspješno dekodirane senzorski čvor se povezuje s pristupnom točkom i zatim šalje informacije na poslužitelj u oblaku, slika 11.

5. ZAKLJUČAK

U radu je prezentirana aplikacija za inicijalizaciju bežičnog senzorskog čvora koja podrazumijeva unos podataka koji se odnose na samu funkcionalnost senzorskog čvora (identitet, vrsta senzora), komunikacijske parametre (IP adresa poslužitelja, adresa čvora u senzorskoj mreži) i sigurnost (SSID, lozinka, ključevi). Za prijenos navedenih podataka razvijena je web aplikacija s bljeskajućim zaslonom. Nakon što je senzorski čvor inicijaliziran on se spaja na bežičnu pristupnu točku (WiFi), a nakon toga na

poslužitelj u oblaku na kojem se pohranjuju i prezentiraju senzorski podaci. Rješenje prezentirano u ovom radu je korisnički orijentirano što znači da je vrlo jednostavno i intuitivno za krajnjeg korisnika. Osim toga rješenje je skalabilno i robusno na pogreške.

Literatura:

1 U. R. Singh, S. Roy, and H. Mutum. A survey on wireless sensor network security and its countermeasures: An overview. International Journal of Engineering Science Invention, 2, 2013.

2 http://estimote.com/ [Online; accessed 10-April-2015]

3 http://www.lifx.com/ [Online; accessed 16-May-2015]

4 L. Eschenauer and V. D Gligor. A key-management scheme for distributed sensor networks. In Proceedings of the 9th ACM conference on Computer and communicationssecurity, pages 41–47. ACM, 2002.

5 A. Perrig, R. Szewczyk, JD Tygar, V. Wen, and D. E Culler. Spins: Security protocols for sensor networks. Wireless networks, 8(5), 2002.

6 C. Kuo, M. Luk, R. Negi, and A. Perrig. Message-in-a-bottle: user-friendly and secure key deployment for sensor nodes. In international conference on Embedded networked sensor systems. ACM, 2007.

7 Y. W. Law, G. Moniava, Z. Gong, P. Hartel, and M. Palaniswami. Kalwen: A new practical and interoperable key management scheme for body sensor networks. Security and Communication Networks, 4(11), 2011.

8 https://electricimp.com/ [Online; accessed 6-April-2015]

9 T. Kovacevic, T. Perkovic, M. Cagalj. LIRA: A New Key Deployment Scheme For Wireless Body Area Networks. SoftCOM 2013 (10.1109/SoftCOM.2013.6671884), Primošten, Croatia

Slika 11. Prikaz prikupljenih informacija na poslužitelju

CASE27 71

Podaci o autorima:

Tonko Kovačević, mr. sc. Mario Čagalj, dr. sc.

Sveučilišni odjel za stručne studije,

Sveučilište u Splitu

FESB Split,

Ruđera Boškovića 32

Livanjska 5, 21000 Split 21000 Split

Mob. 091 33 44 199 e-mail: mcagalj@fesb.hr

e-mail: tkovacev@oss.unist.hr

Toni Perković, dr. sc. Ivan Vuković, student

FESB Split,

Ruđera Boškovića 32

Sveučilišni odjel za stručne studije Sarajevska 28,

21000 Split 21000 Split

e-mail: toperkov@fesb.hr rixfra@gmail.com

72 CASE27

CASE27 73

APLIKACIJA S PROŠIRENOM STVARNOŠĆU ZA GRAD VARAŽDIN

AUGMENTED REALITY APPLICATION FOR CITY VARAZDIN

Ana Ćorić Samardžija

SAŽETAK

Živimo u svijetu gdje su naše svakodnevne aktivnosti posredovane tehnologijom. Računalni hardver postaje svaki dan sve manji i snažniji, te kao posljedicu donosi temeljne promjene u načinu kako provodimo interakciju s tehnologijom. Proširena stvarnost je vrsta tehnologije koja nam omogućava da se digitalni sadržaji (poput videa, slike, animacije, 3D modela i dr.) integriraju sa realnim svijetom te na taj način proširimo (obogatimo) doživljaj stvarnosti koja nas okružje. Primjer takvih informacija može biti prepoznavanje objekata te prikaz dodatnih informacije o promatranom objektu (visina, boja, klasifikacija itd..). Današnji pametni mobiteli i tableti su opremljeni sa brzim procesorima, jakim grafičkim komponentama, velikim ekranima osjetljivim na dodir, kamerom visoke rezolucije, GPS senzorima, kompasom, akcelerometarom, i drugim senzorima te su stoga idealni za proširenu stvarnost bili vani na otvorenom ili u zatvorenom prostoru. Tehnologija proširene stvarnosti je popularna u vojnoj industriji, arhitekturi, medicini, marketingu, edukaciji i turizmu. U ovom radu biti će prikazan i opisan projekt izrade aplikacije s proširenom stvarnošću za grad Varaždin. Aplikacija je razvijena za iPhone/iPad uređaje te koristi Metaio razvojni okvir za razvoj elemenata proširene stvarnosti. Aplikacija omogućava pretraživanje ključnih točaka od interesa (engl. Points of Interest) i integraciju multimedije za svaku ključnu točku, te prepoznavanje slika i prikaz multimedijalnih objekata.

ABSTRACT

We live in a world where our daily activities are mediated by technology. Computer hardware is becoming every day smaller and more powerful, and as a result brings a fundamental change in the way we interact with technology. Augmented Reality is technology that allows us to merge digital content (such as video, images, animations, 3D models, etc.) with the real world and thus augments (expands) our experience of the reality that surrounds us. An example of such augmented information can be object recognition and additional information display about the observed object (height, colour, classification, etc.). Today's smartphones and tablets are equipped with a fast processor, powerful graphics components, a large touch screen, high resolution camera, GPS sensors, compass, accelerometer, and other sensors and therefore are ideal for the augmented reality for both indoor and outdoor. Augmented reality technology is popular in the defence industry, architecture, medicine, marketing, education and tourism. This paper will present and describe a project of tourist augmented reality application development for city Varazdin. The application is developed for iPhone/iPad users and uses Metaio development framework for the development of augmented reality elements. The application enables users to search the key points of interest (POI), and to see multimedia for each POI, and as well image recognition and integration of multimedia objects.

1. UVOD

Proširena stvarnost (engl. Augmented Reality AR) je varijacija virtualne stvarnosti. Korištenjem tehnologije virtualne stvarnosti gubimo osjećaj sa stvarnim svijetom (realnim okruženjem), dok s proširenom stvarnošću možemo iskusiti djeliće virtualne stvarnosti bez da gubimo osjećaj stvarnog svijeta u kojem se nalazimo [1]. Proširena stvarnost se može definirati kao dio kontinuuma između stvarnog i virtualnog svijeta kao dvije krajnosti [2]. Proširena stvarnost nije alternativa

stvarnom svijetu već dodana vrijednost kako bi korisnik doživio iskustvo stvarnog svijeta na drugačiji način. Proširena stvarnost nam omogućava da vidimo stvarni svijet obogaćen sa računalom generiranim objektima. Tehnologija omogućuje kombiniranje fizičke (stvarne) okoline s virtualnim informacijama poput teksta, videa, grafike, podaci sa različitih senzora itd. Azuma je definirao proširenu stvarnost kao sustave koji posjeduju ove tri karakteristike [1]: (1) kombiniraju stvarne i virtualne objekte; (2) interaktivni su u stvarnom vremenu; (3) smješteni su u trodimenzionalni prostor. Tehnologija proširene stvarnosti se može koristiti na različitim lokacijama bilo u otvorenom ili u zatvorenom

prostoru. Proširena stvarnost se može odnositi na sva ljudska osjetila ne samo na vizualne, grafičke elemente.

Istraživanja i primjena proširene stvarnosti izrazito je aktualno u područjima vojne industrije, graditeljske industrije, arhitekture, medicine, marketinga, industrije igara, edukacije i turizma. Uređaji koji podržavaju proširenu stvarnost postali su znatno manji i dostupniji u odnosu na početke, od 1960.ih gdje su uglavnom korišteni unutar laboratorija [3]. Danas je tehnologija

proširene stvarnosti moguća na svim pametnim mobilnim uređajima (npr. pametni telefoni, pametni dlanovnici) te drugim nosivim uređajima (npr. podatkovne naočale). Iako je primjena tehnologije proširene stvarnosti znatno u porastu u posljednjih nekoliko godina, ipak ova tehnologija je još uvijek u fazi razvoja i svoj puni potencijal nije u potpunosti ostvarila. S obzirom na specifičnosti potreba pojedinih organizacija izrada sustava proširene stvarnosti zahtijeva heterogena znanja kao što su poznavanje problemske domene, poznavanje programskih jezika, dizajniranje grafičkih sučelja, modeliranje i teksturiranje virtualnih objekata, izrada animacija, obradu podataka prikupljenih pomoću raznih senzora itd. U industriji se sve više koriste tehnike virtualnog prototipiranja u

74 CASE27

izgradnji i/ili dizajnu zadataka pri čemu nastaju 2D ili 3D modeli (CAD). Stoga za integraciju funkcionalnosti proširene stvarnosti u proizvodni kontekst organizacija ne predstavlja i ne zahtijeva posebne dodatne troškove, jer organizacije već imaju razvijene modele i simulacije rada te ih jednostavno iskoriste i prikažu u stvarnom vremenu vezano uz konkretne situacije.

2. TEHNOLOGIJA PROŠIRENE STVARNOSTI

Glavne komponente koje su potrebne kako bi se omogućila proširena stvarnost su: (1) senzor za hvatanje stvarnosti (npr. kamera, senzori za temperaturu, vlagu, pokrete, GPS itd.); (2) informacije o sustavu praćenja (engl. tracking system), npr. markeri, slike, 3D objekti, lokacija/pozicija itd.; (3) sučelje na kojemu će se prikazati sloj zaprimljenih i kontekstu prilagođenih informacija npr. pametni telefon, pametni dlanovnici, podatkovne naočale i sl.; (4) komponente za prikupljanje ulaznih instrukcija npr. ekran na dodir, mikrofon ili kamera za praćenje pokreta očiju, podatkovne rukavice itd.; te (5) sadržaj npr. tekst, slika, 2D/3D modeli, audio itd.

Razlikujemo četiri platforme koje se koriste za prikaz proširene stvarnosti. Prva su osobna računala s web kamerom. Ovaj oblik je fiksan jer je vezan uz računalo. Marker se treba postaviti ispred web kamere kako bi se prepoznavanjem markera prikazao virtualni sadržaj na ekranu računala. Ovaj oblik se najčešće koristi za prikaz proširene stvarnosti oglasa magazina, dječjih kolekcionarskih kartica, poslovnih kartica i sl. Drugi skup platformi su digitalni kiosci i digitalni prozori. To su stanice gdje korisnici donose svoje predmete kako bi saznali više o njima pomoću proširene stvarnosti. Jedan od najpoznatiji primjera je Lego kiosk koji prikazuje kako izgledaju sastavljene lego kocke iz kutije. Treći skup platformi su pametni telefoni i dlanovnici. To je ujedno i najrašireniji način pristupa sadržajima proširene stvarnosti. Ovi uređaji osim kamere mogu koristiti i akcelerometar i GPS kako bi prikazali sadržaje zavisno o korisnikovoj trenutnoj lokaciji. Četvrta skupina platformi su nosivi prikazi kao što su naočale i kacige. U skoroj budućnosti ovaj oblik će biti najčešće korišten. Danas se tehnologija proširene stvarnosti najviše koristi u oglašavanju, igrama, edukaciji, turizmu, navigaciji, umjetnosti.

Najveći izazov za rad sustava s proširenom stvarnošću su registracija objekta u stvarnosti, točnost senzora te veličina zaslona koji ukoliko nisu adekvatni smanjuju korisnikov doživljaj i iskustvo te mogu odbiti korisnika od korištenja tih sustava.

3. MOTIVACIJA ZA IZRADU APLIKACIJE S PROŠIRENOM STVARNOŠĆU

Turizam je jedna od najvećih industrija u svijetu. Svaka država ulaže u razvoj i promociju turistički znamenitosti svoje zemlje. Svaki grad ima svoje posebnosti i zanimljive priče koje se isplati vidjeti i čuti. Većina turista prilikom razgledavanja nepoznatog grada želi jednostavan i brz pristup razumljivim, sažetim i kontekstu relevantnim informacijama (trenutna lokacija, naziv i kratki info o objektu itd.). Sve više se koriste razna informacijsko tehnološka rješenja kako bi se obogatila iskustva turista.

Proširena stvarnost pokazala se obećavajućom tehnologijom koja turistima omogućuje pristup

relevantnim sadržajima i informacijama. Prvi primjeri upotrebe tehnologije proširene stvarnosti u turizmu su se pojavili krajem 20og stoljeća. Columbia Touring Machine je rani primjer sustava s proširenom stvarnošću namijenjen za vanjska okruženja [4]. Sljedeći značajniji primjer je Archeoguide sustav iz 2001 namijenjen istraživanju povijesno kulturoloških nalazišta stare Grčke [5]. U novije vrijeme imamo turistička

rješenja s proširenom stvarnošću poput: (1)

Philadelphijski odjel za povijesne zapise [6], (2)

Berlinski zid [7], (3) Londonski Muzej [8], (4) Nizozemski

Arhitektonski Institut [9] i Syndneyska elektrana [10].

3.1 Aplikacija s proširenom stvarnošću za grad Varaždin

VarazdinAR je AR platforma razvijena za iOS uređaje

(iPhone/iPad), te omogućuje turistu grada Varaždina da bolje upozna i istraži ljepote grada Varaždina. Sustav je razvijen korištenjem MetaioSDK razvojnog okvira. Metaio je kompanija koja ima više od deset godina iskustva u razvoja rješenje s proširenom stvarnošću. Za korištenje ovog sustava potrebna je povezanost na besplatnu gradsku bežičnu mrežu ili mobilnu mrežu uređaja. Sustav VarazdinAR je organizirana u četiri glavna modula (slika 1).

Slika 1. Prikaz početnog zaslona sustava VarazdinAR

Prvi modul je prikaz točki od interesa (engl. Points of Interest POI). Na temelju lokacije turista prikazuju se udaljenost i smjer pojedinih točki od interesa (slika 2). Turist može filtrirati informacije prema udaljenosti i prema grupama: povijesni sadržaji, restorani, barovi, prenoćišta.

Slika 2. Prikaz točki od interesa kroz prvi modul

CASE27 75

Drugi modul je prikaz točki od interesa na Apple kartama. Turist može jednostavno vidjeti gdje se trenutno nalazi na karti te što se nalazi oko njega (slika 3). Također prikaz točki na karti može filtrirati prema grupama: povijesni sadržaji, restorani, barovi, prenoćišta.

Slika 3. Prikaz točki od interesa na karti

Odabirom pojedine točke možemo vidjeti više informacija o samoj točci, kako doći do nje, prikaz službene web stranice. Ukoliko je riječ o povijesno relevantnoj točki od interesa, moguće su dvije dodatne mogućnosti prepoznavanja vrata kulturnog spomenika i prepoznavanje sadržaja brošure (slika 4). To su ujedno treći (slika 5) i četvrti modul (slika 6) ovog sustava.

Slika 4. Prikaz detaljnih informacija o značajnim

točkama od interesa

Treći modul je otkrivanje dodatnih sadržaja kroz skeniranje ulaznih vrata povijesnih građevina grada Varaždina. Kada se vrata prepoznaju prikaže se naziv građevine te dodatni sadržaji prvenstveno audio zapis o građevini, ali pojedine građevine imaju i sadržaje poput video zapisa, poveznica na službene stranice građevine, poveznica na povijesne slike o građevini i sl. (slika 5).

Slika 5. Prikaz sadržaja na temelju prepoznavanje vrata

točke od interesa

Četvrti modul je otkrivanje dodatnih sadržaja kroz skeniranje brošure grada Varaždina (slika 6). Ovaj modul pored prikaza dodatnih sadržaja kao što su audio zapis o građevini, video zapisa, poveznica na službene stranice građevine, poveznica na povijesne slike o građevini, dodatna posebnost ovog modula je prikaz 3D modela građevina (slika 7).

Slika 6. Prikaz sadržaja na temelju prepoznavanje

stranica brošure grada Varaždina

Slika 7. Prikaz 3D objekta na temelju prepoznavanje

slike

76 CASE27

Svi moduli su međusobno povezani i omogućuju da turist npr. gledajući brošuru grada Varaždina odluči koju građevinu će posjetiti, s mogućnošću da se informira unaprijed o samoj građevini ili ako mu više paše na licu mjesta.

Tekstualni opisi i multimedijski sadržaji (audio, video, slike, 3D modeli itd.) predstavljaju vrijednost za turista u njegovom kontekstu istraživanja/razgledavanja grada. Proces prikaza sadržaja proširene stvarnosti obuhvaća sljedeće: prvo kamera prikazuje stvarno okruženje, potom program hvata video slike i kreira binarni uzorak, uzorak se uspoređuje s uzorkom iz baze te ukoliko se pronađe sličnost prikazuje se i pozicionira sadržaj ovisno o uzorku (markeru). Informacije su pohranjene na Web server i sadržaji se pozivaju (dohvaćaju) prema trenutnoj lokaciji turista.

4. ZAKLJUČAK

Kako tehnologija znatno napreduje svakog dana, tako i pametni uređaji postaju sve snažniji, te posjeduju bolje višejezgrene procesore i imaju dostupno više radne memorije. Algoritmi za detekciju raznih objekata od interesa sve su napredniji, pa u budućnosti možemo očekivati sve veći broj ovakvih sustava. U turizmu ti sustavi pomažu turistima da pristupe relevantnim i vrijednim informacijama te poboljšaju znanje o turističkim atrakcijama u gradu ili okolici. A za posljedicu mogu pozitivno utjecati na turistički doživljaj, iskustvo i zabavu tijekom procesa istraživanja/upoznavanja novih sredina. Stoga, najveća vrijednost informacijskih sustava s proširenom stvarnošću je u tome što ti sustavi omogućuju personalizaciju sadržaja kontekstu i preferencijama korisnika tj. dodaje se novi interaktivni i dinamični sloj na realnost koja ga okružuje.

Literatura:

1 R. Azuma, A Survey of Augmented Reality. 1997.

2 P. MILGRAM and F. KISHINO, “A Taxonomy of Mixed Reality Visual Displays,” Dec-1994. [Online]. Available: http://search.ieice.org/bin/summary.php?id=e77-d_12_1321. [Accessed: 03-Jun-2014].

3 D. van Krevelen and R. Poelman, “A Survey of Augmented Reality Technologies, Applications and Limitations,” Int. J. Virtual Real., vol. 9, no. 2, pp. 1–20, Jun. 2010.

4 H. A. Karimi and A. Hammad, Telegeoinformatics: Location-Based Computing and Services. CRC Press, 2004.

5 V. Vlahakis, N. Ioannidis, J. Karigiannis, M. Tsotros, M. Gounaris, D. Stricker, T. Gleue, P. Daehne, and L. Almeida, “Archeoguide: an augmented reality guide for archaeological sites,” IEEE Comput. Graph. Appl., vol. 22, no. 5, pp. 52–60, Sep. 2002.

6 Weekly Linkfest « Games Alfresco, “Augmented Reality for Cultural Institutions | augmented.org,” 2011. .

7 Layar, “The Berlin Wall is back,” Layar, 2010. [Online]. Available: https://www.layar.com/news/blog/2010/04/16/the-berlin-wall-is-back/. [Accessed: 23-May-2015].

8 “Museum of London Releases Augmented Reality App for Historical Photos,” PetaPixel, 2010. [Online]. Available: http://petapixel.com/2010/05/24/museum-of-london-releases-augmented-reality-app-for-historical-photos/. [Accessed: 23-May-2015].

9 “Netherlands Architecture Institute - item - See what is not (yet) there,” NAi, 2009. [Online]. Available: http://en.nai.nl/museum/architecture_app/item/_pid/kolom2-1/_rp_kolom2-1_elementId/1_601695. [Accessed: 23-May-2015].

10 S. Chan, “New version of Powerhouse Museum in Layar : augmented reality browsing of museum photos around Sydney,” Fresh & New(er), 2010. .

CASE27 77

OPTIMIZACIJA RAČUNARSTVA U OBLAKU ZA BYOD

Vlatka Davidović, Dijana Liverić, Daniele Milani

SAŽETAK

Računarstvo u oblaku je koncept koji se razvija i svakako predstavlja budućnost u poslovnom okruženju. Promjena u načinu razmišljanja korisnika, koji može s bilo kojim uređajem i s bilo kojeg mjesta pristupiti informacijama, utječe i na dosadašnji način rada, te prelaske na nove načine poslovanja. Vrlina računarstva u oblaku svakako je spremanje i dostavljanje informacija bilo kada i bilo gdje, pri čemu korisnici ne moraju voditi računa o tome gdje se te informacije nalaze. BYOD ili „Bring your own device“ odnosno „Donesi svoj uređaj“ odnosi se na trend koji je trenutno aktualan i predstavlja želje i zaposlenika i poslodavca za povezivanjem poslovne tehnologije sa privatnim uređajima, kako bi im se olakšao rad. Kroz rad se nastoje prikazati pozitivni i negativni aspekti računarstva u oblaku kod prelaska na BYOD okolinu, te kako oba koncepta zajedno utječu na poslovno okruženje. Ključne riječi: računarstvo u oblaku, BYOD, prijelaz na BYOD

ABSTRACT

Cloud computing is developing concept and represent the future of the business environment. Changing in mindset of user, who can access the information with any device and from anywhere, affects the current working process and the transition to new ways of doing business. The virtue of cloud computing certainly is storing and delivering information anytime and anywhere, where users do not need to be aware of where this information is located. BYOD or "Bring your own device" refers to a trend that is topical and represents the employers and employees wishes to connect business with private technology devices, to facilitate his work. This paper is trying to show the positive and negative aspects of cloud computing in the transition to BYOD environment, and how both concepts together affect the business environment. Keywords: Cloud computing, BYOD, transition to BYOD

1. UVOD

Računarstvo u oblaku zajedno sa razvojem mobilnog računarstva, u zadnjih nekoliko godina postali su, ne bez razloga, vodeći tehnološki trendovi.

Računarstvo u oblaku nudi resurse kojima je moguće pristupiti s bilo koje lokacije i u bilo kojem trenutku, pri čemu korisnici ne moraju voditi računa o tome gdje su ti podaci nalaze – oni su negdje "u oblaku". Jednostavnost smještanja podataka u oblak, njihovo korištenje, činjenica da se podacima i aplikacijama u oblaku može pristupiti s bilo koje lokacije, u bilo kojem trenutku i s bilo kojeg uređaja, pridonijeli su razvoju oblačnog računarstva. Primjer softvera u oblaku je Google aplikacija, koja integrira razne aplikacije u oblaku u jedan proizvod. Uz kreiranje Google računa nude se i usluge hosting-a elektroničke pošte, kreiranja, uređivanja i spremanja raznih vrsta dokumenata, dostupna je i analiza podataka prometa na web stranici vezanoj uz račun, pristup mapama cijelog svijeta i još mnogo opcija.

Uz razvoj računarstva u oblaku, postoji i trend sve većeg korištenja mobilnih uređaja koji dolaze u svim mogućim oblicima i veličinama – pametni telefoni, tableti, klasična prijenosna računala, razni hibridi. Mobilni uređaji su postali izuzetno moćni, lagani i jednostavni za korištenje, a brojne aplikacije pisane za njih, interakciju su učinile ugodnom i brzom. Dostupnost

velikog broja aplikacija na tržištu, jednostavnost instalacije, te razni mali ugrađeni hardverski dodaci omogućili su njihovu široku primjenu. BYOD (Bring your own device) poslovni model zaposlenicima omogućuje lakši rad jer rade u poznatom okruženju i sve im je dostupno korištenjem jednog uređaja.

Prebacivanje poslovanja u oblak i povezivanje vlastitih mobilnih uređaja s poslovnim resursima u oblaku zahtjeva strategiju razvoja, optimizaciju poslovanja u oblaku za BYOD, te prilagodbu poslovnog okruženja. Potrebno je razmotriti prednosti i nedostatke prebacivanja poslovanja u oblak, kao i BYOD modela poslovanja, sigurnosne rizike poslovanja u oblaku u BYOD okruženju, te razvijanje softverskih rješenja.

2. RAČUNARSTVO U OBLAKU - PREDNOSTI I NEDOSTACI

Prema NIST (National Institute of Standards and Technology) definiciji Cloud Computinga, to je model koji omogućuje odgovarajući mrežni pristup za dijeljenje računalnih resursa na zahtjev (npr. mrežnih, serverskih, smještajnih, aplikativnih i uslužnih), koji mogu biti brzo dodijeljeni i otpušteni uz minimalan trud oko upravljanja ili interakcije sa davateljima usluge.

Model oblaka sastoji se od 5 bitnih karakteristika:

Samousluga na zahtjev – klijent može jednostrano odrediti računalna svojstva kao što su vrijeme

78 CASE27

poslužitelja i mrežno skladištenje podataka, prema potrebi automatski, bez da kontaktira svakog davatelja usluge zasebno

Široki mrežni pristup – mogućnosti su dostupne preko mreže, pristupa im se preko standardnih mehanizama koji potiču korištenje heterogenih tankih ili debelih klijentskih platformi

Udruživanje resursa – računalni resursi se udružuju, te koriste i dinamički dodjeljuju fizičke i virtualne resurse prema klijentskim zahtjevima

Brza elastičnost – svojstva se mogu dodijeliti brzo i elastično (ponekad automatski) kako bi se brzo smanjila, odnosno otpustiti kako bi se brzo povećala. Krajnjem korisniku se svojstva dostupna za dodjeljivanje čine neograničena, te se mogu dohvatiti u bilo kojoj količini i bilo kojem trenutku

Izmjerljivost usluga – sustav automatski kontrolira i optimizira korištenje resursa iskorištavajući sposobnosti mjerenja na nekoj razini apstrakcije

koja odgovara tipu resursa. [9]

U oblaku davatelji usluga iznajmljuju određene resurse. Firme potpisuju ugovor – SLA (Service level agreement) sa davateljem usluga, te mogu koristiti resurse i platiti ih prema količini korištenja. Takav pristup ima određenih prednosti i nedostataka.

Prednosti korištenja računarstva u oblaku:

Smanjivanje troškova vezanih uz IT – plaća se samo ono što se koristi od resursa. Troškovi vezani uz održavanje i nadogradnju hardvera ili programske podrške su reducirani, obzirom da se cijela infrastruktura, platforma ili softver mogu koristiti u oblaku

Globalizacija informacijskog sustava - raspoloživost i stalna dostupnost usluga s bilo kojeg računala koje ima pristup internetu. Također davatelji usluge garantiraju kontinuiranu dostupnost kroz redundanciju podataka, te automatsko prebacivanje poslova na druge servere u slučaju greške.

Lakše upravljanje kroz analizu poslovanja u realnom vremenu – ovisno o performansama sustava skaliranje se može izvršiti na zahtjev korisnika. Resursi se mogu brzo dodijeliti ili otpustiti, ovisno o tome koliko je opterećenje postojećih resursa.

Povećanje proizvodnje i produktivnosti sa manje ljudi – samim tim su i jednostavniji poslovni procesi. Također se smanjuje trošak ulaganja u edukaciju zaposlenika u IT službi

Uvijek je dostupna nova verzija programske podrške

Nedostaci korištenja računarstva u oblaku:

Sigurnost, privatnost i pouzdanost podataka, te nadzor nad njima

Dostupnost usluge - ukoliko postoje tehnički problemi (problemi sa opterećenjem servera, za korisnika je potreban pristup internetu) usluga možda neće biti dostupna.

Problem ovisnosti o jednom davatelju usluge (migracija podataka iz jednog oblaka u drugi, ukoliko rade s različitim tehnologijama i standardima, nije trivijalna)

Mogući veći troškovi ukoliko je potrebna kompleksnija prilagodba aplikacija, ukoliko se one prebace u oblak

Usko grlo kod prijenosa podataka – mnoge aplikacije intenzivno rade s velikom količinom podataka, pa je dobro smjestiti ih fizički što bliže tamo gdje su potrebni.

Nepredvidljivost performansi kao posljedica dijeljenja resursa.

3. BYOD OKRUŽENJE - PREDNOSTI I NEDOSTACI

BYOD je poslovni model u kojem se na mobilni uređaj zaposlenika instaliraju poslovne aplikacije, odnosno njegovom uređaju se dopušta pristup poslovnim podacima. Ono što karakterizira ovakav pristup za zaposlenika je korištenje jednog uređaja za privatne i poslovne svrhe, odnosno on ne mora sa sobom nositi više uređaja. Međutim, to ujedno briše granicu između poslovnog i privatnog okruženja. Sa stajališta poslodavca, manji su troškovi oko nabave uređaja i edukacije zaposlenika vezano uz njegovo korištenje, no veći oko osiguravanja poslovnih aplikacija za različite vrste uređaja.

Prednosti BYOD okruženja:

Manji troškovi za firmu kod ulaganja u hardver i edukaciju zaposlenika

Poznato okruženje uređaja - zaposlenik poznaje mogućnosti vlastitog uređaja, obzirom da ga koristi i u privatne svrhe. Time se smanjuje već navedeni trošak oko edukacije

Fleksibilnost – korištenje samo jednog uređaja za sve potrebe

Dostupnost informacija - zaposlenik ima uvijek dostupne sve potrebne informacije za kvalitetnije odrađivanje poslovnih procesa

Ažurnost – zaposlenik može brže saznati i primijeniti promjene u poslovanju

Nedostaci BYOD okruženja:

Trošak za djelatnika kod nabave uređaja. Pristup podacima i komunikacija mogu biti na trošak zaposlenika

Adekvatnost uređaja, odnosno dostupnost aplikacija – poslovne aplikacije bi trebale biti prilagođene širokom rasponu različitih uređaja sa različitim karakteristikama i OS-ovima. Međutim, moguće je da neki djelatnici neće imati adekvatan uređaj za instalaciju poslovnog rješenja i pristup podacima.

Sigurnost - obzirom da su podaci dostupni na svim osobnim uređajima djelatnika, lako može doći do sigurnosnog propusta. [5]

Napredniji sigurnosni sustav - potrebna ulaganja za unaprijediti sigurnosni sustav kod prijavljivanja i spajanja na poslovne aplikacije

Strah zaposlenika od gubitka privatnosti – prema istraživanju koje je proveo AdaptiveMobile, među zaposlenicima koji ne koriste svoje uređaje za obavljanje posla, najveće prepreke su želja za odvajanjem privatnog i poslovnog života(44%), te nedostatak povjerenja u poslodavce kojima bi

trebali dati dio kontrole nad uređajima. [4]

Poslovna politika mora voditi računa o nekoliko područja u BYOD okruženju, :

Sigurnosna politika koja naglašava prava i obaveze zaposlenika

Nadzor i osiguranje poslovnih podataka - kontrola nad uređajem obično preko mobile device management MDM softvera koji omogućuje poslodavcu kontrolu nad vitalnim komponentama uređaja, ili ograničavanje kroz osobne ili aplikacijske omotače (wrappers) koji unutar tog okruženja omogućuju zaštitu na aplikacijskom nivou za jednu ili više aplikacija

CASE27 79

Firme mogu nuditi skup vlastitih atraktivnih alata za mobilne uređaje kako bi odvratili zaposlenika za koristi neke druge aplikacije za poslovne

aktivnosti.[14]

Poštivanje zakona o radu koji regulira radno vrijeme – zaposlenik može raditi u bilo koje doba dana i

preko normalnog radnog opterećenja [1]

Zaposlenici koriste više različitih uređaja, brže ih mijenjaju, pa sustav treba osmisliti na način da bude dovoljno fleksibilan da može omogućiti jednostavno preuzimanje aplikacija i konfiguraciju MDM rješenja

Podrška za razne vrste uređaja – treba voditi računa o specifičnostima pojedinih uređaja, kao i o tome da se na tržište stalno izbacuju novi modeli.

4. SIGURNOST PODATAKA U OBLAKU PREKO BYOD

Računarstvo u oblaku i BYOD su u osnovi kompleksni koncepti koji svaki zasebno moraju rukovati mogućim sigurnosnim problemima, no sad ih se promatra zajedno. Problemi sigurnosti se obično povećavaju što su informacijski sustavi kompleksniji.

Sigurnost podataka organizacije je puno širi aspekt u kojem se postavlja pitanja tko i na koji način može doći do podataka. Bez obzira na napredne sustave za provjeru korisnika uvijek postoji mogućnost da će doći do sigurnosnih propusta.

Kod prebacivanja cijelog ili dijela informacijskog sustava u oblak javljaju se novi sigurnosni rizici na koje bi trebalo obratiti pažnju. U oblaku su identificirane 3 šire klase rizika: tradicionalni sigurnosne prijetnje, prijetnje koji se odnose na dostupnost sustava i prijetnje vezane uz kontrolu nad podacima od strane trećih pružatelja usluga.

Tradicionalni sigurnosni problemi uključuju zaštitu infrastrukture na strani korisnika, s posebnim naglaskom na konekciju izvan vatrozida, zaštitu procesa autentikacije i autorizacije, pri čemu se može voditi računa o raznim nivoima privilegija, podijeljenim prema ulogama u organizaciji. Prijelazom u oblak, trebalo bi ažurirati i internu sigurnosnu politiku. Tradicionalni sigurnosni problemi pojavljuju se i za davatelje usluga oblačnog računarstva.

Prijetnje koje se odnose na dostupnost sustava vezane su uz moguće greške u sustave, ispade sustava, katastrofe, te druge događaje zbog kojih usluge u oblaku neće biti dostupne duže vrijeme. Također kod ogromnih kompleksnih sustava kao što je oblak, teže je predvidjeti sve interakcije među komponentama kao i njihove performanse. Veće promjene, kao i dodavanje novih komponenti, proširenje usluga ili transfer na noviju tehnologiju povećavaju rizik od greške.

Kontrola nad podacima od strane trećih pružatelja usluga je problematična zbog nedostatka transparentnosti i limitirane korisnikove kontrole. Podugovori koje davatelji usluga međusobno ugovaraju nisu dostupni korisnicima i korisnici ne mogu kontrolirati što se s podacima događa. Postavlja se pitanje jesu li podaci stvarno izbrisani nakon odlaska kod novog davatelja i raskida ugovora s prethodnim. Uz to, nesigurni API-ji i curenje podataka samo su dio

sigurnosnih rizika.[8]

Neki od primjera sigurnosnih problema u oblaku: gubitak podataka ukoliko nije ugovoren backup istih, dostupnost podataka od svuda i sa bilo kojeg uređaja (postoji veća

mogućnost hakiranja korisničkih računa), općenitost prikaza podataka (ukoliko nije ugovorena mogućnost filtriranja podataka po korisniku kako bi pojedinac vidio samo ono što i smije vidjeti), privatnost (ukoliko dođe do neželjenog pristupa podacima, otkrivaju se poslovne ili privatne informacije/tajne).[12]

Rješenja ovih problema nalaze se u dijelom u SLA ugovoru s davateljima usluga, gdje će se jasno definirati prava i obaveze obje strane, edukaciji korisnika vezano uz čuvanje korisničkog imena i lozinke, te definiranju sigurnosne i poslovne politike o tome koji korisnik, kojeg odjela smije pristupiti kojim podacima.

Sigurnosni rizici u poslovnom BYOD okruženju vezani su uz nekoliko specifičnih područja: gubitak ili krađa fizičkog uređaja, proces autentikacije zaposlenika, pristup aplikacijama na uređaju i mrežni pristup.

Izgubljen ili ukraden uređaj može biti velika prijetnja sigurnosti informacijskog sustava. Aplikacije i osjetljivi podaci koji se nalaze na uređaju mogu biti zloupotrijebljeni, pa bi zaposlenici trebali biti upućeni da odmah izvijeste firmu o gubitku/krađi uređaja. Zlouporaba uređaja može se spriječiti udaljenim brisanjem poslovnih aplikacija i podataka s uređaja. MDM (mobile device management) ima mogućnost praćenja uređaja i udaljenog brisanja. Pristup i nadzor nad uređajem može otvoriti drugi problem: narušavanje privatnosti zaposlenika. Najjednostavniji primjer je

praćenje i bilježenje njegove lokacije.[11]

Drugo rješenje

je MAM (mobile application management) koji može odvojiti poslovne i privatne aplikacije i raditi nadzor na aplikativnoj razini.

Proces autentikacije zaposlenika prilikom korištenja poslovnih aplikacija i pristupa osjetljivim informacijama, trebao bi imati jake sigurnosne mehanizme autentikacije i enkripcije. Najčešći problem zaposlenicima je često unošenje lozinke, koja radi sigurnosti treba imati brojke, velika i mala slova. Kod uređaja na dodir to iziskuje dosta strpljenja, pogotovo ukoliko su ti unosi česti. Navika brzog i jednostavnog korištenja uređaja mogla bi biti uzrok brisanja ili zaobilaženja postavljenih

sigurnosnih mehanizama na uređaju.[11]

Korisnikova okolina može utjecati na aplikaciju. Npr. dijete uzme uređaj prijavljen u aplikaciju bez korisnikovog znanja te izbriše bitne podatke. Aplikacije na uređajima koje se instaliraju u privatne svrhe mogu biti nesigurne i ugroziti i sigurnost poslovnih podataka. Također je pitanje da li učitani dokumenti ostaju pod kontrolom aplikacije, ili im se može pristupiti i izvan

nje.[13]

Mrežni pristup bi morao osiguravati enkripciju prijenosa podataka između mobilnog uređaja i mreže, te je dodatno pitanje mogu li svi uređaji osigurati siguran prijenos podataka.

Edukacijom korisnika može se izbjeći dio sigurnosnih propusta, te smanjiti mogućnost krađe uređaja. Stroga sigurnosna pravila mogu značiti gubitak udobnosti i brzinu rada na uređaju, pa ih treba pažljivo balansirati.

Dobrom konfiguracijom uređaja mogu se zaštititi podaci: provjera trajanja aktivnosti - ukoliko korisnik ne dira uređaj određeno vrijeme onda se može napraviti automatsko odjavljivanje, instalacija aplikacija unutar kontejnera nad kojim bi se mogla vršiti udaljena kontrola, te dopuštanje kontrole nad uređajem, tako da se udaljeno mogu kontrolirati i izbrisati vitalni podaci.

Sigurnost podataka u oblaku preko BYOD uključuje promišljanje o zajedničkim faktorima rizika, a pogotovo treba promatrati onaj dio poslovanja gdje se ti koncepti

80 CASE27

spajaju. Pristup podacima u oblaku korištenjem vlastitog uređaja je rizičan u sljedećim dijelovima:

automatska prijava u oblak, gdje su osjetljivi podaci odmah dostupni

prijava u sustav kroz aplikaciju – automatski spremljeni korisnički podaci za lakšu prijavu

odjava nije automatska nakon dužeg perioda neaktivnosti

krađa uređaja prijenos podataka nije kriptiran podaci u oblaku nisu kriptirani privatni i poslovni podaci na uređaju nisu odvojeni nisu osigurani različiti nivoi dopuštanja pristupa

podacima

Navedeni rizici se mogu svesti na minimum uvođenjem sigurnosne politike u koju će se ugraditi ranije navedeni koraci zaštite. Kod prelaska na računarstvo u oblaku u BYOD okruženju potrebno je prije svega sve rizike uzeti u obzir, te, između ostalog, na temelju toga donijeti strategiju uvođenja.

5. MIGRIRANJE POSTOJEĆEG INFORMACIJSKOG SUSTAVA U SUSTAV U OBLAKU U BYOD OKRUŽENJU

Prilikom postupka prelaska na računarstvo u oblaku i BYOD mogući su problemi. U prethodnom poglavlju su navedeni sigurnosni rizici o kojima treba voditi računa, a vezani su uz sigurnost poslovnih podataka u oblaku, te sigurnost podataka, aplikacija i prijenosa podataka prilikom pristupa podacima s nekog mobilnog uređaja.

Jedan od većih problema na kojeg se može naići je edukacija korisnika za nova pravila poslovanja, te za novi način korištenja sustava. Osim toga, brisanjem granica poslovnog i privatnog okruženja, pojavljuju se dodatne komplikacije kao na primjer plaćanje troškova osobnog računa telekomunikacija zaposlenika. Uz potpisivanje ugovora sa zaposlenikom, dogovorno se može odrediti tko plaća navedene troškove.

Struktura postojećeg informacijskog sustava kod prelaska na oblak i BYOD, mora se prilagoditi novim tehnologijama. Klasičan pristup informacijskom sustavu i korištenje aplikacija zamijenit će se pristupom informacijama u oblaku preko mobilnih uređaja, tableta i raznih hibrida.

Sa financijskog aspekta, najčešće je prilagodba starih rješenja veći trošak, nego razvoj novog projekta od nule. Ukoliko se krene razvijati novo rješenje, nova strategija se može lakše primjenjivati.

Razvoj i prilagođavanje aplikacija različitim vrstama mobilnih uređaja postaje izazov. Razvoj aplikacija za najčešće korištene uređaje, može uvjetovati zaposlenicima korištenje propisanih tipova uređaja. Međutim, ukoliko se uvjetuju određene karakteristike uređaja, potrebne za normalan rad sa poslovnim aplikacijama, organizacija bi trebala osigurati takav uređaj zaposlenicima čiji postojeći uređaji ne zadovoljavaju te karakteristike.

6. RAZVIJANJE SOFTVERSKIH RJEŠENJA U OBLAKU ZA BYOD OKRUŽENJE

Softverska rješenja u oblaku moraju podržavati širok raspon uređaja, ukoliko se radi u BYOD okruženju. Kod razvoja aplikacija za BYOD treba definirati razvojne alate i tehnologiju, financijski model - isplativost

razvijanja ukoliko se aplikacija razvija u vlastitoj firmi, ili se razvoj prebacuje na vanjsku firmu i programere, te podržanost tehnologije na različitim platformama.

Mobilni uređaji imaju različite operacijske sustave, različite veličine ekrana, različita svojstva i dodatke. Razvoj mobilne aplikacije koja će se izvršavati na mnogim uređajima, te platformama različitih mogućnosti je opsežan posao. Ukoliko se radi aplikacija za svaki uređaj zasebno, postavlja se pitanje isplativosti, obzirom da se stalno izbacuju nove verzije mobilnih uređaja. Drugo rješenje je prebacivanje aplikacija i podataka koji su inače pohranjeni na mobilnim uređajima, na servere koji se izvršavaju u oblaku. Na taj način korisnici mogu pristupiti aplikaciji i podacima preko preglednika koji se izvršavaju na različitim mobilnim uređajima. Pri tom se procesiranje i smještanje podataka događa izvan mobilnih uređaja, a na mobilni uređaj se šalje samo

prikaz.[2]

Postoji nekoliko mogućih strategija razvoja aplikacija:

razvoj nativnih mobilnih aplikacija – pišu se za svaki tip uređaja zasebno, te ovise o podržanom programskom jeziku i operativnom sustavu. Razvoj takvog sustava je skuplji, ali svaka aplikacija može nuditi maksimalnu funkcionalnost i domaće okruženje (standardno ponašanje aplikacije u okruženju operativnog sustava).

razvoj web aplikacija – obzirom da današnji mobilni uređaji imaju web preglednike, cijela strategija razvoja može se temeljiti na web aplikacijama za tanke klijente. Klijentsko sučelje se bazira na tehnologijama koje su podržane kroz sve ili većinu operativnih sustava: HTML, CSS i Javascript.[10] Postoje framework okruženja koja se koriste kako bi se smanjio raskorak između web i mobilnih platformi. Ukoliko se mobilne aplikacije promatraju kao tanki klijenti, onda se razvija glavna centralna aplikacija koja će komunicirati sa ostalim aplikacijama putem "json" ili "xml" datoteka. Danas se većina startupova pokreću u tim tehnologijama baš zato što svaki uređaj može s njima jednostavno surađivati, dovoljno je imati web preglednik.

razvoj hibridnih aplikacija – kreiraju se jednom, te postavljaju na različite mobilne uređaje. Nativna, mobilna aplikacija u oblaku, izvršava sve ili neke od korisničkih sučelja u mobilnom pregledniku

Neki od pristupa koje se koriste u razvoju mobilnih aplikacija su: MCC (Mobile Cloud Computing), MEAP (Mobile Enterprise Application Platform), "prvo mobilni" ("mobile-first").

Mobile Cloud Computing (MCC) je paradigma koja nudi potpuno drugačiji pristup u kreiranju mobilnih aplikacija - bogate mobilne aplikacije koje bi se dinamički prilagođavale radnoj okolini prema značenju sadržaja. Radije nego da se svi izračuni i podatkovne operacije rade lokalno, MCC bi iskoristio prednosti oblačne platforme za prikupljanje, smještanje i procesiranje podataka za mobilne uređaje. Arhitektura MCC-a definira načine na koji su mobilni uređaji povezani i u interakciji su sa oblakom. Obzirom na to, spominje se tradicionalni centralizirani oblak, zatim oblačić (server bogat resursima, s pristupom internetu i povezan s mobilnim uređajima kroz lokalnu mrežu (LAN)), te ad-hoc mobilni oblak, gdje susjedni mobilni uređaji skupa dijele resurse. Računarstvo u oblaku proširuje mogućnosti mobilnih uređaja u tri aspekta: računanju, smještaju podataka i mreži.

[7]

MEAP se koristi kao mobilni middleware koji povezuje krajnji izvod podataka (velike aplikacije i baze) s

CASE27 81

mobilnim uređajem, te također nudi skup razvojnih alata HTML/CSS/Javascript i RAD alate 4.generacije. Mobilne aplikacije razvijene kroz MEAP mogu se isporučiti s centralnog servera mobilnim uređajima bez obzira na OS, bez ponovnog prepravljanja koda za svaki uređaj. [3]

"Prvo mobilni" je i strategija i novi način pisanja koda. Umjesto pregleda desktop verzije web sjedišta na mobilnim uređajima, s nekim prilagodbama, korisnici pregledavaju web sjedišta specijalno kreirana za njihove mobilne uređaje. Radi se o novom načinu planiranja UX (user experience) dizajna, koji uređaje stavlja ispred strategije i implementacije

. Dizajneri moraju voditi

računa o korisnicima koji koriste različite kontekste. Tekst bi trebao biti lakši za čitanje i navigaciju, fotografije i mape lako dostupne i sav sadržaj namješten da se ispravno prikazuje na uređaju s kojeg korisnik pristupa.

[6]

Prilikom razvoja softverskih rješenja za BYOD i oblak, treba

voditi računa o prednostima i nedostacima jednog

i drugog koncepta, o sigurnosti, te o specifičnostima u okvirima kojih oba koncepta trebaju zajedno egzistirati.

7. ZAKLJUČAK

Informacijska i komunikacijska tehnologija razvija se u smjeru iskorištavanja sve veće komunikacijske

povezanosti, te se taj razvoj odražava i na ostala područja ljudskog djelovanja, među ostalim i na područje poslovnog okruženja. Poslovni sustavi, kao i njihovi informacijski sustavi prilagođavaju se navedenim trendovima, maksimalno ih nastojeći iskoristiti u poboljšavanju rezultata poslovanja. Pri tom, cjelokupno ili djelomično prebacivanje poslovanja u oblak nosi sa sobom određene tehnološke i financijske prednosti.

Računarstvo u oblaku i BYOD se međusobno nadopunjuju osiguravajući korisnicima ugodan rad bez razmišljanja o tome odakle se pokreću aplikacije i gdje se nalaze podaci, s koje lokacije i kad mogu pristupiti podacima. Obzirom da zaposlenici mogu koristiti vlastite mobilne uređaje, te brzo pristupiti svježim informacijama, povećava se produktivnost i agilnost u poslovanju.

Migracija na računarstvo u oblaku uz BYOD uz postojeću tehnologiju ne mora biti preteška, ukoliko se prvo napravi strategija prebacivanja poslovanja u oblak, te odabere prikladna strategija razvoja aplikacija kojima bi trebale pristupati različite vrste uređaja. Jednostavno rješenje je kreiranje aplikacije u oblaku kojoj se pristupa preko web preglednika. Kod navedene migracije obavezno je donošenje sigurnosne politike koja bi trebala obuhvatiti zaštitu od novih sigurnosnih rizika koji se pojavljuju u specifičnim oblačnim i BYOD okvirima.

Literatura:

1 Chellakari,K., Developing a BYOD Strategy: Weigh the Risks, Challenges and Benefits, http://searchsecurity.techtarget.com/feature/Developing-a-BYOD-Strategy-Weigh-the-Risks-Challenges-and-Benefits (15.04.2015)

2 Claybrook,B., Cloud infrastructure for mobile application development, http://searchcloudapplications.techtarget.com/tutorial/Cloud-infrastructure-for-mobile-application-development, (2.05.2015.)

3 Claybrook,B., Using a MEAP to develop mobile applications, http://searchcloudapplications.techtarget.com/tip/Using-a-MEAP-to-develop-mobile-applications (6.05.2015.)

4 Coyle,A.,Fergusson,S., Top two barriers to mobility uncover employees’ lack of trust in employer and concern for privacy, http://www.adaptivemobile.com/press-centre/press-releases/top-two-barriers-to-mobility-uncover-employees-lack-of-trust-in-employer-an (16.04.2015)

5 Drayton,S., The Advantages and Disadvantages of BYOD, http://www.optimussourcing.com/learninghintsandtips/the-advantages-and-disadvantages-of-byod (20.04.2015)

6 Graham,R., Mobile First: What Does It Mean?, http://www.uxmatters.com/mt/archives/2012/03/mobile-first-what-does-it-mean.php, (6.05.2015.)

7 Liu,F., Shu.P. , Jin,H., Ding, L., Yu,J., Gearing resource-poor mobile devices with powerful clouds: architectures, challenges, and applications, University Of Science And Technology, 2013

8 Marinescu,D.C.: Cloud Computing,Theory and Practice, Elsevier Inc, 2013.

9 Mell,P., Grance,T.: The NIST Definition of Cloud Computing, NIST, Gaithersburg, MD 20899-8930, http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf, (20.3.2015.)

10 Nolle,T.: Optimizing the cloud for the BYOD movement, http://searchcloudcomputing.techtarget.com/tip/Optimizing-the-cloud-for-the-BYOD-movement (20.04.2015)

11 Phifer, L.: BYOD security strategies: Balancing BYOD risks and rewards, http://searchsecurity.techtarget.com/feature/BYOD-security-strategies-Balancing-BYOD-risks-and-rewards (30.04.2015)

12 Rhoton,J: Cloud computing Explained: Implementation handbook for enterprises, Velika Britanija, 2010.

13 Strom,D.: Bring your own device policy: Six questions to ask security providers, http://searchsecurity.techtarget.com/tip/Bring-your-own-device-policy-Six-questions-to-ask-security-providers (30.04.2015.)

14 Zumerle,D.: Security Think Tank: BYOD security: policy, control, containment, and management, http://www.computerweekly.com/opinion/Iscuriti-Think-Tank-BYOD-security-policy-control-containment-and-management (16.04.2015)

82 CASE27

Podaci o autorima:

Vlatka Davidović

vdavid@veleri.hr

Dijana Liverić

dliveric@veleri.hr

Poslovni odjel, Studij informatike, Veleučilište u Rijeci, Trpimirova 2/V

51000 Rijeka, Hrvatska

Daniele Milani

dmilani@unipu.hr Fakultet ekonomije i turizma “dr. Mijo Mirković”, Studij informatike

Sveučilište Jurja Dobrile u Puli, 52100 Pula, Hrvatska

Conference Net@inovativno rješenje za

upravljanje organizacijom konferencija integrirano s društvenim mrežama i dostupno na uređajima upravljanim dodirom

www.conferenceatnet.com

CITUS d.o.o.Dragutina Golika 63, Zagreb

http://www.citus.hrcitus@citus.hr

eMotiondetection

Interactive Motion and gesture controlled

MicrosoftKinect PersonRecog