CASE 2018CASE 2018

26.02.-27.02.2018, Zagreb

RAZVOJ POSLOVNIH I INFORMATIČKIH SUSTAVA

RAZVOJ POSLOVNIH I INFORMATIČKIH SUSTAVA

Brončani pokroviteljiBrončani pokrovitelji

Srebrni pokroviteljSrebrni pokrovitelj

Zlatni pokroviteljZlatni pokrovitelj

ORGANIZATOR

CASE d.o.o.

ORGANIZACIJSKI I PROGRAMSKI ODBOR

TOMISLAV BRONZIN mag. ing. el.

ANTE POLONIJO

MISLAV POLONIJO

ZLATKO SIROTIĆ univ.spec.inf.

ZLATNI POKROVITELJ

SREBRNI POKROVITELJ

BRONČANI POKROVITELJI

Izdavač, priprema i tisak:

CASE d.o.o., Rijeka

Urednik:

Mislav Polonijo

ISSN 1334-448X

UDK 007.5 : 621.39 : 681.324

Copyright "Case", Rijeka, 2018

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, fax: 051/218-043, e-mail: case@case.hr, internet: www.case.hr

SADRŽAJ

dr. sc. Igor Nazor, mr. sc. Karmen Klarin GOTOVI ERP ILI RAZVOJ VLASTITOG RJEŠENJA OD POČETKA? POSTOJI MEĐU-RJEŠENJE

7

Matija Novak, Dragutin Kermek PROFESIONALNI PROGRAMER ZNANJA, STAVOVI I ZABLUDE

13

Marko Meštrović, Tonko Kovačević RAZVOJ IOT APLIKACIJA

21

Zlatko Sirotić PRIMJENA STATISTIKE U ORACLE BAZI PODATAKA

29

dr.sc. Mirko Sužnjević INTERNETSKE MREŽNE IGRE, TRŽIŠTE, TRENDOVI I RAZVOJNI IZAZOVI

39

Velibor Božić GDPR – VAŽNOST PROCJENE RIZIKA

45

Daniel Marković, dr.sc. Marin Kaluža, mr.sc. Bernard Vukelić ANALIZA JAVNO DOSTPUNIH ALATA ZA RAZVOJ IGRE

55

Ivona Čančar, Dino Abazović, dr.sc. Marin Kaluža KORIŠTENJE RJEČNIKA PODATAKA RELACIJSKE BAZE PODATAKA ZA POTREBE GENERIRANJA POSLOVNIH WEB APLIKACIJA

67

Mateo Višković, univ. bacc. inf., doc. dr. sc. Tihomir Orehovački ADITIVNE TEHNOLOGIJE I INDUSTRIJA 3D TISKANJA

77

Mislav Hager, univ. bacc. inf., doc. dr. sc. Tihomir Orehovački PROGRAMIRANJE UREĐAJA ZA INTERNET STVARI

87

Edi Crnković, univ. bacc. inf., doc. dr. sc. Tihomir Orehovački IZRADA INDIE IGRE U UNITY 3D OKRUŽENJU I NJENO PLASIRANJE NA GOOGLE PLAY TRGOVINU

97

CASE2018 KONFERENCIJA

MODELIRANJE; PROJEKTIRANJE; RAZVOJ

Kod uvođenja gotovih, "paketskih" rješenja, preporučljivo je da se poslovni procesi poduzeća u što većoj mjeri prilagode procesima koji su već implementirani u programskom rješenju, kako bi potrebne izmjene bile što manjeg opsega. Kd manje "tipičnih" djelatnosti (primjerice, lokalna samouprava, pružatelji telekomunikacijskih usluga, distributeri energije ili komunalna poduzeća) nemaju veliku korist od gotovih rješenja, te je potrebna izrada rješenja po mjeri ili integraciju više različitih sustava. Predlaže se alternativa razvoju vlastitog rješenja od početka, ali uz veliku fleksibilnost pri definiranju specifičnih poslovnih procesa.

„Timovi koji mogu sve“ su timovi koji su super uspješni – raditi u njima je san svakog programera, imati ih je san svakog menadžera. Što su to timovi koju mogu sve? Kakav im je način razmišljanja? Kakvi su bili prije nego sto su “mogli sve”? Što im je zajedničko?

Temeljem svog iskustva kao voditelj razvojnog tima u Microsoftu, i u zadnje vrijeme kao konzultant za vodeće IT tvrtke u regiji, predavač će prezentirati zajedničke karakteristike takvih timova, i korake koje svaka organizacija može poduzeti da dobije timove koji mogu sve.

Programeri i programiranje i je ozbiljan posao te mu tako treba i pristupiti. Nažalost, većinom "profesionalni" programeri nisu profesionalni. Na predavanju prikazati će se što čini profesionalnog programera, te zašto je fraza "Bitno da radi!" problem. Koje stavove profesionalni programer mora imati, koja znanja, mora imati osim generalnog poznavanja programskog jezika te koje su najveće zablude "profesionalnih" programera.

Mogućnosti za statističku obradu podataka . Oracle sustav za upravljanje bazama podataka (SUBP) ima napredne u samoj BP.

Podaci ne moraju ekstrahirati iz BP u neki (drugi) statistički alat, npr. alat koji radi sa R jezikom, pa onda tako obrađeni vraćati u BP, jer se podaci obrađuju direktno u BP i višekratno se ubrzava proces obrade. Tako je u skupljim edicijama Oracle baze, tj. u Enterprise ediciji (EE), ili u EE nadograđenoj s dodatnim opcijama koje se posebno plaćaju nad EE. No Postoje i moćne statističke SQL funkcije koje se mogu koristiti u svakoj ediciji Oracle baze, što znači i u Standard ediciji, pa i u besplatnoj XE ediciji.

Igre u mreži. Trend je igranje više igrača te njihovo natjecanje. Umrežene igre su redovito najprofitabilnije igre. Razvoj umreženih igara značajno teži od razvoja igara koje se izvršavaju samo na lokalnoj platformi. Prezentirani su trendovi koji pokreću igre prema mreži, karakteristike tržišta, nove

umrežene arhitekture igara, kao i postojeći izazovi u razvoju umreženih igara.

GDPR (GDPR -General Data Protection Regulatory)

Opća uredba o zaštiti osobnih podataka stupa na snagu 25.05.2018., pa se treba hitno prilagoditi. Direktiva je obvezna u svim članicama EU pa tako i u Hrvatskoj i ujednačava praksa zaštite osobnih podataka u svim zemljama članicama EU. Suština dokumenta je zaštita osobnih podataka te osiguravanje pristupačnosti, integriteta i povjerljivosti osobnih podataka. Kako se pripremiti za GDPR, kako osigurati pristupačnost podataka, njihov integritet i povjerljivost. Objasniti ćemo kontekst rizika, vrste rizika, način upravljanja rizicima i njihovo smanjivanje na prihvatljivu razinu.

Microsoft Office 365 sadrži moćne alate koji mogu identificirati, klasificirati i upravljati osobnim podacima u Exchange Online, SharePoint Online, OneDrive i Skype servisima. Pretraživanje sadržaja omogućava nalaženje osobnih podataka prema ključnim riječima, ugrađenim predlošcima ili datotekama što će ubrzati cjelokupni proces implementacije i provođenja Uredbe. O planiranju, procjeni usklađenosti tvrtke s Uredbom, izradi programa upravljana rizikom, o implementaciji saznati ćete više i na radionici „Microsoft Office 365 u službi GDPR-a“.

Primjena GPDR uredbe traži zaštitu koju ostvarujemo primjenom metoda identifikacije, autentikacije i autorizacije korisnika, te kriptiranjem osjetljivih podataka. Trebamo pratiti promjene nad podacima (audit podataka). U slučaju pada servera BP, potrebno je brzo podignuti drugi server BP, korištenjem sekundarnog servera BP za disaster recovery, koji se ažurira (skoro) trenutačno na temelju podataka iz primarnog servera BP. Praćenje promjena nad podacima (audit podataka) i replikacija podataka, uz dobre osobine, imaju i manu - moramo voditi brigu da i te "kopije podataka" budu u skladu s GPDR uredbom.

GDPR traži ovladavanje osobnim podatcima. Tako različite industrije trebaju različite vrste podataka i upravo podaci koje obrađuju, najbolje dijele bolnicu od turističke agencije, proizvodno poduzeće od trgovinskoga itd. Internetska i slična rješenja generiraju ogromne količine podataka i u poslovnim sustavima. Papirnato usklađivanje s zakonskim zahtjevima, bez stvarnoga ovladavanja podatkovnih resursa, dovodi do vjerojatnosti, da će papirnato zajamčena „usklađenost“ biti „provjerena“ tek pri njenoj prvoj povredi. Želja je zakonske zahtjeve o zaštiti osobnih podataka postaviti u kontekst općeg nadzora nad podacima i predstaviti primjer uvođenja poslovnog pojmovnika, kao ključnog alata za ovladavanje podataka i usklađenosti s zahtjevima GDPR. Pomoću alata SQL Secure može se uraditi audit baze podataka, da bi utvrdili: potencijalne

slabosti naše baze i analizirali prava pristupa podacima, utvrdili slabe lozinke, pravila ponašanja servera i dr, te dobilii izvještaje koji nam mogu pomoći u pripremi i provjeri našeg MS SQL i Azure servera. U slučaju neovlaštenog pristupa ili gubitka podataka u bazi podataka, SQL Compliance Manager nam pomaže utvrditi tko je što radio nad kojim podacima i upozorava na sumnjive aktivnosti u realnom vremenu. Ukazuje na aktivnosti potrebne za prevenciju i upravljanje eventualnim incidentima.

1. radionica: Postupak usklađenosti s GDPR-om. Krećemo od izrade plana implementacije, gdje je prva stavka svakako analiza podataka i poslovnih procesa koja rezultira procjenom u kojoj se mjeri odredbe Uredbe odnosi na vašu organizaciju. Analiza započinje razumijevanjem podataka koje imate i gdje se nalaze, te u kojoj mjeri su poslovni procesi usklađeni s odredbama GDPR-a koji regulira prikupljanje, pohranu, korištenje i razmjenu osobnih podataka koji se odnose na identificiranu ili prepoznatljivu fizičku osobu. Demonsti ćemo Microsoft Office 365 alate koji pomažu u otkrivanju, upravljanju, zaštiti i izvještavanju u skladu sa Uredbom o zaštiti osobnih podataka, a odnose se na nestrukturirane podatke koji se nalaze „skriveni“ u elektroničku poštu, dokumente i izravnu komunikaciju, na bazi iskustva predavača koji nose titule Microsoft Most Valuable Professional za Office System & Services.

2. radionica: Primjena metoda dubokog učenja predstavlja nekoliko primjera uspješne primjene metoda dubokog učenja u analizi teksta i slike u poslovnom okruženju digitalnih medija. O Styria projektima možete saznati na njihovoj službenoj stranici: https://www.styria.ai/

MOBILNE APLIKACIJE

Mobilne aplikacije su danas integralni dio svakog poslovnog sustava a ne više samo «nice to have» dodataka poslovanju. Obzirom na dvije platforme koje uvijek želimo podržati, postavlja se pitanje kako optimizirati razvoj i kasnije održavanje. Ukoliko razvijate „native“ aplikacije imate opciju da razvijate za svaku platformu zasebno ili da koristite alat za razvoj multiplatformskih aplikacija. Sa Xamarin Forms, nemate više razloga za razvijati zasebne native aplikacije, što proces razvoja i održavanja čini dužim i skupljim. Na ovom predavanju biti će predstavljen Xamarin Forms kao alat za kompletan multipatformski razvoj sa Visual Studiom 2017.

Microsoft PowerApps omogućuje naprednim korisnicima i profesionalnim razvojnim inženjerima brzu i produktivnu izradu mobilnih aplikacija. Poslovni procesi odvijaju se brzo pa aplikacije koje prate te procese moraju se brzo prilagoditi i promijeniti kako bi procesi bili produktivniji i konkurentniji. Olakšava gradnju bogatih aplikacija bez pisanja koda, korištenjem on-line drag & drop razvojne okoline i jednostavnu mogućnost povezivanja s aplikacijskim servisima u Microsoft Azure ili nekom drugi sustavu u oblaku. Dajemo prikaz razvoja potpuno funkcionalnih prototipova mobilnih i web aplikacija. Na osnovu kojih njih razvojni inženjeri mogu razviti mobilne aplikacije namijenjene široj publici ili jednostavno, te aplikacije razvijene u PowerApps dati izravno na korištenje.

Microsoft Teams alat za Projektni pristup i timski rad (koji su česti oblici i metode rada). Pet poznatih razina timskog rada „forming, storming, norming, and

performing" ponekad znaju biti dugotrajne i zamorne, no uz Microsoft Teams i Office 365,timovi se vrlo brzo dobro organiziraju i postaju produktivni i efikasni. Uz Microsoft Teams - središnje mjesto u Office365 s kojeg kreće timski rad, jedno mjesto na kojem se nalaze svi dokumenti, s kojeg se pokreće i sprema sva komunikacija, mjesto s kojeg se pozivaju svi članovi tima u virtualni sastanak što olakšava i pojednostavnjuje posao. Volite raditi svoj posao ali niste baš za administraciju? Ne brinite, s jednog mjesta sve je moguće voditi, podijeliti, zajednički raditi, komunicirati, surađivati i spremati. Nema više potrage za izgubljenim obrascima, projektnim izvještajima, tehničkim specifikacijama, komentarima i sl. Odgovor je samo jedan – Microsoft Teams.

ASP.NET Core JavaScriptServices. Angular, React, Knockout, Aurelia, Vue... JavaScript okusi su osvojili stolove suvremenih aplikacija gdje danas uobičajeno ciljaju najviše ocjene. Na predavanju kuhamo sa - skupom tehnologija koje guraju ASP.NET Core na vrh serverskih web okruženja za posluživanje modernih SPA JavaScript aplikacija. JavaScriptServices se sastoje od vrhunskih sastojaka: predrenderiranje na serveru, "hot module replacement", webpack procesi uključeni u razvoj, "cache priming", "lazy loading", generatori, predlošci, integracija klijentskih i serverskih ruta i validacije, pozivi NPM paketa kroz runtime, izvršavanje JavaScript koda na serveru... I pogedjamo kako servirati SPA aplikacije uz pomoć ASP.NET Core JavaScriptServices pomagača.

Alati (engine-a) za razvoj 2D, 3D, i VR igara. Neki alati koje koriste vodeće kompanije u razvoju igara ili nisu dostupni na tržištu, ili su komercijalni no postoje i besplatni ili javno dostupni alati za razvoj igara. Kakve su im funkcionalnosti? S kojim alatom je moguće lakše razvijati igru? Kojim modelom razvoja se koristiti u razvoju igre? To su neka pitanja developer-a pri razvoju igre. Objasniti će se spiralni model i primjena u procesu razvoja igre. Koje funkcionalnosti trebao bi sadržavati alat za razvoj igre. Kakve vrste igara koje se mogu izrađivati pomoću alata. Objasniti će se neki javno dostupni alati za razvoj igara, analiza potrebnih funkcionalnosti za razvoj igre na javno dostupnim alatima. Na istim alatima analizirat će se mogućnost izrade igre spiralnim modelom razvoja.

Riječnik podataka (Data Dictionary D.D.) na RDBMS-u za neku bazu podataka, koja je izrađena iz normaliziranog relacijskog modela podataka, može se koristiti u postupcima generiranja aplikacijskih komponenti za određene osnovne elemente korisničkog sučelja web aplikacije. DD sadrži sve podatke potrebne za konstruiranje modela podataka i aktivne baze podataka pa tako sadrži podatke o tablicama, redovima (vrijednosti - podaci), stupcima (atributima), ključevima, indexima i vanjskim ključevima. Podaci iz DD-a na RDBMS-u mogu se koristiti za potrebe generiranja pripadne web ili desktop aplikacije, odnosno njenih osnovnih funkcionalnosti (izbornik, tabelaran pregled, pojedinačno ažuriranje). Pokazati će se proces transformacije relacijskog modela u niz stablastih struktura. Pokazat će se kako se takva transformacija može koristiti za potrebe izrade izbornika i stablastih tzv. parent/child stranica s listom. Pokazati će se primjer strukture aplikacijskih komponenti temeljen na MVC strukturi s proširenjem View Model pogodne za korištenje u generatoru web aplikacija koji se temelji na čitanju DD-a na bazi podataka

Opasnosti gubitka podataka spremljenih na mobilnim uređajima (mobiteli, tableti i sl) i koje mjere poduzeti kako bi naši podaci bili zaštićeni a organizacija usklađena s GDPR regulativom. Mobilni uređaji danas sadrže velike količine podataka o svojim vlasnicima, a u poslovnom okruženju na njima se često koriste poslovne aplikacije koje sadrže osobne podatke klijenata, zaposlenika i sl.

Enkripcija uređaja - da li je dovoljna za efikasnu zaštitu osobnih i osjetljivih podataka na samom uređaju? Pokazat ćemo kako se podaci i na mobilnim uređajima mogu čuvati u bazama podataka koje mogu biti posebno zaštićene pa podaci ostaju sigurni čak i ako hakeri uspiju provaliti u naš uređaj. Nećemo pokazivati softver, već govoriti o praksi zaštite podataka na mobilnim uređajima a kao primjer ćemo pokazati kako se to može uraditi pomoću vodeće baze podataka u tom segmentu.

Blockchain se danas povezuje uz veliki hype, pogotovo kada se govori o raznim kriptovalutama i ICO-ovima, gdje su pretežita razmišljanja da je BC tehnologija korisna samo za brzu zaradu na raznim kriptovalutama. Cilj ovog predavanja je na racionalni način prikazati tehničku podlogu iza blockchaina, i raspraviti koja zapravo svojstva nudi blockchain. Umjesto navijanja kako će blockchain promijeniti svijet, predavanje će dati neutralan, tehnički pogled na još jedan alat koji nam je na raspolaganju.

3D printanje nije samo ispisivanje materijala u tri osi, već su osnovni principi rada 3D pisača puno kompleksniji. Započinjemo izradom 3D modela koji se pohranjuje u određenome formatu. Spomenuti modeli se konvertiraju u kod čitljiv računalu. Slijedi odabir najprikladnije aditivne metode koji se svodi na vrstu materijala koji se koristi te na tehniku kojom će model biti izrađen. Odabir metode također ovisi i o industriji u kojoj je predviđena njena primjena. Razlikujemo stereolitografiju, selektivno lasersko sinteriranje, modeliranje nanošenjem rastopljenog materijala, laminiranu objektnu proizvodnju, 3D tiskanje i druge

aditivne metode. Opisati ćemo industrijske grane u kojima je primjena aditivnih tehnologija najzastupljenija kao i dostignuća koja su ostvarena.

Internet stvari IoT (Internet of Things) predstavlja mrežu međusobno povezanih uređaja. Tek sada je došlo do porasta primjene ove tehnologije koja povezuje uređaje i fizičke objekte iz okoline u globalnu mrežu temeljenu na IP protokolu velikih brzina. Omogućuje umrežavanje različitih stvari i objekata iz svakodnevnog života te njihovu trenutnu međusobnu komunikaciju putem Interneta, bez ljudske interakcije. Tehnološki napredak i razvoj senzora, aktuatora, skladišta podataka i mrežnih mogućnosti proširuju moguće scenarije primjene Interneta stvari. Objasniti će se cjelokupan scenarij pripreme i korištenja senzora za temperaturu i vlažnost zraka te računala Raspberry Pi, od instalacije operativnog sustava na računalo do izrade programa i provedbe prikupljanja podataka.

Industrija video igara danas predstavlja najrašireniju i najprofitabilniju granu zabavne industrije. Mobilnih uređaji omogućuju dostup i preuzimanje i igranje igračima sa on-line servisa kao što su GooglePlay i AppleStore. Takav pristup pridonio je popularnosti Indie pristupa razvoju igara jer pojedincu omogućuje da uz minimalna ulaganja ostvariti profit. Opisan cjelokupni postupak razvoja Indie igre, od osmišljavanja ideje i razvoja igre u okruženju Unity 3D pa sve do oblikovanja poslovnog plana i plasiranja igre na Google Play trgovinu.

Na radionici ćemo postaviti kompletnu SPA aplikaciju – uključujući i njezin frontend dio i njezin backend dio. Temeljac je ASP.NET Core i njegovi JavaScript services. A Angular frontend ćemo razvijati na tom osnovno postavljenom projektu. Kroz izradu aplikacije proći ćemo od kreiranja projekta, postavljanja okoline i osnovnih koncepata. U radionici ćemo iskoristi iskoristit ćemo koncepte i dobre prakse i kreirati gotovu aplikaciju. Tako da naučeno primijenite odmah na projektima koji vas čekaju iza ugla!

Podaci o autoru:

Ante Polonijo, dipl.ing., dipl.oec. Tajnik konferencije (svih 26 godina) CASE d.o.o., Antuna Barca 12, 51000 Rijeka tel. +385 51 217 875, fax. +385 51 218 043 e-mail: ante@case.hr

PROFESIONALNA KARIJERA:

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

CASE2018 7

GOTOVI ERP ILI RAZVOJ VLASTITOG RJEŠENJA OD POČETKA? POSTOJI MEĐU-RJEŠENJE

dr. sc. Igor Nazor, mr. sc. Karmen Klarin

SAŽETAK

Manja i srednja poduzeća se danas u pravilu odlučuju za nabavu gotovih ERP (engl. commercial off-the-shelf - COTS) sustava koje implementator u potrebnoj mjeri prilagođuje njihovim potrebama uz čestu potrebu za integracijom dvaju ili više rješenja (primjerice, kada je, pored poslovnih procesa, potrebno informatizirati složen proces upravljanja dokumentacijom).

Kod uvođenja gotovih, "paketskih" rješenja, preporučljivo je da se poslovni procesi poduzeća u što većoj mjeri prilagode procesima koji su već implementirani u programskom rješenju, kako bi potrebne izmjene bile što manjeg opsega. Ovaj pristup je najčešće prihvatljiv za poduzeća koja se bave "tipičnim" djelatnostima (primjerice, maloprodaja ili jednostavna proizvodnja) i ERP rješenja su već implementirana u velikom broju sličnih poduzeća. Međutim, poduzeća koja se bave manje "tipičnim" djelatnostima (primjerice, lokalna samouprava, pružatelji telekomunikacijskih usluga, distributeri energije ili komunalna poduzeća) nemaju veliku korist od gotovih rješenja, te se češće odlučuju za izradu vlastitih rješenja ili integraciju više različitih sustava. Razvoj programskog rješenja za potrebe jednog poduzeća je u pravilu skupo i dugotrajno rješenje, a integracija više različitih podsustava nužno dovodi do kompleksnosti krajnjeg rješenja te otežanog korištenja, razvoja i održavanja.

U ovom radu se predlaže alternativa razvoju vlastitog rješenja od početka, ali uz veliku fleksibilnost pri definiranju specifičnih poslovnih procesa.

SUMMARY

Today's SME's generally decide to purchase commercial off-the-shelf (COTS) ERP systems which are then customized for their specific needs and often requiring integration of two or more specialized systems (for example, when there is need for a complex process of document flow which is not supported by the COTS system).

In order to minimize modifications to the COTS system during implementation it is suggested that the client adjusts their business processes in line with the processes already implemented in the COTS system. This approach is viable for companies in "typical" industry branches (such as retail or simple manufacturing) where there already exist many similar implementations, and industry's best practices are incorporated in existing COTS systems.

On the other side, implementing COTS systems in enterprises in less "typical" industry branches (such as local government agencies, telecom operators, energy distributors or utilities) may require too many modifications to be viable. Such companies usually decide to develop proprietary systems and possibly partially integrate them with existing specialized applications. Custom development is essentially time and resource consuming and integrating different systems often leads to a complex final solution resulting in difficult usage, development and maintenance.

In this paper we propose an alternative approach to developing a custom solution from scratch, while maintaing full flexibility at defining specific business processes.

1. UVOD

U ovom radu je opisan prijedlog načina razvoja ERP sustava unutar postojećeg COTS sustava uz korištenje minimalnog broja ugrađenih funkcionalnosti. Koncept je osmišljen i provjeren tijekom projekta izrade specifikacije korisničkih zahtjeva za jedno komunalno poduzeće srednje veličine sa svrhom objave javnog natječaja za odabir ponuđača programskog rješenja.

Analiza dobivene specifikacije korisničkih zahtjeva je pokazala da zbog širokog kruga djelatnosti poduzeća ne postoji jedno gotovo programsko rješenje koje može zadovoljiti većinu zahtjeva korisnika, već da će se do rješenja morati doći na jedan od sljedećih načina: 1) integracijom većeg broja gotovih rješenja; 2) značajnim izmjenama na nekom od gotovih rješenja; 3) razvojem vlastitog programskog rješenja.

Kako su područja interesa autora ovog rada razvoj i implementacija poslovnih informacijskih sustava, kako na različitim COTS platformama tako i vlastitih rješenja, izrada specifikacije korisničkih zahtjeva je iskorištena za izradu prototipa traženog informacijskog sustava.

U svrhu izrade prototipa razmatrane su dvije opcije: nadogradnja postojećeg COTS-a i razvoja vlastitog programskog rješenja.

Tijekom razmatranja odgovarajućih kandidata među COTS sustavima, uz funkcionalnosti koje podržavaju, analizirana su i njihova razvojna okruženja kao i u kojoj mjeri ispunjavaju različite nefunkcionalne zahtjeve (primjerice, upotrebljivost

8 CASE2018

korisničkog sučelja, interoperabilnost, sigurnost ili nadogradivost). Analizirani su poslovni informacijski sustavi Microsoft Dynamics NAV i Odoo. Rezultati analize su prednost dali sustavu Odoo koji je iskorišten za izradu prototipa programskog rješenja.

Odlučeno je da će se prototip programskog rješenja izraditi na novi način, tako da se od odabranog COTS sustava iskoriste dijelovi koji pokrivaju nefunkcionalne zahtjeve, a podrška funkcionalnim zahtjevima se razvija od početka.

Izrada prototipa programskog rješenja je trajala oko dva mjeseca i razvijena je većina traženih funkcionalnosti te se pristup može smatrati uspješnim.

2. IZRADA VLASTITOG ILI KORIŠTENJE GOTOVOG PROGRAMSKOG RJEŠENJA

Važna odluka koju poduzeće mora donijeti prije početka informatizacije je hoće li razvijati vlastito programsko rješenje ili će koristiti neko od COTS rješenja (engl. build or buy dilemma).

Neke od prednosti razvoja vlastitog programskog rješenja su:

velika mogućnost prilagodbe vlastitim poslovnim procesima, što je posebno važno poduzećima s velikim brojem zaposlenih ili složenom organizacijskom strukturom,

znanje o važnim poslovnim procesima, zbog kojih poduzeće možda ostvaruje konkurentnu prednost, ostaje sačuvano od konkurencije.

Važniji nedostaci razvoja vlastitog programskog rješenja su:

visoka ukupna cijena projekta, dugo vrijeme potrebno za završavanje projekta, velika ovisnost o kompetencijama razvojnog tima, uz veći dugoročni rizik od nastanka problema pri održavanju i

izmjenama takvog programskog rješenja.

Alternativa razvoju vlastitog programskog rješenja je korištenje COTS sustava, potpuno funkcionalnih programskih paketa za čije je korištenje potrebno početno parametriranje. U njima je implementiran velik broj funkcionalnosti koje često uključuju više različitih načina obavljanja nekog poslovnog procesa. Naručitelj ima određenu slobodu biranja načina na koji će izvršavati pojedine poslovne procese, međutim u konačnici se očekuje da se u što većoj mjeri prilagodi poslovnim procesima koji su već implementirani programskom rješenju [1]. Ovakav pristup omogućuje značajno niži trošak implementacije, a kako su kvalitetni COTS sustavi razvijeni na temelju iskustva s velikim brojem korisnika, implementiraju poslovne procese na način koji se je pokazao efikasnim kod velikog broja već postojećih implementacija, pa se mogu smatrati preporučljivim načinima odvijanja posla (engl. best practices). Prednosti COTS rješenja su još i implementiran sigurnosni model uz upravljanje korisničkim pravima, unificirano korisničko sučelje, alati za kreiranje izvještaja, mogućnost uvoza i izvoza podataka, najmanje osnovne mogućnosti upravljanja dokumentima (dodavanje priloga bilo kojem entitetu iz poslovanja), barem osnovni skup alata za prikaz podataka (liste, filtriranje, grupiranje), izvještajni alati (graficki prikaz, visedimenzijska analiza), što rezultira značajno kraćim ciklus razvoja i implementacije od razvoja vlastitog programskog rješenja.

Nedostatak korištenja COTS rješenja je nemogućnost utjecaja korisnika na značajnije izmjene dobivenih funkcionalnosti, što često rezultira nezadovoljstvom. Mogućnost izmjene ili dorade uvelike ovisi o programskoj platformi koja se koristi. Veće izmjene postojećih funkcionalnosti zahtijevaju dodatni rad isporučitelja programskog rješenja, što može značajno povećati ukupnu cijenu projekta. Ukoliko se naknadne dorade na COTS rješenju vrše nekontrolirano ili nestručno mogu biti narušeni koncepti na kojima se zasniva izvorno rješenje, što povećava rizik od pogreški u radu. Otežana je i nadogradnja tako izmijenjenog programskog rješenja na noviju verziju, a smanjena je i mogućnost podrške proizvođača u slučaju nastanka pogrešaka u radu.

Današnja COTS rješenja su, pokušavajući pokriti što veći broj funkcionalnosti, postala glomazna i složena za konfiguriranje. Integracija takvog rješenja s drugim aplikacijama u poduzeću ili s gotovim rješenjima drugih proizvođača, primjerice CRM, može biti skupa, dugotrajna i često s neizvjesnim ishodom [2].

COTS sustavi se međusobno razlikuju prema mogućnostima koje su ostavljene implementatorima za unaprjeđenje postojećih funkcionalnosti i razvoj novih. Sustavi nižeg cjenovnog ranga namijenjeni manjim poduzećima imaju strože definirane poslovne procese i manju mogućnost prilagodbe potrebama korisnika. Sustavi namijenjeni zahtjevnijim korisnicima imaju kvalitetnije razvojno okruženje i veće mogućnosti prilagodbe pojedinačnom korisniku.

3. IMPLEMENTACIJA GOTOVOG RJEŠENJA UZ VELIKE IZMJENE POSTOJEĆIH FUNKCIONALNOSTI

Ako se procesi u poduzeću u velikoj mjeri razlikuju od onih koji su podržani COTS rješenjem, izrada velikog broja dodataka koji su kvalitetno povezani s postojećim funkcionalnostima može biti kompleksna. Gotova programska rješenja u pravilu imaju iznimno kompleksan model podataka koji se sastoji od više stotina ili čak tisuća tablica, koje mogu imati i više od sto atributa. Primjerice, uobičajena instalacija sustava Microsoft Dynamics NAV ima više od 1.100 tablica, oko 1.950 ekranskih formi i oko 960 izvještaja, dok jedna o kompleksnijih tablica (Zaglavlje prodaje) ima 201 atribut. Kod poslovnog sustava Odoo uobičajeni broj tablica je između 350 i 600.

Nadalje, u situacijama kada je potrebna integracija ERP sustava sa specijaliziranim sustavom, primjerice s aplikacijom za upravljanje dokumentacijom, problem je što to najčešće rade različiti implementatori i komunikacija među njima može biti zahtjevna, ako njihova rješenja nisu predviđena za međusobnu komunikaciju.

Programsko rješenje dobiveno integracijom često ima različita korisnička sučelja, donekle različite filozofije rada, a buduće dorade mogu zahtijevati koordinaciju dvaju ili više vanjskih partnera, često uz nejasnu podjelu zadataka i odgovornosti.

CASE2018 9

Klasična podjela zahtjeva koje poslovni informacijski sustav mora ispuniti je na funkcionalne i nefunkcionalne [3], [4], [5]. Funkcionalni opisuju poslovne procese u poduzeću koji se informatiziraju, dokumente i izvještaje koje informacijski sustav generira. Nefunkcionalni uključuju one koji nisu izravno povezani s poslovnim procesima u poduzeću, ali imaju utjecaj na korštenje sustava. Primjeri nefunkcionalnih zahtjeva koji bi morali biti podržani kvalitetnim ERP sustavom su:

autorizacija pristupa korisnika sustavu, upravljanje ovlastima pristupa sustavu i podacima u njemu, intuitivno sučelje za unos podataka u sustav, kvalitetni alati za analizu i prikaz podataka, generiranje izvještaja, višedimenzijsku analizu i grafički prikaz, alati za uvoz i izvoz podataka, upravljanje tokom dokumentacije, upravljanje tijekom poslovnih procesa, funkcionalnosti koje omogućuju slanje dokumenata i obavijesti iz sustava e-mailom i komunikaciju među korisnicima

sustava.

U današnje vrijeme se neki od nabrojanih nefunkcionalnih zahtjeva često mijenjaju zbog vanjskih utjecaja kao što su: napredak tehnologije prikaza informacija, potrebe za integracijom s javnim uslugama (primjerice, autentifikacija korisnika pomoću računa na Googleu ili Facebooku), integracija s društvenim mrežama ili obaveza komunikacije s nekim javnim servisima (on-line plaćanja, predaja poreznih izvješća i sl.).

4. RAZVOJ VLASTITOG RJEŠENJA KORIŠTENJEM OKVIRA ZA IMPLEMENTACIJU POSLOVNIH PROCESA

U ovom radu je opisan pristup razvoju programskog rješenja koji se može smatrati hibridom između korištenja COTS sustava i razvoja vlastitog programskog rješenja. Namjera je iskoristiti prednosti obaju pristupa: što više ubrzati projekt razvoja uz zadržavanje što veće fleksibilnosti koja postoji kod razvoja vlastitog rješenja. Cilj je pronaći alat koje ima kvalitetno implementiranu podršku svim prethodno navedenim nefunkcionalnim zahtjevima, uz razvojno okruženje koje omogućuje jednostavno modeliranje podataka, definiranje korisničkog sučelja, definiranje i održavanje sigurnosnog modela, izradu izvještaja s različitim načinima prikaza podataka te izmjenu podataka s okruženjem (lokalnim aplikacijama i alatima i javnim servisima).

Očekivane koristi od ovakvog pristupa razvoju su:

nastanak unificiranog rješenja koje je prilagođeno poslovnim procesima u poduzeću, kako se sustav već zasniva na provjerenom okviru koji u startu predstavlja funkcionalnu aplikaciju pojednostavljen je

razvoj i testiranje funkcionalnosti, krajnji rezultat je sustav koji objedinjuje sve funkcionalnosti poduzeća što olakšava kasnije dorade i proširenja, te očekivano trajanje razvoja je znatno kraće od trajanja razvoja vlastitog programskog rješenja.

Važno je napomenuti da ovakav pristup stavlja znatnu odgovornost na onoga tko dokumentira postojeće stanje i specificira poslovne procese koji se trebaju informatizirati, jer u sustavu ne postoji pretpostavljeni način odvijanja procesa, koji olakšava razvoj kod gotovih rješenja. U praksi tvrtke često angažiraju implementatore programskih rješenja za izradu specifikacije korisničkih zahtjeva, što je razumljivo zbog znanja i kompetencija koje implementatori poslovnih sustava posjeduju. Međutim, često se događa da rezultat bude dokument koji ne opisuje poslovanje dovoljno precizno, već mu je glavna svrha da sugerira nabavu programskog rješenja koje pojedini implementator nudi. Kvalitetna specifikacija korisničkih zahtjeva sadrži opis svih poslovnih procesa koji se odvijaju u poduzeću s pripadajućim scenarijima, sudionicima i međusobnim vezama, opis svih entiteta s atributima i međusobnim vezama te dokumente i izvještaje koje informacijski sustav mora generirati.

Iako je očekivano trajanje projekta implementacije kraće od razvoja vlastitog rješenja, i dalje se radi o znatno kompleksnijem projektu nego što bi bila tipična implementacija odgovarajućeg COTS sustava.

5. OCJENA PRIKLADNOSTI COTS SUSTAVA KAO OKVIRA ZA IMPLEMENTACIJU POSLOVNIH PROCESA

Programska rješenja koja mogu poslužiti kao okvir za implementaciju poslovnih procesa su zreli COTS sustavi koji u sebi imaju ugrađene napredne mogućnosti razvoja dodatnih funkcionalnosti. Obzirom na razinu kompleksnosti, cijenu i veličinu poduzeća kojima su namijenjeni, primjeri kvalitetnih COTS alata su: SAP koji je namijenjen najvećim poduzećima [6], Microsoft Dynamics NAV namijenjen manjim i srednjim poduzećima [7] i Odoo namijenjen manjim poduzećima [8].

Zbog prehodnog iskustva autora duljeg od desetljeća sa sustavom Microsoft Dynamics NAV i petogodišnjeg iskustva sa sustavom Odoo, istražena je njihova prikladnost kao okvira za implementaciju poslovnih procesa.

Analizirane i uspoređene su verzija 8 Odooa i verzija 5 Microsoft Dynamics NAV-a.* Kod uspoređivanja sustava (Tablica

1.) procijenjeno je vrijeme potrebno za razvoj pojedinih funkcionalnosti sustava. Ocjene su:

A. potrebno je kratko vrijeme uz korištenje za to predviđenih alata B. potrebno je prihvatljivo dugo vremena uz potrebna naprednija znanja C. razvoj je dugotrajan ili zahtijeva implementaciju dodatnih alata

* Trenutna verzija Odooa je 10 koja donosi modernije korisničko sušelje i izmijenjene funkcije sustava, i Microsoft Dynamics NAV 2018,

koja je značajno grafički unaprjeđena i modernizirana uz velik izbor novih načina prikaza podataka.

10 CASE2018

Tablica 1: Procjena vremena implementacije funkcionalnosti korištenjem različitih COTS sustava

Opis funkcionalnosti Microsoft Dynamics NAV Odoo

Izrada osnovnih unosnih maski Dodavanje elemenata unosnih maski korištenjem Object Designera i

grafičkog sučelja. ‑ A

Unosne maske se izrađuju pomoću proširenog HTML koda. Zahtjeva se

poznavanja osnova HTML-a. ‑ B

Izmjena izgleda korisničkog sučelja, kreiranje novih UI elemenata, integracija s drugim aplikacijama i servisima

Nije predviđena mogućnost izrade novih UI elemenata izvan mogućnosti koje nudi izmjena svojstva postojećih i povezivanje programskog koda s događajima (okidači) - C

Uz napredno korištenje weba i izmjenu funkcionalnosti klijentsjke aplikacije moguće je postići velik broj izmjena. ‑ B

Definiranje novog entiteta i atributa te njegovo povezivanje s ostalim entitetima. Izrada osnovnih lista za pregled, prikaz i filtriranje podataka

Kreiranje entiteta i izrada lista su podržani Object Designerom. Sustav automatski nudi filtriranje i sortiranje podataka prema unaprijed definiranim indeksima ‑ A

Entiteti se definiraju izradom novog modula i njegovim instaliranjem u sustav. Liste, filtriranje i grupiranje podataka su podržani sustavomi definiraju se pomoću XML-a. ‑ B

Napredno izvještavanje, grupiranje i filtriranje, analiza po više dimenzija, izrada unakrsnih pregleda

Grupiranje podataka je moguće definiranjem posebnih indeksa, višedimenzijska analiza i unakrsni pregledi su omogućeni primjenom

Dimenzija ‑ A

Sustav podržava unakrsno prikazivanje podataka, višedimenzijsku analizu i grafički prikaz. Pregledi se definiraju pomoću XML-a. ‑ B

Grafički prikaz podataka Nije omogućen u uspoređivanoj verziji bez dodatnih alata. ‑ C

Sustav podržava nekoliko načina grafičkog prikaza podataka. Grafički prikazi se definiraju pomoću proširenog

HTML-a. ‑ A

Implementacija jednostavne poslovne logike, provjera valjanosti unosa pokretanje radnji ovisno o događajima

Na elementima grafičkog sučelja su definirani događaji kojima je moguće dodati programski kod za

implementaciju poslovne logike ‑ A

Osnovni događaji na elementima korisničkog sučelja su podržani proširenim HTML-om. ‑ B

Objektno programiranje, korištenje naprednih struktura podataka

Kako se radi o starom programskom jeziku kod kojeg je objektni pristup simuliran dodavanjem objekata ORM-a, GUI-a i sl, ne mogu se slobodno definirati nove klase. ‑ C

Kako je podloga programski jezik Python, na raspolaganju su sve dodatne biblioteke i sve mogućnosti programskog

jezika. ‑ A

Sigurnosni model, definiranje uloga i prava pristupa podacima

Definicija grupa pristupa, uloga i prava pristupa pojedinačnim entitetima je

podržana sustavom. ‑ A

Definicija grupa pristupa, uloga i prava pristupa pojedinačnim entitetima je

podržana sustavom. ‑ A

Definiranje prava pristupa objektima, funkcionalnostima i izbornicima

Podržano sustavom uz jednostavno konfiguriranje. ‑ A

Prava pristupa izbornicima su indirektno definirana pravima pristupa modelu. ‑ B

Kreiranje strukture izbornika Podržano grafičkim sučeljem u Object Designeru ‑ A

Definira se proširenim XML-om. ‑ A

Iz dobivenih rezultata zaključuje se da sustav Microsoft Dynamics NAV ima zrelije razvojno sučelje koje nudi relativno širok spektar mogućnosti. Međutim, mogućnosti koje nisu direktno podržane razvojnim alatom je iznimno teško realizirati. Sustav Odoo čak i za razvoj jednostavnih funkcionalnosti zahtijeva određeno različitih programskih tehnika (napredno programiranje u pythonu, html, css, xml predlošci). Međutim, kako je sustav zasnovan na poznatim tehnologijama moguće je realizirati i kompleksnije funkcionalnosti.

6. STUDIJA SLUČAJA - KOMUNALNO PODUZEĆE SREDNJE VELIČINE

Ovaj rad je nastao na temelju projekta autora za izradu specifikacije korisničkih zahtjeva u jednom komunalnom poduzeću. Poduzeće ima oko 200 zaposlenih, 40.000 komunalnih korisnika i, osim glavne djelatnosti crpljenja i distribucije vode, bavi se građevinskim radovima izrade priključaka i vodovodne mreže, kao i brigom o zdravstvenoj ispravnosti vode. Značajan dio posla obuhvaćaju i popratne djelatnosti izrade popratne dokumentacije i interakcije s korisnicima i državnim tijelima.

CASE2018 11

Izrada dokumenta je uključila razgovore s predstavnicima 34 organizacijske jedinice. Informacije su prikupljene od 38 djelatnika, a projekt je trajao tri mjeseca. Nakon analize identificirana su 22 glavna tipa dokumenta i 55 podtipova (što ne uključuje izvještaje i financijske dokumente). Identificirano je 70 radnji nad dokumentima koje je potrebno pratiti u sustavu. Na temelju specifikacije korisničkih zahtjeva nastao je prijedlog natječajne dokumentacije čiji tehnički dio sadrži 38 obaveznih zahtjeva i 252 tražene funkcionalnosti.

Na temelju specifikacije korisničkih zahtjeva je vidljivo da ne postoji jedno gotovo rješenje koje može zadovoljiti sve potrebe korisnika. pokrenut je interni projekt razvoja prototipa poslovnog sustava koji je u skladu sa zahtjevima navedenim u dokumentu. Kako je navedeno u rezultatima analize, kao okvir za implementaciju poslovnih procesa odabran je sustav Odoo. Na projektu razvoja prototipa su, pored konzultanta koji je sudjelovao u izradi specifikacije, sudjelovala dva programera.

Tijekom razvoja generirano je ili modificirano 75 entiteta, 65 ekranskih obrazaca i 33 izvještaja. Jedna od "funkcionalnosti okvira" koja je značajnije izmijenjena je način pokretanja akcija kod upravljanja tijekom poslovnih procesa, što je omogućilo kvalitetnije praćenje i prikaz statistike aktivnosti na dokumentima.

Važno je napomenuti da je prototip rješenja razvijen i testiran interno i da nije implementiran u komunalnom poduzeću, te stoga ne postoje točne informacije o njegovoj pravoj efikasnosti.

7. ZAKLJUČAK

Opisana metoda je primjenjiva u specifičnoj situaciji kada poduzeće koje se informatizira ima kompleksne i netipične procese, koje nije moguće obuhvatiti jednim gotovim rješenjem, i kada postoji iznimno kvalitetan i neutralan dokument specifikacije korisničkih zahtjeva.

Kao unaprjeđenje "funkcionalno praznog" okvira za implementaciju poslovnih procesa može se razmatrati korištenje osnovnih entiteta koji su svakako nužni u bilo kojem poduzeću, kao što su partner, zaposlenik, lokacija ili proizvod/usluga. Pritom je potrebno naći ravnotežu između pojednostavljenog razvoja, u slučaju da je dio entiteta i pripadajućih funkcionalnosti već implementiran, i poteškoća s integriranjem novih funkcionalnosti u postojeće, zbog čega je i odabran ovdje opisan pristup umjesto implementacije i mijenjanja COTS sustava.

Literatura:

1 Hallikainen P., Laukkanen S., Sarpola S., «Reasons for ERP Acquisition», Proceedings of the 6th International Conference on Enterprise Information Systems, 2004

2 Chorafas D.N., «Integrating ERP, CRM, supply chain management, and smart materials», CRC Press, SAD, 2001, ISBN: 0-8493-1076-8,

3 Sen C.G. et al., An integrated decision support system dealing with qualitative and quantitative objectives for enterprise software selection, Expert Systems with Applications, Vol. 36, 2009

4 Wu J., Shin S., A methodology for ERP misfit analysis, Journal of Information and Management, Vol. 44, 2007

5 Colom G.G., An i-based Reengineering Framework for Requirements Engineering, doktorska disertacija, Universitat Politechnica de Catalunya, Španjolska

6 SAP Development platform, https://www.sap.com/developer.html, preuzeto 1.2.2018

7 Introduction to Microsoft Dynamics NAV 5.0, Training materials, 2007, preuzeto 1.2.2018

8 OpenErp Technical Memento, https://www.odoo.com/files/memento/older_versions/Open ERP _Technical_Memento_v0.6.5_A4_draft.pdf,, preuzeto 1.2.2018

Podaci o autorima:

dr. sc. Igor Nazor Viši predavač e-mail: igor.nazor@oss.unist.hr Rođen 1972 u Splitu. 2014. godine doktorirao na FER-u u Zagrebu. Zaposlen je na Odjelu za stručne studije Sveučilišta u Splitu kao viši predavač. Kolegiji koje predaje, predavao ih je ili održava vježbe: Analiza i obrada podataka, Informatizacija proizvodnje, Informatizacija i upravljanje proizvodnjom, Sustavi za upravljanje resursima poduzeća, Informacijski sustavi, Projektiranje informacijskih sustava, Elektroničko poslovanje i Baze podataka. U periodu 2007 – 2013 angažiran je kao voditelj nekoliko projekata informatizacije malih i srednjih poduzeća. Tijekom karijere radio je na radnim mjestima koja uključuju: voditelj prodaje i marketinga, voditelj mreže distributera u hrvatskim poduzećima i predstavništvima stranih poduzeća u Hrvatskoj. mr. sc. Karmen Klarin Pomoćnica pročelnika Odsjeka za IT e-mail: karmen.klarin@oss.unist.hr Sveučilišni odjel za stručne studije Sveučilišta u Splitu Kopilica 5, 21000 Split

12 CASE2018

CASE2018 13

PROFESIONALNI PROGRAMER ZNANJA, STAVOVI I ZABLUDE

Matija Novak, Dragutin Kermek

SAŽETAK

Programiranje je ozbiljan posao te mu tako treba i pristupiti. Nažalost, većinom "profesionalni" programeri nisu profesionalni. U ovom predavanju prikazati će se što čini profesionalnog programera, te zašto je fraza "Bitno da radi!" problem. Koji su stavovi koje profesionalni programer mora imati, koja znanja mora imati osim generalnog poznavanja programskog jezika te koje su najveće zablude "profesionalnih" programera.

ABSTRACT

Programming is a serious job and one should approach it that way. Unfortunately, most “professional” programmers are not professional. In this lecture it is presented what makes a professional programmer, and why the phrase “It's only important that it works!” is a problem. What are the attitudes which a professional programmer must have, what knowledge must a professional have except from generic knowledge of programming language and what are the biggest misleads of “professional” programmers.

1. UVOD

Programiranje je ozbiljan posao te mu tako treba i pristupiti. Stoga programiranje bi trebao obavljati profesionalni programer. Riječ profesionalan može imati višestruko značenje. Prema [1] riječ profesionalan znači: „1. koji se odnosi na profesiju i na profesionalce [profesionalni političar]; 2. koji je nastao kao posljedica profesije [profesionalna bolest]; 3. razgovorno: koji je temeljit, dosljedan, dobar u poslu [profesionalan pristup poslu]“. U ovom radu kada kažemo profesionalan programer mislimo na osobu koja je programiranje odabrala kao svoju profesiju (definicija 1), ali samo ako ta osoba ima profesionalan pristup poslu (definicija 3).

Nažalost, prema našem iskustvu često profesionalni (definicija 1) programeri nisu profesionalni (definicija 3). Kako bi zadovoljili obje definicije profesionalni programeri moraju posjedovati određena znanja i vještine i moraju imati ispravan stav prema poslu. Postavlja se pitanje koja su to znanja i vještine koja jedan profesionalni programer mora imati i što znači imati ispravan stav (koji uključuje i navike).

Postoji cijeli skup znanja i vještina koja mora imati profesionalni programer, uz temeljno znanje i vještinu programiranja (tj. poznavanje programskih jezika, struktura podataka, modeliranja, razvojnih alata, …). U ovom radu prikazana su neka od tih znanja i vještina za koja smatramo da su važna i da bi ih svaki programer morao imati, no ona nisu jedina i moguće je da u nekim specifičnim situacijama su neka druga znanja i vještine važnija. Naravno znanja i vještine čine samo jednu stranu medalje, s druge su strane stavovi koje profesionalni programer mora imati.

Kako bi se objasnilo što znači imati ispravan stav dan je skup primjera koji govore što smatramo ispravnim stavom, ali i primjeri koji opisuju neispravan stav tj. zablude koje se smatraju ispravnima dok to uglavnom nisu. Potrebno je napomenuti da fraza ispravan stav ne znači jedini ispravan stav, vrlo je moguće da ponekad postoji više ispravnih stavova. Također „ispravnost“ stava ovisi o situaciji, pa tako na primjer zauzeti negativan stav može ponekad biti ispravno, a ponekad neispravno.

Ostatak rada strukturiran je kako slijedi. Poglavlje 2 opisuje neke zablude programera, u poglavlje 3 opisana su važna znanja i vještine za profesionalnog programera. U poglavlju 4 se govori o nekim stavovima profesionalnog programera, a poglavlje 5 daje zaključak.

2. ZABLUDE

Prije nego krenemo opisivati znanja, vještine i stavove koje programer mora imati opisali bi smo nekoliko zabluda na koje smo naišli.

2.1 Bitno da radi

Kada radimo kao programer u nekoj tvrtki najčešće nismo jedini programer i dosta često se tada može čuti fraza „Bitno da radi!“, posebice kada su rokovi kratki. Ova fraza može se ubaciti u različiti kontekst „Nije bitan dizajn, bitno da radi“, „Nije bitna arhitektura, bitno da radi“, „Nije bitno kako testiraš, bitno da radi“, „Nema veze ako kopiraš kod, bitno da radi“, itd.

U kontekstu programera ona se uglavnom odnosi na testove, arhitekturu, refaktoriranje, čistoću koga i sl., ukratko stvari koje čine kod lakšim za održavanje. Kada govorimo o tzv. „profesionalnim“ programerima onda je ovo jedna od najvećih

14 CASE2018

zabluda. Zbog kratkih rokova i pritiska menadžmenta programeri nemaju vremena pa onda odbacuju automatske testove, refaktoriranje koda, unaprjeđenje arhitekture i sl. jer smatraju da će tako uštedjeti vrijeme.

Ovaj stav osuđuje svaki projekt na propast u dugoročnom pogledu. Kako projekt raste kod postaje sve složeniji. Kod je sve složeniji zbog novih funkcionalnosti, ali ponajviše zbog neodržavanja. Kod koji je složeniji sve ga je teže mijenjati i dodavati nove funkcionalnosti. Programeri kako nemaju testove sve se više boje mijenjati takav kod, što dovodi da ga mijenjaju samo zato što moraju. Naravno mijenjati kod koji je složen i bez testova daje veću vjerojatnost da će se napraviti pogreška, koja se najčešće nalazi u dijelu na kojem trenutno NE radimo. Zbog toga greška obično ne bude prepoznata dok sustav ne ode u produkciju. Što naravno dovodi do novih izmjena kada se greška otkrije i tako u nedogled dok sve ne postane toliko isprepletano da se mora krenuti ispočetka. Kako se za novu verziju opet nema vremena za poboljšanja, priča se ponavlja u krug.

Kako bi izbjegli ovakav scenarij profesionalni programer je dužan odražavati kod kako on ne bi postao presložen za izmjenu. Kako programeri najčešće nemaju vremena za održavanje u smislu poboljšanja kvalitete koda (kao što je opisano kasnije u tekstu), programer je dužan kontinuirano u toku programiranja poboljšavati kod i time ograničavati složenost. Stoga, napisati kod koji radi samo je prvi korak. Prema nekim izvorima [2] Kent Beck je autor izjave: „Prvo napravi da radi, zatim napravi ispravno i nakon toga optimiziraj“.

Sličan savjet krije se i u Martin Fowler-ovoj izjavi koja kaže [3]: „Svaka budala može napisati kod koji računalo razumije. Dobri programeri pišu kod koji čovjek razumije.“. Naime da bi programer razumio kod on mora biti jednostavan za čitanje. A to postaje jedino kroz dobru arhitekturu i pisanjem čitljivog koda.

2.2 Ako oni tako kažu neka tako bude

Opće je poznato da se programeri i menadžeri ne vole previše. Svaki od njih živi u svom svijetu pa dolazi do određenih neslaganja. Kako su menadžeri obično vlasnici tvrtki oni plaćaju programere, a ne obratno. Pa tako kad dođe do neslaganja, najčešće u načinu kako aplikacija mora raditi, zna se čuti izjava „ako oni tako kažu neka tako bude“ od strane programera.

Ova izjava vrlo je neprofesionalna i često se radi pasivnoj agresiji. Programer je u toj situaciji svjestan određenog problema, ali slabo ili uopće ne pokušava spriječiti svog nadređenog da se neka stvar izmjeni i time spriječe problemi u budućnosti. Profesionalni programer dužan je, kada je svjestan problema, upozoriti svoje nadređene i ako treba odbiti raditi posao. Također profesionalni programer treba znati reći NE. U [4] opisani su na zanimljiv način neke situacije kada i kako treba reći ne i kada treba reći da.

Odbijanje posla bila bi ispravna odluka kada se radi na primjer o stvarima koje su ilegalne. Programeri su mišljenja da ako poslodavac nešto od njih traži da su dužni tako postupiti ako on inzistira, što je svakako pogrešno. Osim toga, smatraju iako je neka stvar ilegalna da ne mogu biti kažnjeni već da će samo tvrtka biti kažnjena ako se sazna.

No vremena se mijenjaju pa tako je programer James Liang [5], [6] dobio 40 mjeseci zatvora i $200.000 dolara kazne jer je napisao je dio u softveru koji je varao na mjerenjima ispušnih plinova Volkswagen automobila. Ova činjenica trebala bi probuditi programere da shvate da i oni ako svjesno čine prekršaj također su krivi zajedno sa svojim nadređenim pa i poslodavcem.

Nakon ovog primjera javlja se pitanje tko je kriv ukoliko softver zbog greške u kodu u najekstremnijem slučaju ubije čovjeka? Da li bi programer u slučaju da ga se može prozvati krivim za ubojstvo bio spreman samo tako izbaciti testiranje jer to traži od njega poslodavac? Na ova pitanja ne možemo dati odgovor no mišljenja smo da bi programeri trebali u svojim odlukama postupati kao da je život u pitanju iako to (na svu sreću) najčešće nije slučaj.

2.3 Zadovoljavanje trenutnih zahtjeva

U poglavlju „Bitno da radi“ indirektno je prikazana još jedna zabluda programera. Programeri koji odbacuju testove i sl. kako bi uštedjeli vrijeme pokazuju da im je najbitnije da zadovolje trenutne zahtjeve korisnika. Međutim posao svakog programera primarno nije pisanje programa za zadovoljavanje trenutnih zahtjeva. Da ne bi bilo zabune zadovoljavanje dokumentiranih korisničkih zahtjeva jest postao programera, ali dolazi tek na drugom mjestu.

Vrlo je logično pitati što može biti važnije od zadovoljavanje korisničkih zahtjeva. Robert C. Martin u jednom od svojih videa (Video 9 – The single responsibility principle) [2] kaže da je primarna vrijednost softvera da bude fleksibilan kako bi mogao zadovoljiti buduće zahtjeve, sekundarna vrijednost softvera je da zadovoljava trenutne korisničke zahtjeve. Upravo je to odgovor na pitanje, glavna zadaća programera je da održava program u takvom stanju da ga je uvijek moguće što lakše mijenjati i dodavati nove funkcionalnosti, a tek onda da zadovolji trenutne korisničke zahtjeve. Program koji nije moguće mijenjati, jako brzo gubi na vrijednosti.

Ako ovo stavimo u čisto teoretski kontekst da li je bolje imati program koji je toliko krut da ne možemo ništa promijeniti, ali sto posto radi ono što trenutno traži korisnik ili je bolje imati program koji ne radi uopće ono što korisnik treba, ali se sa par promjena može dobiti da mu zadovoljava potrebe? [2]

2.4 Kodiranje je trivijalan dio

U knjizi The Pragmatic Programer autori sarkastično kažu [7]: „Konvencionalna mudrost kaže da kad je projekt jednom u fazi kodiranja rad je uglavnom mehanički, prepisivanje dizajna u izvršne izjave.“ Dok ovi autori to govore sarkastično, ovo je nažalost mišljenje mnogih menadžera. No ne može im se previše zamjeriti jer ipak nisu oni programeri i nisu često tehnički stručni.

No zašto ovo navodimo u radu koji opisuje zablude programera? Odgovor je jednostavan jer programeri su svjesni da njihovi menadžeri tako misle, ali ne čine ništa ili premalo da to promjene. Zabluda leži u tome da programeri misle da si ne mogu pomoći.

CASE2018 15

Istina je da bi se profesionalni programer trebao izboriti za svoje stavove i uvjerenja. Ako je programer završio petogodišnji studij informatike ili računarstva vjerojatno ima više znanja od nekog menadžera (koji je završio npr. neki studij ekonomije) o tome što zahtjeva faza kodiranja. Programer bi se u takvoj situaciji trebao pobuniti i objasniti koje sve radnje kodiranje zahtjeva. Trebao bi na pristojan način objasniti da to nije samo mehanička radnja i educirati menadžere o tome.

3. ZNANJA I VJEŠTINE

Znanje i vještine za programera daju mu najveću vrijednost. Česte promjene koje se dešavaju u svijetu informatike tjeraju na konstantno usavršavanje i učenje. Praćenje trendova je neizbježno. Usprkos konstantnim promjenama mnoga znanja i određene vještine ostaju korisne duži niz godina i neke od njih umjesto da stare postaju sve značajnija. U ovom poglavlju izdvojili bismo četiri područja za koje smatramo u kojima bi svaki profesionalni programer imati određenu minimalnu razinu znanja i vještina.

3.1 Testovi

Jedna od najefikasnijih načina osiguravanja kvalitete softvera jesu automatski testovi. Postoje razne vrste testiranja no za programera jedinični testovi (eng. unit tests) su testovi s kojima bi trebao raditi na dnevnoj bazi. Jedinični testovi daju programeru [4]: sigurnost da je program ispravan, smanjuju broj grešaka koje radi, hrabrost da mijenja kod bez straha, dokumentaciju najniže razine kako kod radi, a ponekad čak daju bolji dizajn sustava.

Usprkos svim prednostima testovi su ujedno i dio koji se često izbacuje kada pritišću rokovi. To zapravo govori da takvi programeri ipak ne vjeruju prednostima automatskih testova. Da je to pogrešan stav govori i metoda razvoja koja je najdalje otišla u smislu testova i u smislu razvoja programa koji će moći zadovoljavati buduće korisničke zahtjeve. Riječ je o razvoju koji je vođen testovima (eng. Test Driven Developement - TDD) [8]. TDD se temelji na tri pravila [4]:

1. Ne smije se pisati produkcijski kod osim da zadovolji test koji ne prolazi. Drugim riječima ne smijemo pisati produkcijski kod dok nemamo test koji ne prolazi (tj. pada).

2. Smije se napisati samo toliko test koda da se demonstrira pad. Kod koji se ne kompilira se računa kao pad testa. 3. Smije se napasti samo toliko produkcijskog koda da prođe trenutno padajući test.

Poštivanje tih pravila vode razvoj u tri faze [8]:

Crvena – pisanje testa Zelena – pisanje produkcijskog koda da prođu testovi Refaktoriranje – čišćenje koda, micanje duplikata i sl.

Opseg ovog rada nije dovoljan da objasni kompletan TDD no zato postoje knjige poput [8], [9] koje jako dobro opisuju postupak i ideju TDD-a. Smatramo da je TDD disciplina koju bi svaki programer morao isprobati ako već ne i usvojiti. Usvajanje ove discipline kratkoročno jest trošak vremena no jednom kada se usvoji daje iznimne prednosti.

Dužnost svakog programera je pisanje ispravnog koda, ali i davanje dokaza da je kod ispravan, a to se jedino može kroz testove. Ukoliko ne primjenjujemo TDD moramo naći neki drugi način da testiramo svoj kod i osiguramo njegovu ispravnost. Nikako ne bi smijalo desiti da se program isporučuje bez da je kompletno testiran. A jedini način da brzo testiramo prije svake isporuke su automatski testovi. Izjave poput „Testirati ćemo na kraju“ ili „Nemamo vremena pa testiramo ručno“ su zablude i profesionalni programer bi toga trebao biti svjestan i raditi sve u svojoj moći da to promjeni. Kao što kažu u [7]: „Testirajte svoj softver ili će ga testirati vaši korisnici“.

Jedan od mogućih razloga da stariji programeri zanemaruju i/ili izbjegavaju testiranje leži u tome što vrlo vjerojatno njihov studijski program nije sadržavao koncepte jediničnog testiranja. Zbog toga nisu prigrlili ideju pisanja automatskih testova i što je rezultiralo da ne prenose kulturu razvoja softvera bazirano na testiranu na mlađe kolege i svoje suradnike. A sljedeće pitanje je koliko današnji studijski programi uključuju testiranje?

3.2 Refaktoriranje i čisti kod

Jedna od važnih prednosti kada imamo testove jest nestanak straha od promjene koda te otvara vrata za refaktoriranje i čisti kod.

Refaktoriranje i čisti kod su dvije povezane radnje, ali nisu sinonimi. Refaktoriranje Martin Fowler u [10] opisuje kao „kontrolirana tehnika za unaprjeđenje dizajna postojećeg koda. U suštini je primjena slijeda malih transformacija koje ne mijenjaju ponašanje, od kojih svaka transformacija je premala da bi se isplatila. No kumulativni efekt svake te transformacije je poprilično značajan. Izvedba malih koraka smanjuje rizik da se naprave greške.“

Čisti kod s druge strane govori o tome kako pisati kod koji je lako razumljiv, čitljiv, jednostavan, elegantan, efikasan itd. Robert C. Martin je 2009 svojoj knjizi Clean Code [11] opisao detaljno kako i što je čisti kod. No ideja o čistom kodu je puno starija pa tako već 1999 u knjizi The Pragmatic Programer [7] ima podosta savjeta koji su vezani uz čisti kod iako se tako ne zove.

I dok se refaktoriranje i čisti kod razlikuju oni opet idu zajedno jer bez refaktoriranja nema čistog koda, a bez čistog koda teže je ili čak nemoguće refaktorirati. Možemo reći da najčešće čisti kod uključuje refaktoriranje.

Poznavanje metoda refaktoriranja i principa čistog koda važna su i korisna i neizbježna znanja potrebna svakom profesionalnom programeru.

3.3 Uzorci dizajna

Programiranje kao struka nije stara, ako uzmemo programske jezike koja su radila na principu papirnatih traka (eng. paper tapes) i bušenih kartica (eng. punch cards) iz 1950-tih nije stara niti 100 godina. No i u tom kratkom vremenu

16 CASE2018

mnogo toga se napravilo i promijenilo, no opet mnogo toga je ostalo isto. No jedan od važnijih inovacija nakon objektno orijentirane paradigme jesu zasigurno uzorci dizajna.

Temeljna knjiga Design patterns elements of reusable object oriented software [12] definira uzorke dizajna „kao jednostavna i elegantna rješenja za specifične probleme u objektno-orijentiranom dizajnu softvera“.

Uzorci dizajna olakšavaju programeru da riješe probleme koje je već netko drugi riješio. Uzorci pojednostavljuju arhitekturu sustava (koja može biti u različitim oblicima) i čine ju fleksibilnijom. Također olakšavaju komunikaciju između programera koji su upoznati sa terminologijom uzoraka dizajna.

Kako je nemoguće odmah na samom početku predvidjeti kako će sustav izgledati, nemoguće je u startu uvijek odabrati najbolji uzorak. Pa kako bi se omogućila izmjena izvornog koda tehnike refaktoriranja nam omogućuju da sa postojećeg dizajna sustava prevedemo u neki drugi, a uzorci nam pomažu da lakše nađemo taj drugi dizajn. Vrlo koristan izvor za refaktoriranje u uzorke dizajna je [13] u kojoj se mogu naći uobičajeni principi refaktoriranja postojećeg ograničenog rješenja u poboljšanu i fleksibilniju verziju na bazi uzoraka dizajna. Pri tome su dane jasne upute u obliku sljedova aktivnosti koje se provode na segmentima postojećeg rješenja uvidu dodavanja novih i/ili brisanja postojećih klasa, promjene dijelova programskog koda i sl.

Osim uzoraka u pronalaženju boljeg dizajna mogu pomoći SOLID [14] i sl. principi. No samo objašnjavanje je izvan opsega ovog članka.

4. STAVOVI

Mogli bismo dugo pisati o tome koje bi stavove morao imati profesionalni programer. No na svu sreću već su 1999. godine Hunt i Thomas napisali knjigu The Pragmatic Programmer [7] u kojoj su naveli dobre savjete za programere. Također, 2011. godine Robert C. Martin napisao je knjigu The Clean Coder [4] u kojoj daje odgovore na pitanja poput:

Tko je profesionalni programer? Kako se profesionalac ponaša? Kako se profesionalac treba nositi sa konfliktima, kratkim rokovima i nerazumnim menadžerima? Kako i kada bi profesionalac trebao reći „ne“? Kako se profesionalac treba nositi kada je pod pritiskom?

Slijedom popularnosti knjige Robert C. Martin snimio je preko pedeset video materijala [2] i puno piše o toj temi na svom blogu [15].

Ovdje bi smo izdvojili samo neke od stavova koje smatramo posebno zanimljivima jer su temeljeni na vlastitom iskustvu i idejama iz knjiga [4], [7].

4.1 Prenošenje znanja i vještina

Kada u tvrtku dođe mladi programer potrebno ga je uvesti u posao. Međutim stariji programeri često nemaju vremena baviti se mladim programerima. Daju mu neki zadatak i neka ga riješi, ako ima pitanja neka pita, ali ne previše. Mladi programer koji je tek došao u neku tvrtku treba biti mentoriran. On treba nekoga tko će provjeravati njegov kod, koga može pitati i od koga može učiti. Profesionalni programer mora biti spreman podučavati druge i prenositi znanje i vještine.

U slučaju programiranja to je najjednostavnije kada se primjenjuje programiranjem u paru. Programiranje u paru ima višestruke prednosti. S jedne strane mladi programer koji samo promatra može vidjeti kako iskusniji radi, iskusniji programer koji objašnjava kod dobiva puno bolji uvid u svoj kod nego kada radi sam. Koliko često vam se desilo da ste došli do rješenja samo zato jer ste nekome objašnjavali svoj problem, a ponekad čak i vlastitom psu ili mački?

Osim što se programiranje u paru može koristi za educiranje mladih programera ono može biti dobra tehnika za rješavanje zajedničkih problema. Programeri se mogu izmjenjivati i dok jedan može pratiti globalnu sliku drugi se može fokusirati na detalje.

Također programiranje u paru je najefikasniji način da jedan iskusan programer prenese svoje znanje o problemskoj domeni i njenom softveru na drugog iskusnog programera. Ipak kod se najbolje uči kada programiramo. U takvoj situaciji programer koji uči može pisati kod dok onaj drugi može promatrati njegov rad i davati sugestije kada smatra da je to potrebno.

Detaljan pregled programiranja u paru može se pronaći u knjizi Pair programming illuminated [16].

4.2 Čitljiv kod

Programeri češće čitaju kod nego ga pišu [11]. Pa ako je tome tako onda je sigurno jedna od važnih zadaća programera pisanje čitljivog koda. U toku programiranja sve što pišemo nam je razumljivo jer smo u tom problemu. No već nakon tjedan dana stvari izgledaju manje razumljive, a pogotovo nakon mjesec ili godinu dana. Često se dešava da kada godinu dana programer ne radi na nekom dijelu koda koji je on sam napisao i više ne zna kako točno radi.

Stoga je vrlo važno da se situacija ne pogoršava time što je kod još nečitljiv. Loš je primjer kada se kao nazivi varijabli imena poput: a, b, c itd. ili kada se napravi loša raspodjela funkcija u hijerarhiji klasa pa se na primjer u klasi upravitelj datotekama nalazi funkcija za pretvaranje liste u polje, a istovremeno postoji klasa koja se zove upravitelj listama. Naravno tu ima brdo drugih elemenata o kojima treba voditi računa. U knjigama Clean Code [11] i Clan Arhcitecture [17] opisan je cijeli niz ideja i savjeta kako pisati kod koji će biti kasnije razumljiviji i čitljiviji.

Profesionalni programer dužan je pisati kod koji će u budućem čitanju biti razumljiv i čitljiv i treba imati stav da nikad neće ostaviti kod u stanju koji će biti nerazumljiv drugim programerima.

CASE2018 17

4.3 Produktivnost

Programeri se znaju žaliti da ne mogu biti produktivni jer imaju puno prekida. No u većini slučajeva sami su krivi jer ne znaju organizirati svoje vrijeme. Jedna tehnika koja bi mogla pomoći je Pomodoro tehnika [18]. Ideja je da se radi o manjim blokovima od po 25 minuta zvani pomodoro (rajčica) u kojima nema prekida. Svaki uspješan pomodoro se označava. Za vrijeme trajanja svaki prekid potrebno je što brže odbaciti i nastaviti raditi. Ako se prekine na duže od par sekundi pomodoro se ne broji.

Cilj tehnike je bolje upravljanje vlastitim vremenom. Dobra strana tehnike je da ne zahtjeva odobrenje, svatko ju vodi za sebe i ne mora pokazivati bilo kome svoje rezultate, a tko je spreman može ju primjenjivati u raznim poslovima. Više o samoj tehnici može se pronaći na web stranici Pomodo tehcnique [18] gdje se prodaje i knjiga.

Profesionalni programer uvijek pokušava poboljšati svoju produktivnost. No profesionalni programer pokušava poboljšati i tuđu produktivnost ili barem treba voditi brigu da ne šteti drugima ako već ne može pomoći. Drugim riječima mora biti timski igrač. Produktivnost ne ovisi samo o upravljanju vremenom već o svim stvarima koje smo dosad u ovom radu naveli.

4.4 Privatni život

Profesionalni programer ima uređen privatni život. Problemi kod kuće često se odražavaju na kvalitetu posla. Stoga je važno voditi brigu o tome. Profesionalni programer je svjestan kada mu nešto odvraća pažnju te pokušava riješiti taj problem ili barem ublažiti kako bi mogao što kvalitetnije obavljati svoj posao.

Također profesionalni programer ne radi (puno) prekovremeno. Ponekad je nemoguće izbjeći prekovremene sate, ali jednako tako nije dobro konstantno raditi prekovremeno. Prekovremeni sati nas u dugoročnom smislu iscrpljuju i produktivnost opada. Važno je prepoznati taj problem i odbijati prekovremene sate ukoliko pređu nerazumnu granicu. Ostaviti ćemo da sami definirate koja je to granica.

Balans između privatnog i poslovnog života važan je aspekt profesionalnog programera. Jednako tako važna je i fizička aktivnost i zdravlje bez kojeg sve ostalo pada u vodu.

4.5 Usavršavanje

Posljednja stav o kojem ćemo govoriti jest stav prema usavršavanju. Programeri kada se jednom zaposle vrlo često su usko ograničeni na jednu tehnologiju i metodu razvoja softvera jer je su oni definirani politikom poslodavca, razvojne grupe ili samih kupaca. Postojeće obaveze ih maksimalno okupiraju zbog rokova završetka pojedinih projekata zbog čega nemaju vremena proučavati druge tehnologije. Sljedeći razlog ograničavanja na postojeću tehnologiju obično leži u kapitaliziranom intelektualnom vlasništvu pod čime mislimo na vlastito razvijene okvire, biblioteke, module i sl. u toj tehnologiji. Njihovo prekodiranje u drugu tehnologiju vrlo često je preskupo i predugo traje, a ako ne primjenjuju testovi ono može postati izvor novih pogreška u radu sustava.

4.5.1 Interno usavršavanje

Svaka tvrtka koja razmišlja dugoročno investira u edukaciju svojih zaposlenika (u ovom slučaju programera) i u planu tjednih aktivnosti uključuje i odgovarajući broj sati za usavršavanje. Jedan od mogućih oblika usavršavanja su interni seminari koje vode vlastiti zaposlenici tvrtke, tvrtka može koristiti vanjske predavače i mogu se zaposlenici uputiti na usavršavanja u obliku formalnog, neformalnog ili informativnog obrazovanja. Tvrtka može također slati svoje zaposlenike na razne stručne konferencije. Konferencije mogu biti neovisne o proizvođačima programske opreme, tehnologije ili metode razvoja (npr. CASE) ili su jako specijalizirane na neku tehnologiju (npr. JavaCro, Javatura, WinDays, HrOUG, …).

4.5.2 Individualno usavršavanje

Profesionalan programer uzima vrijeme i samostalno uči i usavršava se u slobodno vrijeme. Robert C. Martin je jednom rekao da ako smo dali poslodavcu 40 sati dužni smo sebi dodatnih 20 sati. U tih 20 sati moramo raditi nešto što nas veseli i omogućava nam da učimo. Ako smo odabrali programiranje kao doživotnu struku onda bi ju trebali i voljeti i ne bi nam trebao biti problem dodatno se educirati u tom području. Edukacija može biti raznovrsna: web stranice, knjige, video materijali, konferencije, veleučilišta, fakulteti i sl.

Unatrag zadnjih nekoliko godina vrlo značajan oblik usavršavanja za različite struke, a posebno one koje su iz područja IKT-a što uključuje programiranje, predstavljaju masovni otvoreni online tečajevi (eng. Massive Open Online Courses – MOOC). Jedna od najpoznatiji platformi za MOOC je Coursera koja ima više od 26 milijuna korisnika, 2500 tečajeva (od kojih je oko 16% iz područja računarstva, informatike i programiranja) koje realizira više od 150 partnera.

Odličan oblik usavršavanja i razmjene iskustva su neformalna druženja poput Razmjene vještina (koja se održava na Fakultetu organizacije i informatike u Varaždinu), Developers Meetup koji se odražavaju po raznim gradovima unutar Hrvatske i izvan nje, i sl. Također tu su i razne korisničke grupe i udruge (npr. HrOpen, HUJAK, Hrvatski savez informatičara, IEEE CS†, ACM‡, AIS§, …) i sl. u koje se pojedinac može uključiti.

Ono što je važno da sami sebe motiviramo za danju edukaciju i učimo razne stvari iz programiranja, ali šire pa makar ne radimo u tim tehnologijama na poslu. Također važno je da preispitamo sebe i svoje slabosti te se kao profesionalni programeri sami pokušamo usavršiti u onome u čemu smo loši.

† IEEE Computer Society

‡ Association for Computing Machinery

§ Association for Information Systems

18 CASE2018

4.5.3 Doprinos društvu

Najbolji oblik da osoba usavrši svoje znanje jest da sudjeluje u organiziranim oblicima edukacije drugih osoba. To se može ostvariti kroz konferencije (kao predavači), edukaciju djece koju provode udruge (npr. Udruga Mladi informatičari Strahoninca –MIS, Međimurski informatički klub – MIK, …), radionice za druge programere, itd. Sljedeći oblik su pozvana predavanja na raznim kolegijima na fakultetima ili popularnima danima/tjednima karijera (npr. na Fakultetu Organizacije i Informatike). Također pojedinac može ispuniti svoje stručne ambicije kroz uključivanje u nastavni proces u školama, na otvorenim učilištima, veleučilištima i fakultetima gdje kao stručnjak iz prakse sudjeluje u izvođenju praktičnog dijela nastave. Ovo nije svaku osobu jer su potrebne i druge vještine posebno iz područaja pedagogije i metodike.

5. ZAKLJUČAK

Biti profesionalni programer nije lagan zadatak, traži izuzetno znanje i vještine, no ponajviše traži profesionalan stav. Ako bi trebali izdvojiti jednu rečenicu koja opisuje profesionalnog programera onda je to rečenica koju je jednom prilikom rekao Kent Beck [3]: „Ja nisam odličan programer, ja sam samo dobar programer sa odličnim navikama.“

Posao profesionalnog programera traži puno znanja, vještina, kompetencija, discipline, pridržavanja etike struke i sl. Robert C. Martin je u svom videu (Video 45 - The progamer's Oath) [2] naveo zakletvu programera (koja nije možda potpuna niti je do kraja točna) koja opisuje devet tvrdnji kojih bi se svaki profesionalni programer morao pridržavati (radi lakšeg razumijevanja zadržana je i engleska verzija):

1. Ja neću proizvoditi štetan kod. (I will not produce harmful code.) 2. Kod koji stvaram uvijek će biti moj najbolji rad. Ja neću svjesno dozvoliti da se kumulira kod koji je neispravan bilo u

ponašanju ili strukturi. (The code that I produce will always be my best work. I will not knowingly allow code that is defective either in behaviour or structure to accumulate.)

3. Ja ću sa svakom distribucijom dati brzi, pouzdan, ponovljiv i provjerljiv dokaz da svaki element koda radi kako bi trebao. (I will produce, with each release, a quick, sure, and repeatable proof that every element of the code works as it should.)

4. Ja ću raditi česte i male distribucije tako da ne ometam napredak ostalih. (I will make frequent, small, releases so that I do not impede the progress of others.)

5. Ja ću neumorno i nemilosrdno poboljšavati kvalitetu moga rada u svakoj prilici i nikada ju neću smanjiti. (I will fearlessly and relentlessly improve my creations at every opportunity. I will never degrade them.)

6. Ja ću sve učiniti da zadržim na visokoj razini moju produktivnost i produktivnost ostalih te neću smanjiti tu produktivnost. (I will do all that I can to keep the productivity of myself, and others, as high as possible. I will do nothing that decreases that productivity.)

7. Ja ću kontinuirano osiguravati da me drugi mogu pokriti i da ja mogu pokriti njih. (I will continuously ensure that others can cover for me, and that I can cover for them.)

8. Ja ću davati procjene koje su iskrene u veličini i preciznosti. Neću davati neizvjesna obećanja. (I will produce estimates that are honest both in magnitude and precision. I will not make promises without certainty.)

9. Ja neću nikada prestati učiti i usavršavati svoje vještine. (I will never stop learning and improving my craft.))

Neke od ovih zakletvi mogu se činiti nerazumne, no za potpuno razumijevanje što je autor želio reći potrebno je pogledati video, a za detaljno objašnjenje autor je snimio još dodatnih 7 videa (Video 38 – Video 44) na tu temu.

Programerska struka još uvijek je u razvoju i pitamo se da li joj kao uzori trebaju poslužiti starije struke poput medicine, građevinarstva i prava. Posao tih struka vrlo često je uređen zakonima, pravilnicima i drugim aktima, a samostalan rad se temelji na odgovarajućoj licenci za čiju valjanost se brine pripadajuća komora. Pojedinac se mora ponašati u skladu s pravilima i etičkim kodeksom struke jer bi u suprotnom mogla biti oduzeta licenca za izvođenje tog posla. Osim toga uloga komore je da štiti struku kao i svoje certificirane članove i putem formalnih i neformalnih kanala utječe na pravnu zaštitu struke od nestručnih osoba u profesionalnom izvođenju posla.

Specifičnost struka unutar IKT-a je da se traže i cijene certifikati koje izdaju proizvođači programske podrške putem svojih sustava edukacije i provjera. Takvi certifikati su usko orijentirani na pojedinu tehnologiju iz portfelja proizvođača, često nisu prenosivi na druge slične tehnologije ostalih proizvođača i vrlo često su kratkog vijeka trajanja.

Literatura:

1 Znanje d.o.o. and Srce, “Hrvatski jezični portal,” 2006. [Online]. Dostupno na: http://hjp.znanje.hr/. [Pristupljeno: 12.02.2018].

2 R. C. Martin, “Clean Coders,” 2018. [Online]. Dostupno na: https://cleancoders.com/videos/clean-code. [Pristupljeno: 12.02.2018].

3 J. Fields, S. Harvie, M. Fowler, and K. Beck, Refactoring: Ruby Edition. Pearson Education, 2009.

4 R. C. Martin, The clean coder: a code of conduct for professional programmers. Pearson Education, 2011.

5 R. C. Martin, “Just Following Orders,” The Clean Code Blog, 2017. [Online]. Dostupno na: http://blog.cleancoder.com/uncle-bob/2017/08/28/JustFollowingOders.html. [Pristupljeno: 12.02.2018].

6 K. McCarthy, “VW engineer sent to the clink for three years for emissions-busting code,” The Register - Biting the hand that feeds IT, 25-Aug-2017. [Online]. Dostupno na: https://www.theregister.co.uk/2017/08/25/vw_engineer_gets_3yrs_for_emissionbusting_sw/. [Pristupljeno: 12.02.2018].

7 A. Hunt and D. Thomas, The pragmatic programmer: from journeyman to master. Addison-Wesley Professional, 2000.

8 K. Beck, Test-driven development: by example. Addison-Wesley Professional, 2003.

CASE2018 19

9 S. Freeman and N. Pryce, Growing Object-oriented Software: Guided by Tests. Pearson Education India, 2009.

10 M. Fowler and K. Beck, Refactoring: improving the design of existing code. Addison-Wesley Professional, 1999.

11 R. C. Martin, Clean code: a handbook of agile software craftsmanship. Pearson Education, 2009.

12 E. Gamma, R. Helm, R. Johnson, and J. Vlissides, “Design patterns: elements of reusable object-oriented languages and systems.” Addison-Wesley Reading, 1994.

13 J. Kerievsky, Refactoring to patterns. Pearson Deutschland GmbH, 2005.

14 R. C. Martin, Agile software development: principles, patterns, and practices. Prentice Hall, 2002.

15 Cirrilo Comsulting GMBH, “The pomodoro technique,” 2018. [Online]. Dostupno na: https://francescocirillo.com/products/the-pomodoro-technique. [Pristupljeno: 13.02.2018].

16 L. Williams and R. Kessler, Pair programming illuminated. Addison-Wesley Longman Publishing Co., Inc., 2002.

17 R. C. Martin, Clean Architecture: A Craftsman’s Guide to Software Structure and Design. Pearson Education, 2017.

18 F. Cirillo, The pomodoro technique. Lulu.com, 2009.

Podaci o autorima:

Matija Novak, mag. inf.

e-mail: matija.novak@foi.hr

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. 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. Bio je član programskog odbora konferencije CARNet User Conference (CUC) od 2007. do 2013. godine.

Prof. dr. sc. Dragutin Kermek

e-mail: dragutin.kermek@foi.hr

Sveučilište u Zagrebu

Fakultet organizacije i informatike

Pavlinska 2, Varaždin 42000

20 CASE2018

CASE2018 21

RAZVOJ IOT APLIKACIJA

IOT APPLICATIONS DEVELOPMENT

Marko Meštrović, Tonko Kovačević

SAŽETAK:

Razvoj Interneta stvari rješenja nerijetko zahtijeva dobro poznavanje nekog od programskih jezika kao što su C/C++, Python, Java, C#. Osim što je potrebno poznavati programski jezik, razvoj IoT rješenja uglavnom oduzima dosta vremena na programiranje i testiranje programskog koda. Nerijetko se javlja želja da osobe koje ne posjeduju odgovarajuća programerska znanja imaju ideju, koju nisu u mogućnosti realizirati, ili pak da se pojedina ideja razvije jednostavno u mnogo kraćem vremenskom roku. Oba problema mogu se efikasno riješiti promjenom pristupa, odnosno odgovarajućem odabiru platforme kao što je primjerice Node-RED. Ova platforma omogućuje razvoj korištenjem dijagrama toka, umjesto klasičnog pisanja programskog koda. Ključne riječi: IoT, oblak, platforma, Node-RED, MQTT

SUMMARY:

Development of Internet of Things (IoT) solutions usually requires good knowledge of a particular programming language such as C/C++, Python, and Java or C#. In addition to having to know the programming language, the development process of IoT devices is time consuming, mostly while programming and debugging of code. Every day, many people who don’t have adequate programming skills, have an idea how to create something or to develop an idea simply and within much shorter period of time. Both listed problems can be solved efficiently by changing the approach that is by choosing the corresponding development platform such as Node-RED. This platform allows rapid development of application using flow diagrams, instead of writing the program code.

Keywords: IoT, cloud, platform, Node-RED, MQTT

1. UVOD

Broj uređaja povezanih na Internet na Zemlji premašio je broj ljudi, a predviđanja ICT tvrtki su da će taj broj doseći 50 milijardi do 2020. godine kao što se vidi na slici 1.1.

Područje Interneta stvari (IoT) jedno od najbrže rastućih grana industrije, a predviđa se da će u 2018. godini broj IoT uređaja zasjeniti broj mobilnih telefona. Pored toga, procjenjuje se da će ekonomski utjecaj IoT-a do 2025. godine iznositi između 2.7-6.2 bilijuna dolara (slika 1.2.). U ovom radu prezentira se Node-RED platforma za razvoj IoT rješenja koja se zasniva na konceptu vizualnog povezivanja funkcionalnih blokova korištenjem dijagrama toka zbog sve većih zahtjeva za brzim razvojem aplikacija,. Uz to, ukratko se prezentiraju podržane platforme u oblaku (cloud platforms) na koje je moguće instalirati Node-RED programsku podršku. U zadnjem dijelu rada opisan je MQTT (Message Queuing Telemetry Transport) protokol koji ima važnu ulogu u IoT svijetu zbog svoje jednostavnosti i lagane implementacije, kao i ugrađenog mehanizma za QoS (Quality of Service) koji garantira isporuku sadržaja bez obzira na moguće probleme u komunikaciji.

Slika 1.1. Koncept Internet of things ''rođen'' je između 2008. i 2009. godine (Izvor: Cisco IBSG, http://www.cisco.com/c/dam/en_us/about/ac79/docs/innov/IoT_IBSG_0411FINAL.pdf)

22 CASE2018

Slika 1.2. Ekonomski utjecaj IoT-a do 2025 [izvor: McKinsey Global Institute analysis]

2. NODE-RED IOT PLATFORMA

Node-RED je programska platforma razvijena u NodeJS programskom okviru, a namjenjena je za razvoj IoT rješenja korištenjem vizualnog (blokovskog) načina povezivanja komponenti [1]. Ovaj način uveliko ubrzava razvoj aplikacija budući da u većini slučajeva nije potrebno pisati programski kod. Razvoj aplikacije je omogućen korištenjem klasičnog web preglednika uzuporabu gotovih funkcijskih blokova, koji se metodom ''drag-and-drop'' pozicioniraju na željene pozicije unutar sučelja.Nakon toga blokovi se međusobno povezuju, pri čemu veze između pojedinih blokova podrazumijevaju logičke tokove podataka. Na slici 2.1. prikazano je vizualno sučelje Node-RED platformekojese sastoji odsljedećih cjelina:

s lijeve strane nalaze funkcijski blokovi; u sredini se nalazi radna površina za pozicioniranje i povezivanje blokova; desno su prikazane kartice (tabs) koje pružaju mogućnost prikaza osnovnih informacija i konzola za otkrivanje

pogreški (debug console).

Slika 2.1. Vizualno sučelje Node-RED platforme

CASE2018 23

Vizualno prezentirani blokovi unutar samog Node-RED sustava su JavaScript funkcije. Jednom kreirana funkcija može se spremiti za kasnije korištenje ili objaviti na nekoj od softverskih razvojnih platformi kao što su GitHub ili npmjs.org, što osigurava njihovu uporabu drugim korisnicima. Podatokvni tokovi (data flow) kreirani u Node-RED sučelju mogu se pohranjivati u JSON formatu unutar datoteke:

>>flows_<ime_racunala>.json

a koja je smještena u radnom direktoriju pod nazivom .node-red.

Node-RED moguće je instalirati na različitimplatformama kao što su Windows, Linux, MacOS operativni sustavi. Što se tiče instalacije na ugradbena računala, moguće ga je instalirati na Raspberry Pi, BeagleBone Black i Arduino platforme te na određene platformekoje koriste Android operativni sustav. Dostupna je i podrška za instalaciju u okruženju u oblaku i to na sljedeće platforme: IBM BlueMix, SenseTecnic FRED, Amazon Web Services i Microsoft Azure. Također, Node-RED je dostupan je i u obliku Docker kontejnera.

Instalacija na korisničko računalo može se izvršiti iz npmjs.org ili GitHub repozitorija uz predinstalranu podršku za Node.js verzije LTS 8.x ili novije. Primjerice, pozivanjem komande u CLI (Command Line Interface) sučelju:

>>npm install –g –unsafe-perm node-red.

Pokretanje se vrši jednostavnim pozivanjem komande node-red u CLI sučelju, dok se pristup grafičkom sučelju ostvaruje korištenjem nekog od web preglednika kao što su primjerice Mozilla Firefox, Google Chrome, Internet Explorer ili Safari, pri čemu je dovoljno upisati IP adresu ili DNS ime računala na kojem je instaliran Node-RED uz korištenje komunikacijskog porta 1880, primjerice:

http://<IP_ADRESA:1880/.

Inicijalno Node-RED sučelje nije zaštićeno nikakvim autentifikacijskim mehanizmom te je nužno odmah nakon instalacije pristupiti postavljanju parametara za autentifikaciju kako bi se spriječila mogućnost neovlaštenog pristupa sustavu. Podržani mehanizmi autentifikacije su klasična kombinacija korisničkog imena i lozinke ili korištenjem nekih od Oauth/OpenID providera kao što su primjerice Twitter ili GitHub. Konfiguracija autentikacijskih parametara se vrši unutar settings.js datoteke, a koja je smještena u radnom direktoriju.

Slika 2.2. Prikaz inicijalno ugrađenih funkcija

U okviru same Node-RED platforme dostupan je određeni broj funkcionalnih blokova koji nam omogućavaju razvoj jednostavnijih rješenja, slika 2.2. Prva grupa pod nazivom ''input'' pruža mogućnost očitavanja parametara iz nekoliko različitih tipova izvora kao što su MQTT broker, HTTP REST sučelje, Websocket, TCP socket i UDP socket. Grupa ''output'' pruža nam mogućnost slanja podataka na ''debug'' konzolu i MQTT brokeru, generiranje HTTP odgovora, kao i slanje na Websocket, TCP i UDP socket. Također, na raspolaganju je i grupa ''function'' u okviru koje je dostupan veći broj logičkih funkcija koje omogućavaju uvjetovano izvršavanje tokova. Uz to, tu su i funkcije koje omogućavaju čitanje i pisanje datoteka u csv, html, json, xml, yabl i rbe formatu. Grupa ''socia'' pruža mogućnost komunikacije korištenjem Twitter API sučelja te spajanje na mail posužitelj. Ukoliko postoji potreba za komunikacijom s nekom drugom platformom, tada se odgovarajuća funkcija može potražiti na npmjs.org repozitoriju. U grupi ''storag'' dostupne su funkcije za čitanje i pisanje UTF-8 kompatibilnih datoteka na lokalnom računalu. Funkcija ''watch'' omogućuje detekciju izmjena unutar nekog direktorija na računalu, a funkcija ''feedparse'' omogućuje dohvat RSS izvora. Ukoliko se želi izvršiti određena sistemska komanda to se može učiniti korištenjem funcije ''exec''. Na najpoznatijem repozitoriju za distribuciju JavaScript biblioteka npmjs.org dostupno je više od 1800 gotovih funkcija koje je moguće direktno integrirati u Node-RED ako dostupne funkcije nisu dovoljne za realizaciju projekta. Ove funkcije omogućavaju razne funkcionalnosti kao što su: podrška za povezivanje fizičkih uređaja, mogućnosti za spajanje na razne vrste baza podataka i integracije s ostalim sustavima korištenjem standardiziranih protokola i API sučelja ili namjenskih programskih funkcija razvijenih od strane korisnika.

Prilikom korištenja različitih ugradbenih računalnih platformi kao što su Raspberry Pi ili BeagleBone Black moguće je direktno pristupati GPIO (General Purpose Input Output) pinovima, komunicirati putem I2C (Inter-Integrated Circuit) ili SPI (Serial Peripheral Interface) sabirnica te korištenjem ugrađenog USB (Universal Serial Bus) ili RS232 (Recommended Standard 232) sučelja. Arduino platforma je po pitanju Node-RED platforme specifična jer ne pruža mogućnost instalacije zbog veoma male količine memorije. Za uspješnu integraciju Arduino i Node-RED platformi nužno je instalirati Node-RED na neku drugu fizičku platformu koja ima mogućnost povezivanja putem USB sučelja, dok se na Arduino instalira programska podrška za komunikaciju putem Firmata protokola dostupnog unutar Arduino IDE sučelja. Arduino je zatim

24 CASE2018

moguće spojiti na željeno fizičko sklopovlje, kao što su primjerice razni senzori i slično, a Node-RED posredstvom Firmata protokola može pristupati Arduino pločici i posredno očitavati ili upisivati parametre uređaja, odnosno vršiti komunikaciju s njima.

3. IOT PLATFORME U OBLAKU

U ovom poglavlju ukratko su predstavljene platforme u oblaku koje su službeno podržane za korištenje Node-RED platforme. Bitno je napomenuti da instance Node-RED platforme koje se izvršavaju na infrastrukturi u oblaku nemaju mogućnost direktnog povezivanja i interakcije s fizičkim uređajima kao što je to kod različitih ugradbenih platformi, primjerice kod Raspberry Pi mikroračunala. Instance Node-RED platforme u oblaku mogu komunicirati s fizičkim uređajima putem posredničkih čvorova koji im omogućuje interakciju. Kod razmatranja usluga računarstva u oblaku (cloud computing) nužno je uvidjeti razliku između različitih modela usluga. Na slici 3.1. prikazan je tradicionalni model koji se koristio do pojave računarstava u oblaku te tri modela koji se implementiraju na infrastrukturi u oblaku.

Slika 3.1. Različiti modeli računalne infrastrukture

Kod tradicionalnog modela, na korisniku je bilo da uspostavi kompletnu fizičku infrastrukturu za sve usluge koje nudi uz velike troškove operativnog održavanja takvog modela infrastrukture. IaaS (Infrastucture as a Service) je model kod kojeg korisnik zakupljuje hardverske resurse, a samostalno se brine o operativnom sustavu, bazama podataka, sigurnošću poslužitelja te aplikativnoj podršci. Primjer IaaS usluge su AWS EC2 i Azure Virtual Machines. Kod PaaS (Platform as a Service) modela, korisnik se brine isključivo o aplikaciji, dok svu brigu o infrastrukturi vodi davatelj usluge. SaaS (Software as a Service) je model kod kojeg korisnik isključivo koristi željenu aplikaciju, dok svu brigu oko održavanja, počevši od infrastrukturnog do aplikativnog vodi pružatelj usluge.

3.1 IBM BlueMix

IBM BlueMix je PaaS rješenje u oblaku razvijeno od strane tvrtke IBM. Na raspolaganju su tri modela korištenja [2]. Na slici 3.2 prikazan je pojednostavljena arhitektura IBM BlueMix platforme.

Slika 3.2. Arhitektura IBM BlueMix IoT platforme

(Izvor: https://console.bluemix.net/catalog/services/internet-of-things-platform)

CASE2018 25

3.2 SenseTecnic FRED

Tvrtka SenseTecnic specijalizirana je za razvoj komercijalnih IoT rješenja i aktivno sudjeluje u razvoju Node-RED platforme od samog početka [3]. Jedan od proizvoda ove tvrtke jest i FRED, što je skraćenica od pojma ''Front-End for Node-RED'', a radi se o platformi u oblaku koja ima mogućnost paralelnog izvršavanja velikog broja Node-RED instanci. Svaka instanca oslanja se na takozvani ''smart-proxy'' servis koji usmjerava HTTP upite i web-socket komunikaciju prema određenoj instanci na osnovu API ključa, a koji je individualan za svakog korisnika na sustavu. Arhitektura kompletnog sustava zasniva se na Docker kontejnerima čime se osigurava skalabilnost sustava.

Dostupne su besplatna i plaćena varijanta usluge. Kod besplatne varijante, postoji ograničenje od maksimalno 50 komponenti, a instanca se gasi automatski nakon isteka 24 sata od zadnje prijave u sustav. Plaćene varijante usluge za razliku od besplatne imaju mogućnost komunikacije korištenjem MQTT protokola i mogućnost upravljanja putem desktop aplikacije, a međusobno se razlikuju po količini dostupne memorije za izvršavanje servisa, broja upita prema korisničkoj podršci, broju istovremeno spojenih MQTT klijenata te podrškom za pohranu podataka u bazu podataka. Skuplji paketi imaju mogućnost pohrane u InfluxDB bazu podataka, koja služi kao privremeno spremište.

Slika 3.3. Arhitektura SenseTecnic FRED platforme

(Izvor: http://sensetecnic.com/newsletter-10-news-from-the-fred-cloud-node-red-team-at-sense-tecnic/)

3.3 Amazon Web Services

Amazon Web Services (AWS) je platforma u oblaku tvrtke Amazon [4]. Platforma je započela s radom 2002 godine, a prva javna usluga bila je Simple Queue Service (SQS) pokrenuta u studenom 2004. U ožujku 2006. Amazon službeno predstavio tri individualne usluge koje se mogu međusobno integrirati, a to su:

Simple Storage Service (S3) koja služi kao podatkovno spremište; Elastic Cloud Computing (EC2) kao usluga virtualnog računala u oblaku; SQS koji se koristi kao servis za distribuiranu dostavu poruka kao što su email ili SMS.

Trenutno AWS u ponudi ima preko 90 različitih servisa i usluga. Po dostupnim podacima iz 2017. godine AWS je bio uvjerljivo vodeći igrač na Internet tržištu, zastupajući ukupno 34% tržišta PaaS i IaaS usluga, dok su vodeća konkurencija Microsoft, Google i IBM zauzeli po 11%. AWS je prisutan u ukupno 16 zemljopisnih regija u svijetu te kontinuirano širi svoju dostupnost. Osim javno dostupne infrastrukture u oblaku u USA su dostupne i usluge GovCloud i Secret, čije korištenje je moguće isključivo tijelima javne uprave i raznim državnim agencijama. AWS je također zakoračio u IoT svijet tako što je 2015. godine u rad pustio platformu pod nazivom IoT Core, slika 3.4.

26 CASE2018

Slika 3.4. Arhitektura Amazonove IoT Core platforme

(Izvor: http://linuxgizmos.com/amazon-releases-aws-greengrass-for-local-iot-processing-on-linux-devices/)

3.4 Microsoft Azure

Microsoft Azure, inicijalno poznat pod imenom Windows Azure je platforma za računarstvo u oblaku pokrenuta 2010. godine, a do danas je dostupna u 36 regija u cijelom svijetu, slika 3.5 [5]. Azure trenutno broji preko 100 različitih usluga i servisa koji su dostupni korisnicima te pokriva sva tri modela računalstva u oblaku: IaaS, PaaS i SaaS. Što se tiče implementacije IoT tehnologija, Azure nudi IoT Suite, skup predkonfiguriranih alata koji nam omogućavaju ubrzani razvoj rješenja. Pri tome su zastupljena rješenja koja osiguravaju mogućnost spajanja krajnjih uređaja, obradu podataka, analitiku te mogućnost prikaza podataka i isporuku vanjskim sustavima ukoliko za to postoji potreba.

Slika 3.5. Prikaz ključnih elemenata Azure IoT arhitekture

(Izvor: https://blogs.msdn.microsoft.com/tedmalone/2016/05/30/the-iot-journey-connecting-to-the-cloud/)

Node-RED instancu u okviru Microsoft Azure platforme moguće je instalirati na način da se kreira virtualni poslužitelj s Linux Ubuntu operativnim sustavom, a zatim se na njemu instalira Node-RED. Također, potrebno je u okviru postavki za ''Network security group'' postaviti pravila za TCP port 1880.

4. MQTT PROTOKOL

MQTT je ISO standardizirani protokol za komunikaciju koji se temelji na takozvanom ''pub-sub'' (publish-subscribe) principu [6]. Oslanja se na TCP/IP protokol, a osmišljen je za potrebe međusobnog povezivanja raznih uređaja i usluga

CASE2018 27

između udaljenih lokacija korištenjem javne ili privatne IP mrežne infrastrukture. Gledano s aspekta primjene za IoT rješenja, MQTT protokol se uglavnom koristi za komunikaciju s raznim senzorima i sličnom opremom koju karakterizira mala količina raspoložive memorije, kao i za uvjete gdje je mrežna propusnost ograničena iz određenog razloga. Također, u većini slučajeva se radi o baterijski napajanim uređajima kojima je potrošnja energije od ključna važnosti. Klasični modeli komunikacije kao što je primjerice HTTP REST API ili SOAP nisu adekvatni budući da unose veliku zalihost, čime se znatno poskupljuje implementacija. Za uspješno korištenje MQTT protokola, nužno je imati pristup MQTT poslužitelju, koji se još naziva i broker. Neki od poznatijih MQTT brokera su HiveMQ, Apache ActiveMQ, MQTTRoute, Emmiter, HBMQTT, IBM MessageSight, Mosca, Mosquitto i RabbitMQ. Iako je svima zajednička činjenica da se radi o MQTT brokerima, razlikuju se po primijenjenim tehnologijama, odnosno programskim jezicima koji su korištene za razvoj. Pored toga, razlikuje se po dodatnim mogućnostima kao što su: integracija s raznim servisima, bazama podataka, protokolima ili u mogućnost horizontalnog skaliranja kada je potrebno upravljati velikim količinama podataka. Kako bi uređaji mogli komunicirati korištenjem MQTT protokola, nužno je unutar programskog koda implementirati odgovarajuće biblioteke. Komunikacija se odvija posredovanjem takozvanog ''brokera'', odnosno mrežnog poslužitelja koji zaprima MQTT poruke i prosljeđuje ih ostalim uređajima,slika 4.1.

Slika 4.1. Princip rada MQTT protokola

(Izvor: https://www.survivingwithandroid.com/2016/10/mqtt-protocol-tutorial.html)

Prva specifikacija MQTT protokola objavljena je 1999. godine, a danas je u upotrebi verzija 3.1. Maksimalna veličina poruke može biti do 256 MB, bez obzira što je protokol inicijalno zamišljen za male količine podataka. Nema ugrađene mehanizime za ispravak grešaka ili retransmisije, već se u tu svrhu oslanja na TCP/IP protokol. Komunikacija između poslužitelja i klijenta se odvija po TCP portu 1883 za klasičnu varijantu protokola, te TCP portu 8883 za TLS varijantu. Od verzije protokola 3.1, moguća je i autentifikacija klijenta korištenjem korisničkog imena i lozinke. U slučaju da TLS zaštitni mehanizam nije na raspolaganju, može se pribjeći i zaštiti komunikacije na aplikacijskoj razini, primjerice korištenjem AES enkripcije. Osim klasičnog MQTT protokola, postoji i varijanta MQTT-SN (Sensor Network), a radi se o inačici protokola kojoj je primarna namjena za korištenje u senzorskim mrežama gdje ne postoji podrška za TCP/IP protokol već primjerice ZigBee ili neki drugi protokol.

Kako bi se instalirala podrška za MQTT protokol nužno je napisati vlastitu biblioteku ili koristiti već postojeću. Tako je razvijena namjenska programska podrška za mikrokontrolerski upravljane platforme kao što su Arduino, ESPduino, Mbed, Nanode i netDuino. Također, programska podrška je dostupna za cijeli niz programskih jezika kao što su C, C++, Java, Go, JavaScript, Lua, dotNET, PHP, Python, Ruby i drugi. Ovo praktički omogućava implementaciju MQTT protokola na bilo kojoj platformi, no treba napomenuti da neke od dostupnih biblioteka nemaju sve dostupne funkcionalnosti koje su definirane standardom. Sam protokol je veoma jednostavan i temelji se na razmjeni 14 različitih preddefiniranih poruka (slika 4.2.) te je stoga veoma lagan za implementaciju i ne zahtjeva posebno održavanje. U praksi se MQTT protokol koristi u mnogim sustavima, a da korisnici toga nisu niti svjesni. Primjerice, Facebook ga koristi unutar Messenger sustava za razmjenu poruka, no u javnost nije izašao sa detaljnijim informacijama o načinu korištenja. Poznate računalne platforme u oblaku kao što su AWS i Azure, te OpenStack ga također koriste za internu razmjenu poruka, kao i niz manje poznatih aplikacija i IoT rješenja.

28 CASE2018

Slika 4.2. MQTT poruke

U protokolu je ugrađena podrška za QoS, pa je prilikom slanja poruke moguće definirati uvjete isporuke, a to se izvodi postavljanjem zastavice (flag) u zaglavlju svake poruke. Na raspolaganju su nam ukupno 3 različite mogućnosti:

Poruka će se isporučiti bez potrebe za potvrdom isporuke; Poruka će se isporučiti barem jednom, sa zahtjevom za potvrdom isporuke; Poruka će se isporučiti točno jednom, sa zahtjevom za potvrdom isporuke.

Ovaj mehanizam iznimno je važan budući da u uvjetima gdje može doći do poteškoća u mrežnoj komunikaciji garantira isporuku sadržaja poruke bez obzira na eventualnu nepouzdanost komunikacijske infrastrukture.

5. ZAKLJUČAK

U ovom radu prezentirana je NodeRED platforma koja se koristi za razvojIoT aplikacija. Kako bi se korisniku omogućio pristup prikupljenim podacima prezentirane su četiri najpopularnije platforme u oblaku koje se koriste za razvoj IoT aplikacija uz mogućnost korištenja NodeRED platforme. Na kraju rada dan je kratak pregled MQTT protokola koji omogućava integraciju cjelokupnog IoT rješenja.

Literatura:

1 https://nodered.org/ (Pristupljeno, 10.12.2017.)

2 https://www.ibm.com/cloud/internet-of-things (Pristupljeno, 5.2.2018.)

3 https://fred.sensetecnic.com/ (Pristupljeno, 11.2.2018.)

4 https://aws.amazon.com/ (Pristupljeno, 7.8.2017.)

5 https://azure.microsoft.com/ (Pristupljeno, 20.1.2018.)

6 http://mqtt.org/ (Pristupljeno, 20.12.2017.)

Podaci o autorima:

Marko Meštrović Veleučilište „Marko Marulić“ u Kninu Kralja Petra Krešimira IV 30, 22300 Knin e-mail: marko.mestrovic@veleknin.hr dr.sc. Tonko Kovačević Sveučilišni odjel za stručne studije, Sveučilište u Splitu Kopilica 5, 21000 Split e-mail: tkovacev@oss.unist.hr

CASE2018 29

PRIMJENA STATISTIKE U ORACLE BAZI PODATAKA

Zlatko Sirotić

SAŽETAK

Oracle baza ima širok raspon alata za statističke potrebe. Oracle Advanced Analytics (OAA) je opcija Oracle baze podataka (Enterprise Edition), što znači da se posebno plaća. OAA se sastoji od dva dijela: Oracle Data Mining i Oracle R Enterprise. Osim OAA opcije, na raspolaganju je skoro 300 SQL statističkih funkcija, od kojih je većinu moguće koristiti u svim edicijama Oracle baze, pa i besplatnoj XE ediciji. U radu je prikazano desetak primjera korištenja tih SQL funkcija.

ABSTRACT

The Oracle database has a wide range of tools for statistical purposes. Oracle Advanced Analytics (OAA) is an Oracle Database (Enterprise Edition) option, which means it is paid specially. OAA consists of two parts: Oracle Data Mining and Oracle R Enterprise. In addition to the OAA option, nearly 300 SQL statistical functions are available, most of which can be used in all editions of the Oracle database, including the free XE edition. This paper presents a dozen examples of using these SQL functions.

1. UVOD

Primijenjena statistika je danas jako važna za umjetnu inteligenciju (AI), naročito kod strojnog učenja. No i izvan AI, statistika se intenzivno primjenjuje, i to na velikim količinama podataka, smještenim u (različite) baze podataka.

Često se koriste specijalizirani alati / jezici za statistiku. Neki su komercijalni, kao SAS, SPSS, MATLAB, a neki besplatni, kao jezik (opće namjene) Python i statistički jezik R. Oracle SUBP može koristiti jezik R na dva načina. Jedan način je da se podaci iz baze prebace na R klijenta, a rezultati se vraćaju na bazu. Drugi način, bolji i skuplji, je da se direktno koristi R stroj (engine) unutar Oracle baze.

Postoji još jedna varijanta – korištenje (skoro 300) SQL statističkih funkcija, od kojih je većinu moguće koristiti u svim edicijama Oracle baze, pa i onoj besplatnoj (XE edicija).

2. ORACLE ADVANCED ANALYTICS

Oracle Advanced Analytics (OAA) je opcija Oracle baze podataka (Enterprise Edition), što znači da se posebno plaća. OAA postoji od baze 11g i sastoji se od dva dijela:

Oracle Data Mining, koji je postojao i u prethodnim verzijama baze, 9i i 10g;

Oracle R Enterprise, koji je uveden u 11g.

Slika 1. prikazuje razvoj napredne analitike u Oracle bazi podataka.

Slika 1. Evolucija Oracle Advanced Analitics opcije; Izvor: Oracle prezentacija

30 CASE2018

Oracle Data Mining se može ukratko opisati kao skup SQL funkcija i PL/SQL paketa, koji služi za data mining unutar baze podataka (in-database data mining). Naravno, tu su i grafički alati, npr. Oracle Data Miner Workflow GUI (ekstenzija Oracle SQL Developer alata). Oracle R Enterprise integrira programski jezik R (koji je open source) unutar Oracle baze podataka.

Slika 2. prikazuje mogućnosti OOA opcije.

Slika 2. Mogućnosti Oracle Advanced Analitics opcije; Izvor: Oracle prezentacija

Osim u Oracle R Enterprise (uveden u 11g), R programski jezik se može koristiti nad Oracle bazom i bez OOA opcije, ako se R jezik koristi (samo) na klijentskoj strani. Postoji i (besplatni) Oracle R Distribution (Oracle-supported redistribution of open source R). Omogućuje bolju skalabilnost i bolje performance kada se (kao klijent) koristi sa ORE (koji se izvršava na bazi). Osim toga, omogućuje dinamičko učitavanje biblioteka za linearnu algebru (npr. Intelovu Math Kernel Library) koje omogućuju da se neke R funkcije izvršavaju u višedretvenom modu.

Za razliku od toga, Oracle R Enterprise integrira programski jezik R unutar Oracle baze podataka. Slika 3. prikazuje na koji način radi Oracle R Enterprise engine.

Slika 3. Kako radi radi Oracle R Enterprise engine; Izvor: Oracle prezentacija

Kako prikazuje slika 3., R na klijentskom računalu presreće R funkcije i prosljeđuje ih serveru. Rezultate dobivene sa baze prikazuje grafički. Može raditi i transformacije podataka i koristiti statističke funkcije i napredne analitičke funkcije.

CASE2018 31

R unutar Oracle baze omogućuje obradu velikih količina podataka direktno u bazi, i može koristiti SQL paralelizam (koji ima EE edicija baze). Koristi postojeće statističke i data mining SQL funkcije / PL/SQL pakete koji se nalaze u Oracle bazi. R Engine (uključujući Oracle R Enterprise pakete) je R sustav prilagođen od strane Oracle-a. Moguće je istovremeno startati više takvih R sustava, tj. koristiti paralelizam i na R razini.

Ukratko, ORE eliminira problem ograničenja memorije na klijentskom računalu, omogućuje paralelizam i optimizaciju upita na bazi, ali i paralelizam na R razini.

3. PODSJETNIK NA OSNOVE MATEMATIČKE STATISTIKE

Diskretna (ili diskontinuirana) slučajna varijabla x koja prima niz vrijednosti x1, x2, … ali svaku od njih s određenom vjerojatnošću p(x1), p(x2), …

pri čemu vjerojatnosti p(xi) zadovoljavaju jednakost p(xi) = 1 Primijetimo da niz vrijednosti koje poprima slučajna varijabla može biti i beskonačan.

Skup svih parova: {xi, p(xi)}, i = 1, 2, …

tvori razdiobu (distribuciju) slučajne varijable x. Zakon p(x) po kojem svakoj vrijednosti xi pripada vjerojatnost p(xi) zovemo funkcijom (gustoće) vjerojatnosti slučajne varijable x.

Funkcija vjerojatnosti se može prikazati i grafički. Npr. na slici 4. prikazana je funkcija vjerojatnosti slučajne varijable r koja predstavlja broj glava kod bacanja pet novčića (koji su pošteni, tj. kod kojih je ista vjerojatnost padanja glave i pisma):

Slika 4. Funkcija vjerojatnosti varijable r (broj glava kod bacanja pet novčića); Izvor: [1]

I kod diskontinuirane i kod kontinuirane slučajne varijable, najvažnije su njene sljedeće veličine: matematičko

očekivanje ( ili E(x)), varijanca (2

ili V(x)) i standardna devijacija (). Umjesto pojma matematičko očekivanje, u praksi se često koristi pojam aritmetička sredina, ali je prvi pojam primjereniji za teoretske, a drugi za empiričke distribucije.

Kod diskontinuirane slučajne varijable, te se veličine definiraju ovako:

= xi p(xi) (matematičko očekivanje)

2 = (xi - )

2 p(xi)

= xi

2 p(xi) -

2 (varijanca)

= 2

(standardna devijacija).

Varijanca se može definirati i kao prosječno kvadratno odstupanje pojedinačnih vrijednosti od matematičkog očekivanja. Kvadrat se uzima kako se ne bi poništile pozitivne i negativne razlike, a lakše je raditi s kvadratom nego sa apsolutnim vrijednostima razlika. Kako bi se na neki način eliminirao utjecaj kvadriranja, uvela se standardna devijacija - kao (drugi) korijen varijance.

Osim funkcije vjerojatnosti, kod diskretnih slučajnih varijabli važna je funkcija distribucije (ili razdiobe) vjerojatnosti slučajne varijable (ili funkcija kumulativne distribucije, eng. Cumulative Distribution Functions). Funkcija pokazuje kolika

je vjerojatnost da slučajna varijabla x poprimi bilo koju vrijednost x0:

F(x0) = p(xi) tj. F (x0) = P{x x0}

xi x0

Na slici 5. prikazana je funkcija distribucije koja odgovara prethodno prikazanoj funkciji vjerojatnosti slučajne varijable r (koja predstavlja broj glava kod bacanja pet novčića).

32 CASE2018

Slika 5. Funkcija distribucije varijable r (broj glava kod bacanja pet novčića); Izvor: [1]

Diskretne varijable služe za izučavanje diskontinuiranih obilježja elemenata nekog skupa ili niza pojava. Iako se može postaviti filozofsko pitanje da li (izvan matematike) uopće postoji beskonačnost, a pogotovo neprebrojiva beskonačnost, u praksi radimo kao da kontinuirana obilježja stvarno postoje (npr. visinu ili težinu neke osobe smatramo kontinuiranim obilježjima) i za njih koristimo kontinuirane slučajne varijable. Kod kontinuirane slučajne varijable vjerojatnost ne pridružujemo pojedinoj vrijednosti varijable (jer bi ta vjerojatnost bila 0), već intervalu vrijednosti na brojevnom pravcu.

Funkcija (gustoće) vjerojatnosti kontinuirane slučajne varijable x (ili funkcija gustoće vjerojatnosti, eng.Probability Density Function) je takva funkcija f(x) koja ima svojstva:

1. f(x) 0 za svaki x iz domene funkcije [a, b] (a može biti -, b može biti +)

2. ab f(x) dx = 1 (površina ispod funkcije unutar domene [a, b] je 1)

3. x1x2

f(x) dx = P{x1 x x2} (površina ispod funkcije unutar domene [x1, x2]

jednaka je vjerojatnosti da slučajna varijabla poprimi vrijednost iz te domene).

Kod kontinuirane slučajne varijable, najvažnije veličine definiraju se ovako:

= ab x f(x) dx (matematičko očekivanje)

2 = a

b (x - )

2 f(x) dx

= a

b x

2 f(x) dx -

2 (varijanca)

= 2

(standardna devijacija).

Jedna od najpoznatijih funkcija vjerojatnosti (kontinuirane varijable) je tzv. normalna razdioba (poznata i kao Gaussova krivulja, po matematičaru Gaussu), koja je važna po tome što mnoge druge razdiobe (diskontinuirane i kontinuirane) graniče prema njoj ako neki parametri rastu u beskonačnost. Posebno postoji tzv. jedinična (ili standardna) normalna razdioba, kod koje je matematičko očekivanje = 0, a standardna devijacija = 1.

Funkcija vjerojatnosti jedinične (ili standardne) normalne razdiobe je:

a funkcija vjerojatnosti općenite normalne razdiobe je

Slika 6. prikazuje jediničnu normalnu razdiobu.

CASE2018 33

Slika 6. Normalna razdioba (najpoznatija funkcija vjerojatnosti); Izvor: [1]

Kao što kod diskretne varijable svaka funkcija vjerojatnosti ima odgovarajuću funkcija distribucije, tako je i kod kontinuirane varijable.

Funkcija distribucije kod kontinuirane slučajne varijable definira se ovako:

F(z) = az f(x) dx = P{a x z}

Funkcija distribucije jedinične normalne razdiobe prikazana je na slici 7.

Slika 7. Funkcija distribucije kod (jedinične) normalne razdiobe; Izvor: [1]

Ne treba raditi grešku (koja se ponekad radi u praksi) i smatrati da se sve pojave u prirodi ponašaju po zakonu normalne razdiobe (barem približno). Za provjeru podudaranja teoretske i stvarne razdiobe potrebno je izvršiti odgovarajuće

testiranje, a često se za to koristi tzv. 2-test.

Ako imamo funkciju vjerojatnosti slučajne varijable x koja (funkcija) ovisi o nekom parametru P (parametara može biti više, npr. parametri ne-jedinične normalne razdiobe su matematičko očekivanje i standardna devijacija, ali jedan parametar promatramo kao varijablu, a ostale kao konstantu) onda možemo postaviti hipotezu H0 da je vrijednost tog parametra npr. P0, te alternativnu hipotezu H1, da je vrijednost parametra P1 (moguće su i drugačije varijante postavljanja hipoteza). Odluku o tome da li prihvaćamo hipotezu H0 ili H1 donosimo na temelju testiranja uzorka, koji je uvijek konačan. Kod testiranja moguće su četiri situacije, dvije u kojima smo donijeli ispravnu odluku i dvije u kojima smo donijeli pogrešnu odluku, kako prikazuje tablica 1.

Tablica 1. Moguće kombinacije istinitosti hipoteze H0 i pravilnosti zaključivanja; Izvor: [3]

Hipoteza H0 Istinita Neistinita

Odbacuje se Greška 1.vrste

(njena vjerojatnost je )

Pravilan zaključak

Prihvaća se Pravilan zaključak Greška 2.vrste

(njena vjerojatnost je )

Postoji još i pojam jakost testa, a računa se kao 1 – .

34 CASE2018

4. STATISTIČKE FUNKCIJE U ORACLE BAZI

Za razliku od Oracle Advanced Analytics (OAA) opcije, koja se posebno plaća, Oracle baza ima i statističke funkcije (SQL i PL/SQL) koje postoje u svakoj ediciji baze, pa čak i u besplatnoj ediciji (Oracle XE). Slika 8. ukratko prikazuje statističke i analitičke funkcije, raspoložive u svakoj ediciji baze (od verzije 10g).

Slika 8. Oracle SQL i PL/SQL statističke i analitičke funkcija, raspoložive u svakoj ediciji baze (od verzije 10g); Izvor: Oracle prezentacija

Sada ćemo prikazati nekoliko primjera korištenja statističkih funkcija u Oracle bazi. Poslužit ćemo se standardnom Oracle shemom HR. Shema HR ima 7 tablica (međusobno povezanih). Jedna od njih je tablica EMPLOYEES. Zamislimo da ona sadrži samo uzorak iz nekog (velikog) osnovnog skupa. Primjer 1. prikazuje neke podatke iz te tablice.

Primjer 1.

select employee_id, first_name, last_name, salary

from employees

order by employee_id;

EMPLOYEE_ID FIRST_NAME LAST_NAME SALARY

----------- -------------------- ------------------------- ----------

100 Steven King 24000

101 Neena Kochhar 17000

102 Lex De Haan 17000

...

204 Hermann Baer 10000

205 Shelley Higgins 12008

206 William Gietz 8300

Primjer 2. prikazuje upit i rezultat: minimalna i maksimalna vrijednost, medijan, mod i aritmetička sredina za vrijednosti u stupcu SALARY tablice EMPLOYEES.

Primjer 2.

select min(salary),

max(salary),

median(salary),

stats_mode(salary),

avg(salary)

from employees;

MIN(SALARY) MAX(SALARY) MEDIAN(SALARY) STATS_MODE(SALARY) AVG(SALARY)

----------- ----------- -------------- ------------------ -----------

2100 24000 6200 2500 6461.83178

Primjer 3. prikazuje procjenu varijance i standardne devijacije (korijen od varijance) na temelju uzorka (dijeli se s N – 1; razlika između STDDEV / STDDEV_SAMP je u tome što vraćaju 0 / NULL ako postoji samo jedan redak), i procjenu

CASE2018 35

standardne devijacije populacije (ako podaci sadrže cijelu populaciju; dijeli se sa N) za vrijednosti u stupcu SALARY tablice EMPLOYEES.

Primjer 3.

select variance(salary),

stddev(salary),

stddev_samp(salary),

stddev_pop(salary)

from employees;

VARIANCE(SALARY) STDDEV(SALARY) STDDEV_SAMP(SALARY) STDDEV_POP(SALARY)

---------------- -------------- ------------------- ------------------

15284813.7 3909.57973 3909.57973 3891.26778

Osim SQL funkcija, Oracle baza ima i PL/SQL paket DBMS_STATS_FUNCS, koji sadrži brojne funkcije, od kojih neke postoje i kao SQL funkcije. Paket sadrži i funkcije za provjeru "uklapanja" (prilagodbe) vrijednosti iz uzorka u određenu (teorijsku) distribuciju (distribution-fitting functions). Te funkcije testiraju koliko se dobro vrijednosti iz uzorka prilagođavaju određenoj (teorijskoj) distribuciji:

NORMAL_DIST_FIT function (prikazan u primjeru 4.) UNIFORM_DIST_FIT function POISSON_DIST_FIT function WEIBULL_DIST_FIT function EXPONENTIAL_DIST_FIT function.

Primjer 4.

DECLARE

sredina NUMBER := 6000;

sdevijacija NUMBER := 3000;

signif NUMBER := 0;

BEGIN

-- Kod normalne distribucije, 4.parametar (vrsta testa) može biti:

-- 'CHI_SQUARED', 'KOLMOGOROV_SMIRNOV’,

-- 'ANDERSON_DARLING', 'SHAPIRO_WILKS’

--

DBMS_STAT_FUNCS.NORMAL_DIST_FIT ('HR', 'EMPLOYEES', 'SALARY’,

'CHI_SQUARED', sredina, sdevijacija, signif);

DBMS_OUTPUT.PUT_LINE('Signifikantnost: ' || signif);

END;

/

X-squared value : 84.85046728971962616822429906542056074765

Degree of freedom : 15

Signifikantnost: .99999999999103495

Oracle baza ima nekoliko parametarskih testova i nekoliko neparametarskih testova. Parametarski testovi imaju neke pretpostavke, a tipična je da su podaci u osnovnom skupu distribuirani po normalnoj razdiobi.

Parametarski testovi:

T-test F-test One-Way ANOVA.

Neparametarski testovi:

Binomial test Wilcoxon Signed Ranks test Mann-Whitney test Kolmogorov-Smirnov test.

T-test se najčešće koristi za mjerenje signifikantnosti razlika aritmetičke sredine uzorka i zadane vrijednosti, ili razlika aritmetičkih sredina dvaju uzoraka.

Postoje 4 funkcije s prefiksom STATS_T_TEST_*

STATS_T_TEST_ONE: test s jednim uzorkom STATS_T_TEST_PAIRED: test između dva uzorka (paired t-test, crossed t-test) STATS_T_TEST_INDEP: test dvije nezavisne grupe s jednakom varijancom (pooled variances) STATS_T_TEST_INDEPU: test dvije nezavisne grupe s nejednakom varijancom

(unpooled variances).

Primjer 5. prikazuje T-test hipoteze o signifikantnosti razlike između aritmetičke sredine uzorka i zadane vrijednosti 6500.

Primjer 5.

select avg(salary),

36 CASE2018

STATS_T_TEST_ONE(salary, 6500, 'STATISTIC') t_statistic,

STATS_T_TEST_ONE(salary, 6500, 'TWO_SIDED_SIG') t_sig

from employees;

AVG(SALARY) T_STATISTIC T_SIG

----------- ----------- ----------

6461.83178 -.1009866 .919751863

Primjer 6. prikazuje T-test hipoteze o o (ne)jednakosti aritmetičkih sredina dvaju uzoraka – uspoređuju se prosječne plaće zaposlenika odjela 50 i odjela 80.

Primjer 6.

select avg(decode(department_id, '50', salary, null)) avg_dept50,

avg(decode(department_id, '80', salary, null)) avg_dept80,

STATS_T_TEST_PAIRED(department_id, salary, 'STATISTIC') t_stat,

STATS_T_TEST_PAIRED(department_id, salary, 'TWO_SIDED_SIG')t_sig

from employees

where department_id in ('50', '80');

AVG_DEPT50 AVG_DEPT80 T_STAT T_SIG

---------- ---------- ---------- ----------

3475.55556 8955.88235 -15.925636 3.1440E-26

Primjer 7. prikazuje F-test hipoteze o (ne)jednakosti između varijanci dvaju uzoraka – uspoređuju se varijance plaća zaposlenika u odjelima 50 i 80.

Primjer 7.

select variance(decode(department_id, '50', salary, null)) var_dept50,

variance(decode(department_id, '80', salary, null)) var_dept80,

STATS_F_TEST(department_id, salary, 'STATISTIC', 50) f_stat,

STATS_F_TEST(department_id, salary, 'TWO_SIDED_SIG') f_sig

from employees

where department_id in ('50', '80’);

VAR_DEPT50 VAR_DEPT80 F_STATISTIC F_SIG

---------- ---------- ----------- ----------

2214161.62 4135873.44 .535355264 .053026341

Primjer 8. prikazuje analizu varijance s jednim promjenljivim faktorom – analiziraju se plaće po različitim poslovima (job_id), za svaki odjel posebno (group by department_id), ali samo za odjele koji imaju više od 5 zaposlenika.

Primjer 8.

select department_id,

STATS_ONE_WAY_ANOVA(job_id, salary, 'F_RATIO') f_ratio,

STATS_ONE_WAY_ANOVA(job_id, salary, 'SIG') p_value,

avg(salary),

count(1)

from employees

group by department_id

having count(1) > 5

order by 1;

DEPARTMENT_ID F_RATIO P_VALUE AVG(SALARY) COUNT(1)

------------- ---------- ---------- ----------- ----------

30 987.842105 6.1073E-06 4150 6

50 123.493632 2.5691E-18 3475.55556 45

80 26.3968778 .00001331 8955.88235 34

100 23.7247927 .008214884 8601.33333 6

Primjer 9. prikazuje korištenje neparametarske statistike. Računa se koeficijent korelacije između trajanja zaposlenosti (u danima) i plaće.

Primjer 9.

select CORR_S(sysdate - hire_date, salary) coefficient,

CORR_S(sysdate - hire_date, salary, 'TWO_SIDED_SIG’) p_value

from employees;

CASE2018 37

COEFFICIENT P_VALUE

----------- ----------

.126235719 .195097794

Primjer 10. je također primjer neparametarske statistike. Promatra se linearna regresija između trajanja zaposlenosti (u danima) i plaće. Rezultati su nagib pravca i odsječak na osi y.

Primjer 10.

select REGR_SLOPE(sysdate - hire_date, salary) reg_slope,

REGR_INTERCEPT(sysdate - hire_date, salary) reg_intercept

from employees;

REG_SLOPE REG_INTERCEPT

---------- -------------

.063023539 4079.37252

5. ZAKLJUČAK

Oracle baza ima širok raspon alata za statističke potrebe.

Oracle Advanced Analytics (OAA) je opcija Oracle baze podataka (Enterprise Edition), što znači da se posebno plaća. OAA postoji od baze 11g i sastoji se od dva dijela:

Oracle Data Mining, koji je postojao i u prethodnim verzijama baze, 9i i 10g;

Oracle R Enterprise, koji je uveden u 11g.

Oracle Data Mining se može ukratko opisati kao skup SQL funkcija i PL/SQL paketa, koji služi za data mining unutar baze podataka (in-database data mining). Oracle R Enterprise integrira programski jezik R (koji je open source) unutar Oracle baze podataka.

Statistički jezik R se u Oracle bazi podataka može koristiti i bez ORE, ali se tada podaci iz baze moraju prebaciti na R klijent, a rezultati se (ako je potrebno) vraćaju na bazu. Time se smanjuje mogućnost obrade vrlo velikih količina podataka, i paralelizam (koji omogućuje baza podataka). No ta je varijanta jeftinija, pa i besplatna (može raditi i s XE bazom).

Postoji još jedna varijanta primjene statistike u Oracle bazi. Od baze 10g na raspolaganju je skoro 300 SQL statističkih funkcija, od kojih je većinu moguće koristiti u svim edicijama Oracle baze, pa i besplatnoj XE ediciji. U radu je prikazano desetak primjera korištenja.

Literatura:

1 DeCoursey, W.J. (2003): Statistics and Probability for Engineering Applications, Newnes, Woburn Massachusetts

2 Iličić, K. (2017): Matematičke osnove statistike, Element, Zagreb

3 Pavlić, I. (1977): Statistička teorija i primjena (2. izdanje), Tehnička knjiga, Zagreb

4 Russell, S.J. & Norvig, P. (2010): Artificial Intelligence – A Modern Approach (3. izdanje), Prentice Hall - Pearson Education, New Jersey

Oracle priručnici za bazu 12c Release 2 (2016.):

5 SQL Language Reference (E17209-14)

6 PL/SQL Packages and Types Reference (E17602-14)

7 Data Mining Concepts (E17692-13)

8 Data Mining User's Guide (E17693-13)

9 R Enterprise User's Guide (E35158-07)

Podaci o autoru:

Zlatko Sirotić, univ.spec.inf.

ISTRA TECH d.o.o., Pula

e-mail: zlatko.sirotic@istratech.hr

Autor radi skoro 35 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 28 godina). Oracle softverske alate (baza, Designer CASE, Forms 4GL, Reports, JDeveloper IDE, Java) koristi više od 20 godina. Objavljivao je stručne radove na kongresima / konferencijama CASE, KOM, HrOUG, JavaCro, "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). Na Fakultetu informatike u Puli sudjeluje (od početka osnivanja, sedam godina) kao vanjski suradnik na kolegijima Baze podataka 2 i Informatički praktikum 1.

38 CASE2018

CASE2018 39

INTERNETSKE MREŽNE IGRE, TRŽIŠTE, TRENDOVI I RAZVOJNI IZAZOVI

dr.sc. Mirko Sužnjević

KRATAK PREGLED

U ovom radu obrađuje se tema mrežnih digitalnih igara. Ukratko se opisuje stanje na tržištu s aspekta trenutnog stanja te potencijala tržišta za rast. Detaljno se obrađuje stanje po pojedinoj regiji svijeta. Osim tržišta ukratko su navedeni i opisani sljedeći trendovi vezani za digitalne igre: e-sportovi, strujanje igara, ozbiljne igre te pomak igara ka mreži. Trend pomaka ka mreži je detaljnije analiziran te je razložen na osnovne faktore koji su: višekorisničke igre, igre na društvenim mrežama, igre na mobilnim uređajima, distribucija igara te zaštita sadržaja. Svaka od ovih komponenti je detaljno opisana.

1. UVOD

Danas digitalne igre predstavljaju ogromnu industriju. Svakodnevno se milioni ljudi širom svijeta zabavljaju uz igre na mobitelima, tabletima, računalima ili posebnim konzolama specijalno izgrađenim za igranje (poput Play Station ili Xbox serije konzola). Prema podacima kompanije NewZoo koja se primarno bavi proučavanjem tržišta igara, procijenjena vrijednost tržišta igara u svijetu je 2017. godine bila 108.9 milijardi USD 1. Za usporedbu, cjelokupni proračun Republike Hrvatske je u 2017. godini iznosio 126,1 milijardi HRK (oko 20,9 milijardi USD) što čini industriju igara većom od proračuna Republike Hrvatske za više od 5 puta. Ovo ogromno tržište još uvijek ima potencijala za veliki rast, ali je potrebno detaljno proučiti njegovu strukturu kako bi se fokusiralo na ona tržišta koja imaju potencijal, ne samo u geografskom smislu već i u smisli platforme za igranje, tipa igara ciljane dobne skupine i slično. Također potrebno je identificirati i trendove industrije igara kako bi se oni iskoristili. Danas najznačajniji trend je dodatak mrežne komponente u određeni aspekt igre. Mrežna komponenta može biti uključena u distribuciju igre (primjerice sve komercijalne igre za mobitele se dostavljaju preko mreže korištenjem Apple ili Play trgovina za Apple i Android uređaje) u sam koncept igre (primjerice igre koje podržavaju više igrača ili su primarno dizajnirane kako bi ih igralo više igrača), kroz igre na društvenim mrežama koje zahtijevaju povezanost s Internetom, ili samo kroz komponentu kojom se igra spaja na mrežu radi validacije kupovine odnosno zaštite sadržaja (engl. Digital Rights Management – DRM). U ostatku rada se prvo prezentiraju karakteristike tržišta u poglavlju 2, potom osnovni trendovi u poglavlju 3 te se detaljnije razrađuje trend pomaka igara prema mreži odnosno implementaciji mrežnih karakteristika. Na kraju u poglavlju 4 se zaključuje rad.

2. TRŽIŠTE IGARA

Tržište igara je u posljednjih dvadeset godina, od male industrije vezane za relativno usku populaciju te mali broj uređaja naraslo do jedne od najvećih komponenti zabavne industrije. Prema procjenama kompanije NewZoo vrijednost tržišta igara 2017. godine bila je 108.9 milijardi USD s predviđenim stupnjem godišnjeg rasta od 7,8%. Geografski najveći dio tržišta predstavlja regija Azija-Pacifik od 47% ukupne vrijednosti i s najvećim potencijalom za rast od čak 9.2% (Slika 1). Ovaj potencijal je tu zbog broja ljudi koji su nastanjeni u ovom području (procjene su da preko 4 milijarde ljudi živi u ovom području – više nego u ostatku svijeta 3).

Slika 1 Predviđanja kompanije NewZoo vezana za veličinu tržišta igara (preuzeto s 1)

40 CASE2018

S druge strane veliki broj zemalja te regije je još u razvoju te postoji veliki potencijal za poboljšanje životnog standarda i samim tim povećanje vremena u kojem se ljudi opuštaju i prepuštaju zabavnim sadržajima. Jedini veći godišnji rast predviđen je u zemljama Južne Amerike (13.9%) koje su za sada jako mali dio tržišta sa samo 4,4 milijarde USD. Sjeverna Amerika predstavlja zreli dio tržišta u kojem je već veliki postotak stanovništva izložen digitalnim igrama te su mu iste dostupne tako da je predviđeni rast u ovoj regiji samo 4%. Kada se gledaju pojedinačne zemlje Kina je preuzela titulu najvećeg tržišta od SAD-a s 27,5 milijardi naspram 25,1 milijardi USD.

Slika 2 Tržište igara prema igraćoj platformi (preuzeto s 1)

Slika 2 predstavlja podjelu tržišta na pojedinu platformu. Mobilne platforme (mobiteli i tableti) predstavljaju najveći dio tržišta (42%) dok osobna računala (engl. personal computer – PC) i konzole drže 27% i 31% tržišta. Može se vidjeti da su veliki dio kolača PC tržišta igre namijenjene igranju u Internet pregledniku koje čine 4% sveukupnog tržišta. Prema predviđanjima kompanije NewZoo 2020. godine situacija će se dodatno pokrenuti u smjeru mobilnih platformi koje će držati 50% tržišta koje će po predviđanjima tada biti vrijedno 128,5 milijardi dolara.

U zrelim tržištima poput SAD-a očito je iz karakteristika populacije da su igre industrija koja cilja razne dobne i spolne skupine. Neke zanimljive karakteristike su 4:

Prosjek godina igrača u SAD-u je 35.

Žene koje su starije od 18 čine 31% tržišta dok muškarci mlađi od 18 čine 18% tržišta. Ova činjenica pobija uvriježene zablude da su najveći dio populacije koja igra igre maloljetni muškarci. Žene čine sveukupno 41% tržišta.

53% igrača iz skupine onih koji najčešće igraju, igraju višekorisničke igre (pri čemu provode u prosjeku 6 sati igrajući s drugim ljudima preko mreže te 5 sati igrajući s drugim ljudima uživo).

Najpopularniji žanrovi su: igre gađanja (engl. shooters) s 29%, ležerne igre (engl. casual) s 28% te akcijske igre s 27%.

2. TRENDOVI

Tržište igara je vrlo dinamično te se mijenja iz godine u godinu. Prije 20-ak godina igre iz žanra strategija u stvarnom vremenu su bile među najpopularnijima dok danas nisu ni blizu vrha ljestvice popularnosti. Zapravo popularni žanrovi se smjenjuju na razini nekoliko godina. Prije 10-ak godina senzacija su bile masivne višekorisničke igre preuzimanja uloga (engl. Massively Multiplayer Online Role-Playing Games – MMORPG), ne samo zbog svog uspjeha na tržištu nego zbog utjecaja na globalnu kulturu. Nakon toga uspjeh igara iz žanra višekorisničkih borbenih arena (engl. Multiplayer Online Battle Arena – MOBA) bio je neprikosnoven s najpopularnijom igrom – League of Legends koja je imala preko 100 milijuna registriranih korisnika aktivnih na mjesečnoj razini 5. U 2017. i 2018. godini veliku popularnost stječu igre preživljavanja na temelju „Battle Royale“ koncepta u kojem igrači se bore na određenom području za preživljavanje dok ne preostane samo jedan. Ovaj žanr igara se može podvesti pod žanr igara gađanja.

Trendovi u ovom radu neće se baviti popularnošću pojedinog žanra zbog njihove vrlo dinamične prirode već generalnim trendovima u industriji igara te njenim različitim aspektima. Trendovi koji će biti opisani su: e-sportovi, strujanje igara, ozbiljne igre te pomak igara ka mreži.

2.1 E-sportovi

E-sportovi se ukratko mogu definirati kao natjecanja u igranju igara. Mogu biti na razini natjecanja igrača jedan na jedan (popularno u primjerice igri Starcaft 2) ili natjecanja timova igrača (popularno u igrama Dota 2, League of Legends, Counter Strike, itd.). Igrači i timovi koji se bave e-sportovima imaju sponzore, mogu dobivati plaću, redovno treniraju te sudjeluju u natjecanjima u kojima mogu osvojiti velike nagrade. Popularnosti ovih natjecanja svjedoči da će prema procjenama NewZoo kompanije vrijednost tržišta e-sportova u 2018. godini dostići 905,6 milijuna USD 6. Velika natjecanja u najpopularnijim igrama prati veliki broj igrača uživo, a još puno veći putem strujanja u živo koje će detaljnije biti objašnjeno u idućem poglavlju. Turnir u igri League of Legends 2017 godine je prema oficijelnim podacima pratilo u

CASE2018 41

prosjeku 33 milijuna ljudi putem servisa za strujanje (od kojih najveći dio u Kini) 7. Nagradni fond za finalno svjetsko natjecanje u igri Dota 2 2015. godine je iznosio 18,5 milijuna USD dok je već 2017. godine narastao na 24,8 milijuna. Ovako veliki iznos nagrada za natjecanje financiran je inovativnim poslovnim modelom u kojem kompanija koja je vlasnik igre (Valve) financira natjecanje s nekom inicijalnom sumom primjerice 1 milijun USD. Ostatak novca skuplja se unutar igre prodajom virtualnih predmeta koji omogućuju gledanje igre putem strujanja kao i različite predmete u samoj igri. Kupovinom tog virtualnog predmeta igrači 25% iznosa automatski doniraju u fond za nagrade. Time kompanija koja održava sam turnir zapravo višestruko vraća inicijalno uložena sredstva.

2.2 Strujanje igara

Strujanje igara je relativno nov fenomen čiju popularnost je omogućilo sve veće prisustvo širokopojasnih mreža koje omogućuju spajanje na Internet uz velike brzine prijenosa i mala kašnjenja. Strujanje igara može se definirati kao uživi prijenos ekrana igrača (često uz dodatan prozor koji prikazuje samog igrača) preko određenog servisa za strujanje prema zainteresiranim gledateljima (najčešće drugim igračima zainteresiranima za tu igru). Dodatno, osim pojedinih igrača mogu se prenositi i igre timova s različitih natjecanja. U takvim slučajevima često postoje i voditelji i komentatori. Najpopularnija usluga ovog tipa na zapadnom tržištu je Twitch.tv koja je prodana kompaniji Amazon 2015. godine za 970 milijuna USD. Popularni događaji ili igrači mogu privući tisuće ili desetke tisuća gledatelja u prijenosu uživo. Najčešće video zapisi prijenosa se pohranjuju te im kasnije gledatelji mogu pristupiti u formi videa na zahtjev.

2.3 Ozbiljne primjene igara

Igre se mogu koristiti i u ne-zabavne svrhe. Najčešće su ozbiljne svrhe vezane za edukaciju, zdravlje, rješavanje složenih problema i slično. Što se tiče edukacijskih primjena postoje tri identificirana načina na koji se igre mogu koristiti u edukaciji 8:

1) Korištenjem komercijalnih igara u edukacijske svrhe (primjerice korištenje igre Civilization za učenje povijesti). 2) Korištenje specijalno kreiranih „ozbiljnih“ igara koje imaju određenu edukacijsku svrhu (primjerice korištenje igre Math

Playground specijalno dizajnirane za učenje matematičkih operacija). 3) Zajednička izrada jednostavnih igara – za učenje programerskih vještina.

Postoji niz različitih igara vezanih za zdravlje. S jedne strane vezano za širenje informacija o zdravlju, a u novije vrijeme i niz igara koje pokušavaju natjerati igrača da vježba kontrolirajući njegove pokrete putem kontrolera ili specijaliziranih kamera (primjerice Microsoft Kinect). Primjena takvih igara je najveća u polju fizikalne terapije 9.

Igrifikacija (engl. gamification) je proces u kojem se određeni elementi igara uvode u različite druge procese kako bi se povećala motivacija i sudjelovanje ljudi koji su uključeni u te procese, produktivnost, lakoću korištenja i slično. Primjeri igrifikacije:

Skupljanje bodova na web stranici za udaljeno obrazovanje prilikom završetka određene lekcije. Skupljanje različitih bonusa na kupovinu web stranica Dodjeljivanje postignuća prilikom postignuća određenih vrijednosti u proizvodnji/prodaji i sl.

2.4 Pomak prema mreži

Pomak prema mreži je uzrokovan različitim faktorima među kojima su:

Višekorisničke igre; Igre na društvenim mrežama; Igre na mobilnim uređajima; Distribucija igara; Zaštita sadržaja.

Višekorisničke igre kao što im ime govori omogućavaju igranje više od jednog igrača (najčešće istovremeno). Prije široke dostupnosti Interneta višekorisničke igre su se igrale na jednom računalu primjerice uz izmjenu igrača u krugovima ili uz podijeljeni ekran. Lokalne mreže su također omogućavale višekorisničko igranje, ali je njihov doseg bio mali i u smislu broja igrača kao i geografski. Tek nakon što je Internet postao dostupan većem broju korisnika višekorisničke igre su dobile značajno na popularnosti. Neke od najpopularnijih igara današnjice poput League of Legends ili Dota 2 uopće i nemaju komponentu za jednog igrača već je igra u svojoj osnovici višekorisnička.

Društvena mreža Facebook je napravila je najveći proboj te uvelike definirala tržište igara na društvenim mrežama. Tijekom godina udio Facebooka u tržištu igara je opadao te su se igre sve više selile prema mobilnim uređajima kao samostalne aplikacije. Dok je najveći dio igara za mobilne uređaje dizajniran za jednog korisnika najčešće su igre dizajnirane za više korisnika one koje najviše zarađuju. Ovo se može jednostavno provjeriti na stranicama Google Play trgovine u kojima se navode sve najprodavanije igre te one koje najviše zarađuju 9. Među najuspješnijim proizvođačima igara za mobilne uređaje svrstava se tvrtka Supercell koja je sa svoje dvije najpopularnije igre Clash of Clans i Clash Royale tijekom 2016. godine ostvarila preko 2,6 milijardi USD dolara prihoda 11

Sama distribucija igara je ubrzano posljednjih godina evoluirala od fizičkih medija ka dostavi preko Interneta. Slika 3 ilustrira kretanje udjela pojedine prodaje od 2010. do 2016. godine 12. Trend opadanja dostave kroz fizičke medije je očigledan te je očekivano da će se isti nastaviti i dalje. Uzroci ovog trenda su šira dostupnost neograničenih pristupa Internetu kroz žičane konekcije te njihova brzina koja omogućava jednostavno i brzo preuzimanje igara u digitalnom obliku kao i popularizacija igara na mobilnim uređajima na kojima se kompletna dostava sadržaja igre jedino i može napraviti putem Interneta.

42 CASE2018

Slika 3 Udio prodaje igara putem fizičkog medija digitalnom dostavom (preuzeto s 12)

3. ZAKLJUČAK

U ovom radu ukratko je opisano stanje na tržištu digitalnih igara vezano za veličinu tržišta te njegov rast. Dodatno, razmotrene su i opisane geografske karakteristike u kojoj regija Azija-Pacifik predstavlja najveći dio tržišta s velikim potencijalom za rast. Sa strane pojedine platforme prikazano je da mobilne platforme preuzimaju tržište igara i da će do 2020. godine predstavlja polovinu ukupne vrijednosti tržišta. Pokazane su karakteristike zrelog tržišta u smislu karakteristika igrača koje dokazuju da je populacija igrača vrlo heterogena s obzirom na spol i dob, odnosno da se ovom vrstom zabave služe i žene i muškarci i stari i mladi. Pregled trendova vezanih za igre pokazuje primarno pomak igara ka mreži odnosno pomak ka tome da velika većina igara ima neke funkcije vezane za mrežu. Objašnjeni su i pojmovi strujanja igara i e-sportova kao relativno novi fenomeni na ovom tržištu koji postaju sve značajniji. Prikazane su i ukratko opisane i ozbiljne primjene igara s fokusom na edukativne i zdravstvene primjene.

Reference:

1 E. McDonald, „The Global Games Market Will Reach $108.9 Billion in 2017 With Mobile Taking 42%,“ https://newzoo.com/insights/articles/the-global-games-market-will-reach-108-9-billion-in-2017-with-mobile-taking-42/

2 Ministarstvo financija, „Državni proračun 2017,“ http://www.mfin.hr/hr/drzavni-proracun-2017-godina

3 Worldmeters, „Populacija Azije,“ http://www.worldometers.info/world-population/asia-population/

4 Entertainment Software Association, „Essential facts about computer and game industry 2017,“ http://www.theesa.com/wp-content/uploads/2017/09/EF2017_Design_FinalDigital.pdf

5 P. Volk, „League of Legends now boasts over 100 million monthly active players worldwide,“ https://www.riftherald.com/2016/9/13/12865314/monthly-lol-players-2016-active-worldwide

6 J. Pannekeet, „Newzoo: Global Esports Economy Will Reach $905.6 Million in 2018 as Brand Investment Grows by 48%,“ https://newzoo.com/insights/articles/newzoo-global-esports-economy-will-reach-905-6-million-2018-brand-investment-grows-48/

7 ESC, „2017 World Championship,“ https://esc.watch/tournaments/lol/2017-world-championship

8 Stewart, J., Bleumers, L., Van Looy, J., Mariën, I., All, A., Schurmans, D., Willaert, K., De Grove, F., Jacobs, A. and Misuraca, G., 2013. The potential of digital games for empowerment and social inclusion of groups at risk of social and economic exclusion: evidence and opportunity for policy. Joint Research Centre, European Commission.

9 Geurts, L., Vanden Abeele, V., Husson, J., Windey, F., Van Overveldt, M., Annema, J.H. and Desmet, S., 2011, January. Digital games for physical therapy: fulfilling the need for calibration and adaptation. In Proceedings of the fifth international conference on Tangible, embedded, and embodied interaction (pp. 117-124). ACM.

10 Google Play Most popular games, https://play.google.com/store/apps/top/category/GAME

11 R. Cowley, „Supercell sees revenues grow to $2.3 billion in 2016 thanks to success of Clash Royale,“ http://www.pocketgamer.biz/news/65090/supercell-financials-2016/

12 J. Davidson, „Digital video game sales outselling physical by a whole lot,“ https://www.technobuffalo.com/2017/04/21/digital-video-game-sales-outselling-physical-by-a-whole-lot/

CASE2018 43

Podaci o autoru:

dr.sc. Mirko Sužnjević

Istraživač, Zavod za telekomunikacije

Fakultet elektrotehnike i računarstva

Unska 3, 10000 Zagreb

e-mail: mirko.suznjevic@fer.hr

44 CASE2018

CASE2018 45

GDPR – VAŽNOST PROCJENE RIZIKA

Velibor Božić

SAŽETAK

Dana 25. 5. 2018. stupa na snagu europska direktiva za zaštitu osobnih podataka (General Data Protection Regulatory), u daljnjem tekstu GDPR. Ova direktiva obvezna je u svim članicama EU pa tako i u Hrvatskoj. Njome se ujednačava praksa zaštite osobnih podataka u svim zemljama članicama EU. Ovo je prilično opsežan tekst u kojem se definira što je osobni podatak, kako se mora štititi i još mnogo stvari. Suština dokumenta je zaštita osobnih podataka te osiguravanje pristupačnosti, integriteta i povjerljivosti osobnih podataka. Ovaj rad će pokušati dati odgovore na pitanje kako da se organizacije pripreme za GDPR, prvenstveno kako da osiguraju pristupačnost podataka, njihov integritet i povjerljivost. U tom kontekstu bit će govora o rizicima vezanim uz nepoštivanje GDPR-a. Bit će objašnjen kontekst rizika, vrste rizika, način upravljanja rizicima i njihovo smanjivanje na prihvatljivu razinu.

Ključne riječi: GDPR, upravljanje sigurnošću informacija, rizici, upravljanje rizicima.

1. ŠTO JE GDPR?

General Dana Protection Regulatory (GDPR) je dokument donesen na razini Europske unije (27. 4. 2016.) koji regulira osnovna načela zaštite osobnih podataka. Na hrvatskom jeziku to bi bila Opća uredba o zaštiti osobnih podataka. Ovaj dokument posljedica je neujednačene prakse zaštite osobnih podataka u zemljama europske unije. Zbog te neujednačene prakse europski parlament i europska komisija donjeli su spomenutu uredbu koju ćemo u tekstu zvati GDPR. GDPR je prilično glomazan dokument koji ima sedam osnovnih načela i to:

Odgovornost u procesu Ograničavanje svrhe obrade Zakonitost i transparentnost prikupljanja podataka Optimizacija količine podataka Točnost i ažurnost padataka Ograničavanje trajanja pohrane Povjerljivost i integritet podataka.

Kroz sva ova načela se provlači osnovna ideja, a to je:

Sprečavanje narušavanja povjerljivosti i integriteta osobnih podataka Sprečavanje neovlaštene dostupnosti podataka te osiguravanje nesmetane i kontinuirane dostupnosti podataka

onima koji imaju ovlaštenja

Iz osnovne ideje GDPR-a može se zaključiti da se organizacije najbolje mogu pripremiti za GDPR primjenom ISO standarda za informacijsku sigurnost 27001 (u zdravstvu to je ISO 27799, inačica ISO standarda za informacijsku sigurnost posebno namijenjena zdravstvenim ustanovama). Bitan dio zadovoljavanja zahtjeva za informacijskom sigurnošću jest uvođenje organizacijskih (upravljačkih), logičkih i fizičkih kontrola. Kako bi se uvele učinkovite i djelotvorne kontrole, potrebno je procijeniti ranjivosti sustava te prijetnje koje mogu iskoristiti te prijetnje. Kao funkcija ranjivosti i prijetnji nastaje rizik. Rizicima se treba na pravi način upravljati i upravo o tome, upravljanju rizicima u kontekstu GDPR-a, nešto više u nastavku.

2. INFORMACIJSKA SIGURNOST

Temeljni je cilj informacijske sigurnosti zaštita povjerljivosti, dostupnosti i integriteta osobnih podataka U zaštiti informacija potrebno je voditi računa o svim elementima sustava – korisnicima (npr. Pacijentima u zdravstvu), javnosti, zaposlenicima, poštivanju zakona i propisa, upravi, nadzoru (upravnom vijeću, nadzornim odborima). Svi sudionici sustava moraju biti na neki način zadovoljeni u kontekstu zaštite integriteta, te povjerljivosti i dostupnosti informacija. Prilikom zaštite podataka potrebno je voditi računa o riziku.

3. RIZICI SIGURNOSTI PODATAKA

Na povjerljivost, dostupnost i integritet podataka mogu utjecati mnogi faktori koji proizlaze iz ranjivosti sustava. Rizik nastaje zbog prijetnje sigurnosti koja proizlazi iz ranjivosti sustava i zbog razmjera posljedica po sustav koju ta prijetnja može prouzročiti. Zaštitom informacija (osobnih podataka u kontekstu GDPRa) rizik se mora smanjiti na prihvatljivu mjeru.

46 CASE2018

4. BIT UPRAVLJANJA ZAŠTITOM INFORMACIJSKIH SUSTAVA (O ČEMU SE TU RADI?)

Povjerljivost, dostupnost i integritet informacija izloženi su riziku. Na povećanje rizika izravno utječu prijetnje sustavu. Prijetnje iskorištavaju ranjivost sustava. Ranjivost sustava također povećava rizik. Ranjivost sustava omogućuje izloženost imovine sustava (informacija u ovom kontekstu). Imovina sustava ima određenu vrijednost koja utječe na cjelokupnu organizaciju.

Rizik direktno utječe na vrijednost imovine tako što ju smanjuje. Organizacija (bolnica u našem slučaju) ima određene sigurnosne zahtjeve. Ti sigurnosni zahtjevi se ispunjavaju kroz određene kontrole. Kontrole su ključne za smanjivanje rizika (zadovoljavanje zahtjeva za povjerljivošću, dostupnošću i integritetom informacija). Kontrole pomažu zaštiti protiv prijetnji prema sustavu. Time je krug zaštite sustava zatvoren.

CASE2018 47

5. ULOGE KOD UPRAVLJANJA RIZICIMA (kao osnove za osiguravanje informacijske sigurnosti)

Uloga uprave (top menadžment) kod upravljanja rizikom:

procjena prirode rizika i definiranje razine do koje se razina rizika mora smanjiti kako bi bio prihvatljiv za poslovanje procjena vjerojatnosti pojave rizika određivanje načina upravljanja s neprihvatljivim rizicima definiranje sposobnosti poduzeća da minimalizira vjerojatnost pojave prijetnji i njihovog utjecaja na poslovanje identificiranje troškova i koristi od rizika te određivanje kontrolnih aktivnosti definiranje kriterija za mjerenje učinkovitosti borbe protiv rizika razmatranje utjecaja rizika na odluke uprave.

Uloge izvršnih direktora (članovi stručnog vijeća u bolnici; srednji menadžment):

odgovornost za dnevno provođenje upravljanja rizikom širenje svjesnosti o riziku unutar područja kojim rukovode upoznavanje zaposlenika s ciljevima upravljanja rizicima osiguravanje modela da upravljanje rizikom postane jednakopravna tema sa svim ostalim temama na sastancima

menadžmenta uključivanje upravljanja rizikom u bilo koji od projekata kao jedne od njegovih faza bez koje ne može biti uspješno

realiziran.

Osim navedenih uloga, uprava i izvršni direktori zajednički imaju ulogu osigurati djelotvorno i učinkovito upravljanje rizikom:

usvojiti politiku i strategiju upravljanja rizikom definirati upravljanje rizikom na strateškoj i operativnoj razini stvoriti kulturu svjesnosti postojanja rizika u poduzeću osigurati procese nadgledanja rizika koordinirati aktivnosti u poduzeću koje su povezane s upravljanjem rizikom razvijati odgovore na rizik (što napraviti ukoliko se rizik ostvari – programi kontinuiteta poslovanja) pripremiti izvješća o rizicima prema vlasnicima i svima ostalima koji su zainteresirani za poslovanje.

Za učinkovito upravljanje rizicima u poduzeću potrebno je osigurati internu kontrolu. Uloge interne kontrole:

kontroliranje upravljanja kritičnim rizicima (koje identificira menadžment) ukazivanje na eventualne propuste u procesu upravljanja pomoć kod identifikacije rizika koordiniranje izvješća o riziku prema upravi i vlasnicima

6. KRITIČNI FAKTORI USPJEHA ZA POSTIZANJE INFORMACIJSKE SIGURNOSTI

postojanje politike informacijske sigurnosti, ciljeva i aktivnosti koji su odraz poslovnih ciljeva definiranje pristupa ka stvaranju, održavanju, nadzoru i unapređenju informacijske sigurnosti koji je u skladu s

organizacijskom kulturom vidljiva podrška i posvećenost svim razinama menadžmenta dobro razumijevanje zahtijeva informacijsku sigurnost, procjenu rizika, upravljanje rizicima učinkovito informiranje o informacijskoj sigurnosti svih menadžera, zaposlenika i svih drugih zainteresiranih (dioničari,

partneri…) distribucija vodiča za informacijsku sigurnost (zasnovanog na politici i standardu) svima u organizaciji stvaranje i povećavanje fonda aktivnosti za ostvarivanje informacijske sigurnosti omogućavanje stvaranja „kulture rizika”, edukacije i treninga uspostavljanje učinkovitog upravljanja incidentima kod informacijske sigurnosti implementacija sustava mjerenja kojim se procjenjuje izvedba upravljanja informacijskom sigurnošću (povratna

informacija za unapređenje čitavog procesa)

7. SPECIFIČNE PRIJETNJE INFORMACIJSKOJ SIGURNOSTI

neovlašteni pristup podacima iznutra i izvana (ostanak u programu nakon prestanka rada – druga osoba koristi program pod tuđom lozinkom; narušena povjerljivost i integritet)

neautorizirana uporaba zdravstvenog informacijskog sustava – loša identifikacija i autentifikacija korisnika, loša kontrola pristupa i upravljanje privilegijama

otvorenost prema malicioznom softveru (virusi, trojanci, crvi…) upadi u komunikaciju i uništenje poruka odbijanje prijema ili slanja osjetljivih informacija zbog nepostojanja digitalnog potpisa greške kod povezivanja na mrežne servise (npr. plaćanje putem Centralnog zdravstvenog informacijskog sustava

Republike Hrvatske – CEZIH) nehotično slanje osjetljivih podataka na krive adrese tehničke greške (serveri, mreža, kompjutori…) nepostojanje rezervnih varijanti kod nestanka struje, požara, poplava… greške u funkcioniranju sustava – nemogućnost korištenja servisa greške u funkcioniranju aplikacijskog softvera greške operatera (sustav administratora, mrežnih administratora) greške u održavanju

48 CASE2018

greške korisnika manjak osoblja krađe podataka unutar organizacije/izvan organizacije namjerno uništenje opreme iznutra i izvana terorizam

8. INFORMACIJE KOJE SE TREBAJU ZAŠTITITI (OSOBNI PODACI U KONTEKSTU GDPR-A)

Postoji nekoliko tipova informacija čije se dostupnost, integritet i pouzdanost trebaju štititi. To su:

osobne informacije o korisnicima (npr. pacijenatima) pseudoinformacije o korisnicima (npr. pacijentima) generirane za potrebe nekih istraživanja informacije prikupljane za potrebe statističkih istraživanja, uključujući i anonimne informacije izvedene iz osobnih

zdravstvenih informacija (u kojima nema identifikacijskih podataka) informacije o djelatnicima informacije vezane uz javni nadzor informacije vezane uz sudske procese povezane s korisnicima (npr.s liječenjem pacijenata)

Primjer osobnih podataka u zdravstvu koji se moraju štititi (članak 4., 9., 23., 35., 45., 52-54.,63., 65., 71., 73., 75., 88., 91., 112., 121., 155., 159. u GDPRu):

• osobni podaci o zdravlju pacijenata (elektronički zdravstveni karton) • podaci o pacijentima unutar kojih je identifikacija pacijenta onemogućena kriptografijom (za potrebe statističkih obrada) • ostali medicinski podaci za potrebe statistike (podaci koji nisu nužno vezani uz pacijente) • medicinski podaci koji nisu vezani uz pacijente (npr. podaci o reakcijama na lijekove, o bolničkim infekcijama i sl.) • podaci o medicinskom osoblju i liječnicima • podaci vezani uz javno zdravstvo • kontrolni podaci, derivirani iz bolničkog informacijskog sustava • podaci o lozinkama, korisničkim imenima, tj. podaci bitni za provođenje kontrole povjerljivosti, integriteta i dostupnosti.

9. ETAPE I POSTUPCI IZGRADNJE SUSTAVA UPRAVLJANJA INFORMACIJSKOM SIGURNOŠĆU – KAKO ISPUNITI ZAHTJEVE GDPRa

Da bi se ispunili zahtjevi GDPR-a potrebno je izgraditi sustav za upravljanje informacijskom sigurnošću. Izgradnja tog sustava treba pratiti tzv. Demingov ili PDCA (Plan-Do_Check-Act) krug. U nastavku ukratko, što sve treba raditi u svakoj fazi izgradnje sustava za upravljanje informacijskom sigurnošću.

Planiranje

Korak 1: Definiranje područja djelovanja sustava za upravljanje infomacijskom sigurnošću informacija

Korak 2: Planiranje politika unutar sustava za upravljanje infomacijskom sigurnošću

Korak 3: Planiranje sustavnog pristupa procjeni rizika

Korak 4: Identifikacija rizika (procjena faktora rizika i informacijske imovine)

Korak 5: Izvedba procjene rizika

Korak 6: Planiranje odnosa prema riziku

Korak 7: Izbor upravljačkog cilja i kontrola

Korak 8: Priprema „Izjave o prihvatljivosti“

Korak 9: Priznavanje preostalog rizika i omogućavanje funkcioniranja sustava upravljanja informacijskom sigurnošću

Dokumentacija: opis sustava koji se prati, identificirana sigurnosna politika, dijagram upravljačke strukture sustava za upravljanje informacijskom sigurnošću (tko je za što odgovoran), procedure identifikacije informacijske imovine, popis informacijske imovine, lista rizika, procedure procjene rizika, izvješće o procjeni rizika, procedure tretiranja rizika, izvješće o tretiranju rizika, plan tretiranja (odnosa prema) rizika, kriteriji mjerenja informacijske sigurnosti, izjava o prihvatljivosti.

Izrada

Korak 1: Izvođenje postupka smanjivanja rizika

Korak 2: Alociranje poslovnih resursa od strane menadžmenta

Korak 3: Uporaba kontrole (planiranje potrebnih procedura)

Korak 4: Izvedba obuke i treninga

Korak 5: Upravljanje operacijama

Korak 6: Upravljanje poslovnim resursima

Korak 7: Definiranje akcija u slučaju pojave sigurnosnih incidenata

Dokumentacija: plan za tretiranje rizika, plan za sustav zaštite informacija, plan kontinuiteta poslovnih informacija, plan edukacije i treninga, priručnik procedura za edukaciju i trening, procedure za upravljanje dokumentima o zaštiti informacija, izvješća o provedenom treningu i edukaciji, o provedenim sigurnosnim operacijama, plan za mjerenje ozbiljnosti sigurnosnih incidenata, izvješće o mjerenjima sigurnosnih incidenata.

CASE2018 49

Provjera

Korak 1: Nadgledanje procedura i kontrola

Korak 2: Nadzor nad sustavom upravljanja informacijske sigurnosti (nadzor učinaka sustava, preostalog i prihvatljivog rizika).

Korak 3: Izvješće za upravu

Dokumentacija: plan, procedure i liste provjere internog audita (kontrole); izvješća o treningu i edukacijama u vezi sa sustavom upravljanja informacijskom sigurnošću, izvješća o operacijama povećanja informacijske sigurnosti, izvješća o mjerilima kojima se određuje ozbiljnost informacijskih incidenata, izvješća internih audita; zapisnici sa sastanaka na kojima se izvješćuje uprava o poduzetim radnjama, zapisnici sa sastanaka radne skupine za uspostavu sustava upravljanja informacijskom sigurnošću.

Korekcija (djelovanje)

Korak 1: Definirati mjere poboljšanja sustava sigurnosti informacija (korektivne i preventivne akcije)

Korak 2: Raspraviti kroz organizaciju o akcijama koje se poduzimaju.

Dokumentacija: plan odnosa prema rizicima (prihvaćanje, izbjegavanje, smanjivanje ili prenošenje rizika), korekcijske i preventivne procedure.

U fazi planiranja (u koracima 3-9), u fazi izrade u koraku 1, u fazi provjere u trećem koraku te u fazi korekcije u oba koraka, potrebno je upravljati rizicima. U osnovi upravljanje rizicima prikazano je na slici:

Potrebno je izraditi registar rizika. Svaki rizik mora se opisati. Jedan od prijedloga je slijedeći

Svaki rizik funkcija je vjerojatnosti pojave prijetnje te utjecaja prijetnje na ranjivost sustava. Procjena rizika sigurnosti informacija i njihov tretman osnova je za postavljanje okvira informacijske sigurnosti. Kroz identifikaciju, kvantifikaciju, određivanje važnosti rizika te određivanje odgovora na rizik, određuju se aktivnosti i prioriteti za upravljanje informacijskom sigurnošću.

Registar rizika (u kontekstu kvantifikacije rizika):

50 CASE2018

10. ISO 27001:2016 (ISO 27799:2016) – standard informacijske sigurnosti

Ovaj standard je preduvjet za izgradnju kvalitetnog sustava za izgradnju informacijske sigurnosti, a samim tim i zadovoljavanje zahtjeva GDPR-a. U nastavku, ukratko o standardu.

Standard ima 11 područja i 39 ciljeva.

1. Politika informacijske sigurnosti

izrada dokumenta informacijske sigurnosti

pregled dokumenta informacijske sigurnosti (i promjena ako je potrebno)

2. Organizacija informacijske sigurnosti

Unutarnja organizacija

posvećenost menadžmenta informacijskoj sigurnosti

koordinacija informacijske sigurnosti

podjela odgovornosti za informacijsku sigurnost

autorizacija procesa obrade informacija od strane odgovornih

ugovori o povjerljivosti

komunikacija sa stručnjacima

komunikacija s interesnim grupama

neovisna ocjena informacijske sigurnosti

Vanjska organizacija

identifikacija rizika povezanih s vanjskim partnerima

određivanje rizika kada omogućujemo partnerima pristup do organizacijske imovine

određivanje mjera sigurnosti u ugovorima o outsourcingu

3. Upravljanje imovinom

Odgovornost za imovinu

inventura imovine vlasništvo nad imovinom prihvatljiva uporaba imovine

Klasifikacija informacija

vodič za klasifikaciju (kako klasificirati informacije u kategorijama njihove vrijednosti, osjetljivosti, važnosti za organizaciju)

upravljanje i označavanje informacija

4. Pouzdanost ljudskih resursa

Aktivnosti prije zaposlenja

uloge i odgovornosti nadzor (provjera zaposlenika) uvjeti zaposlenja

Aktivnosti za vrijeme zaposlenja

odgovornost menadžmenta da upozna zaposlenika s politikom informacijske sigurnosti razvijanje svijesti, trening i edukacija o informacijskoj sigurnosti disciplinski postupak za kršenje sigurnosti završetak ili promjena posla odgovornosti kod završetka rada povrat imovine gašenje prava pristupa

CASE2018 51

5. Fizička sigurnost i sigurnost okoline

Sigurna područja

definiranje fizičkih sigurnosnih barijera fizička kontrola ulaza sigurne sobe, uredi i sl. (sistemska soba) zaštita protiv vanjskih prijetnji i prijetnji iz okoline rad u sigurnim područjima pristup javnosti, područja isporuke

Sigurnost opreme

smještaj i zaštita opreme usluge podrške (napajanje, strujom, zaštita od požara, klimatizacija…) sigurnost kablova održavanje opreme održavanje rezervne opreme sigurno odlaganje i ponovna uporaba opreme

Izuzimanje opreme (uklanjanje opreme mora biti autorizirano)

6. Upravljanje komunikacijama i operativom

Operativne procedure i odgovornosti

dokumentirane operativne procedure upravljanje promjenama podjela dužnosti odvajanje funkcija razvoja, testiranja i operacija

Upravljanje isporukama outsourcinga

isporuka usluga (SLA-ugovori) nadzor i izvješćivanje o uslugama outsourcinga upravljanje promjenama usluga outsourcinga

Planiranje i prihvaćanje sustava (minimizacija rizika od sustavnih grešaka)

upravljanje kapacitetima (kontrolirana uporaba resursa) prihvaćanje sustava (novi IS, nove verzije, promjene…)

Zaštita od malicioznog i mobilnog koda

kontrole protiv malicioznog koda kontrole protiv mobilnog koda

Backup

sigurnosne kopije informacija upravljanje sigurnošću mreže kontrola mreže sigurnost mrežnih servisa

Upravljanje medijima

upravljanje prijenosnim medijima odlaganje medija procedure upravljanja informacijama sigurnost informacija o sustavu

Razmjena informacija

politika i procedure razmjene informacija ugovori o razmjeni (misli se na partnere izvan organizacije) osiguranje fizičkih medija u tranzitu definiranje elektroničkih poruka način razvoja poslovnih informacijskih sustava

Usluge elektroničke trgovine

zaštita elektroničke trgovine on-line transakcije javno dostupne informacije

Nadzor

zapisi kontrola definiranje uporabe informacija nadzora u sustavu zaštita zapisa o nadzoru postojanje zapisa administratora i operatera zapisi o greškama sinkronizacija vremena

7. Kontrola pristupa

Poslovni zahtjevi za kontrolu pristupa

politika kontrole pristupa

Upravljanje korisničkim pristupom

registracija korisnika

52 CASE2018

upravljanje privilegijama upravljanje korisničkim lozinkama pregled korisničkih prava

Odgovornost korisnika

uporaba lozinki oprema korisnika pravilno zaštićena zaštita osjetljivih informacija na radnom stolu i kompjutoru

Kontrola pristupa mreži

politika uporabe mrežnih servisa autentifikacija korisnika kod vanjskog pristupa identifikacija opreme na mreži daljinska dijagnostika i konfiguracija mrežnih ulaza (mora biti pod kontrolom) podjela mreže na manje segmente radi lakšeg upravljanja kontrola usmjeravanja mreže

Kontrola pristupa operacijskom sustavu

procedure sigurne prijave korisnička identifikacija i autentifikacija sustav upravljanja lozinkama uporaba sistemskih servisa vremensko ograničenje sesija

Kontrola pristupa aplikacijama i informacijama

ograničenje pristupa informacijama izolacija osjetljivih sustava

Mobilno računalstvo i rad na daljinu

definiranje uvjeta mobilnog računalstva i komunikacija definiranje uvjeta rada na daljinu

8. Nabavka, razvoj i održavanje informacijskih sustava

Sigurnosni zahtjevi informacijskih sustava

specifikacija i analiza sigurnosnih zahtjeva

Pravilno procesiranje u aplikacijama

validacija ulaznih podataka kontrola internih procesa integritet poruka validacija izlaznih podataka

Kriptografske kontrole

politika uporabe kriptografskih kontrola upravljanje ključevima za kriptografsku zaštitu

Sigurnost sistemskih datoteka

kontrola operativnog softvera (softvera u okviru operacijskog sustava) zaštita testnih, sistemskih podataka kontrola pristupa u programski izvorni kod

Sigurnost u razvoju i podršci procesa

procedure kontrola promjene tehnički pregled aplikacija nakon promjena ograničenja promjena aplikacija sprječavanje curenja informacija kontrola razvoja aplikacija u outsourcing

Upravljanje tehničkom ranjivošću

kontrole tehničke ranjivosti

9. Upravljanje incidentima informacijske sigurnosti

Izvješćivanje o događajima i slabostima unutar informacijske sigurnosti

izvješćivanje o događajima vezanim uz informacijsku sigurnost izvješćivanje o sigurnosnim slabostima Upravljanje incidentima informacijske sigurnosti i unapređivanje tog

upravljanja definiranje procedura i odgovornosti učenje iz incidenata skupljanje dokaza

10. Aspekti informacijske sigurnosti kod upravljanja kontinuitetom poslovanja

uključivanje informacija o informacijskoj sigurnosti u proces upravljanja kontinuitetom poslovanja procjena rizika i kontinuitet poslovanja postavljanje okvira za planiranje kontinuiteta poslovanja testiranje, održavanje i ponovna procjena planova za kontinuitet poslovanja

11. Uskladivost

sukladnost sa zakonskim zahtjevima

CASE2018 53

identifikacija primjenjive legislative prava na intelektualno vlasništvo zaštita organizacijskih zapisa zaštita podataka i osobito osobnih podataka prevencija pogrešne uporabe obrade informacija regulacija kriptografskih kontrola Sukladnost sa sigurnosnim politikama i standardima i tehnička usklađenost sukladnost sa sigurnosnim politikama i standardima provjera tehničke uskladivosti sa sigurnosnim standardima Razmatranja o kontroli informacijskih sustava kontrole nadzora informacijskih sustava zaštita alata za kontrolu informacijskih sustava (specijalni softver ili podaci)

11. ZAKLJUČAK

Ispunjavanje zahtjeva GDPR-a zahtjeva angažiranost cijele organizacije, od top menadžmenta do neposrednih izvršitelja. Treba se krenuti od upravljanja rizicima. Upravljanje rizicima je osnova izgradnje sustava za upravljanje informacijskom sigurnošću. Da bi se taj sustav izgradio potrebno je implementirati načela ISO 27001 standarda. Uvođenjem načela ISO 27001 standarda, ispunjavaju se i načela GDPR-a.

Literatura:

1 N. Markovinović, GDPR-izazovi za menadžere i poslovne analitičare,“Kontroling, financije, menadžment, Broj 4, 2017.

2 V. Božić, Upravljanje informacijskom sigurnošću, „MEDIX“, Broj 101/ 102, 2012.

3 UREDBA (EU) 2016/679 EUROPSKOG PARLAMENTA I VIJEĆA od 27. travnja 2016. o zaštiti pojedinaca u vezi s obradom osobnih podataka i o slobodnom kretanju takvih podataka te o stavljanju izvan snage Direktive 95/46/EZ (Opća uredba o zaštiti podataka) (Tekst značajan za EGP); preuzeto: 27. 4. 2017.

Podaci o autoru:

Velibor Božić

Opća bolnica "Dr. Tomislav Bardek" Koprivnica

Željka Selingera 1, 48000 Koprivnica

e-mail: informatika@obkoprivnica.hr

54 CASE2018

CASE2018 55

ANALIZA JAVNO DOSTPUNIH ALATA ZA RAZVOJ IGRE

Daniel Marković, dr.sc. Marin Kaluža, mr.sc. Bernard Vukelić

SAŽETAK

Na tržištu je dostupan veći broj različitih alata (engine-a) za razvoj 2D, 3D, i VR igara. Neki alati koje koriste vodeće kompanije u razvoju igara ili nisu dostupni na tržištu, ili su komercijalni. Postoje i besplatni ili javno dostupni alati za razvoj igara. Koji alat omogućuje bolje funkcionalnosti? S kojim alatom je moguće lakše razvijati igru? Kojim modelom razvoja se koristiti u razvoju igre? To su neka pitanja developer-a pri razvoju igre.

U radu će se objasniti spiralni model i primjena u procesu razvoja igre. Pokazati će se potrebne funkcionalnosti koje bi trebao sadržavati alat za razvoj igre. Prikazati će se vrste igara koje se mogu izrađivati pomoću alata. Objasniti će se neki javno dostupni alati za razvoj igara. Provesti će se analiza potrebnih funkcionalnosti za razvoj igre na često korištenim javno dostupnim alatima. Na istim alatima analizirat će se mogućnost izrade igre spiralnim modelom razvoja.

Ključne riječi: engine, igra, razvoj, alat, materijali

1. UVOD

Ovaj rad se bavi pregledom ponuđenih alata za izradu igara za različite platforme. Proučit će se koji alat ima svoje prednosti u razvoju 2D, 3D i VR(Virtual Reality) igara, gdje je ponuđeno najviše besplatnih modela za korištenje u igri, te količina tutoriala i pomoći pri razvoju. Moguće je da jedan ili dva alata uspiju zadovoljiti sve kriterije, dok neki mogu zadovoljiti samo neke zbog jednostavnije primjene ili izrade npr. samo jedne vrste igara kao što su 2D igre.

Istraživanje bi trebalo pomoći novim korisnicima za lakšu odluku u korištenju alata za izradu svoje igre, te pronalaženje drugih opcija osim 2 najpoznatija ponuđaća takvog software-a. Kako bi provjerili pojedine dijelove alata i mogućnost izrade moraju zadovoljiti kriterije igre, a to su: 2D pogled, 3D modeli u igri, animacije, kolizije i gravitacija u okruženju.

Svrha je pronalaženje ponuđaća alata s kojim je moguće od zamišljanja ideje sve do njene komercijalizacije izvesti sve korake bez mijenjanja alata ili dodatnog učenja nekog third-party software-a. Prikazat će se da postoje alati koji omogućuju razvoj 2D, 3D i VR igara koristeći spiralnu metodologiju, te omogućuju pračenje igre kroz sve životne cikluse.

1.1 Metodologije u razvoju

Spiralni model za razvoj igara je jednostavna i elegantna tehnika koja se obično koristi za razvoj igre učinkovito. Neiskusni razvojni programeri igara skloni su dizajnu igre s puno mogućnosti, a zatim ih počnu primjenjivati bez ikakvog prioriteta. Uvijek je dobra praksa da se definira: koje značajke trebaj razviti prvo, a koje treba razviti kasnije.

Ovaj model može dovesti do problema. Na primjer, što ako se dođe do spoznaje da neke značajke koje su implementirane ne funkcioniraju kako je očekivano u fazi nakon proizvodnje?

Postoji mogućnost povratka u fazu dizajna kako bi se redizajnirala takva značajka koja nije dobro funkcionirala, a zatim je potrebno podešavanje koda tako da odgovara toj novoj značajki. Zbog toga je vodopadni model dobar i učinkovit samo za vrlo mali projekt. Kako bi se izbjegle takve situacije može se koristiti razvojna tehnika nazvana spiralni model.

Slika 1.: Spiralni model

56 CASE2018

Spiralni model pri korištenju:

Ovaj model omogućuje fleksibilnost i interaktivnost u razvojnom procesu videoigre. Prvi korak ciklusa spiralnog modela je faza Dizajna:

Dizajn: Ovdje se definiraju značajke koje će se razviti u sljedećem ciklusu. Implementacija: Ovdje se mogu razviti značajke koje su prošle fazu dizajna. Playtest: U ovoj fazi je potrebno pobrinuti se da je ono što je napravljeno zabavno za igrača. Procijenite: Završne misli o tome što je učinjeno ispravno i pogrešno tijekom proteklog ciklusa, stvaranje novog skupa

problema ili grešaka koje su pronađene, te povrat na početni korak.

Proces posjeduje puno prednosti:

1. Držite rizike što je moguće niže.

Ako se otkrije da nešto planirano ne funkcionira kako se očekuje u fazi projektiranja, moguće su promijene u sljedećem ciklusu.

2. Početak s osnovnim značajkama.

Prvi ciklusi procesa razvoja igre bit će posvećen razvoju osnovnih značajki igre. To će omogućiti otkrivanje grešaka što prije, ako nešto nije dobro s jezgrom igre tj. ako postoji greška u mehanici igre.

3. Izraditi prototip što brže.

Glavni cilj kada se razvija vlastita igra, to je što je prije moguće dobiti prototip koji se može igrati. Kada se odluči o osnovnim značajkama igre, pratit će se prve iteracije kako bi ih razvili. Na kraju prvog ciklusa, završit će se igranim prototipom koji se može upotrijebiti za procjenu jezgre igre i možda, ako postoje neke promjene, to se može učiniti u sljedećim ciklusima.

Ovaj ciklus pokazuje kako se dobije prototip što brže moguće, a svaki će ciklus voditi do novog prototipa s novim značajkama, taj će se ciklus nastaviti dok ne proizađe operativni prototip sa svim minimalnim vrijednostima unaprijed određenih značajki.

4. Može se upotrijebiti s „Scrum“.

Spiralni model se lako može koristiti uz tehniku „Scrum“. To može pomoći povećati produktivnost i učinkovitost u razvojnom procesu. U osnovi, svaki plan može biti povezan s razvojnim ciklusom spiralnog modela.

5. Dopušta brze izmjene.

Jeste li nešto pogriješili u prošlom ciklusu razvoja? Ili možda samo odlučite promijeniti ili dodati novu značajku u svoju igru? Nema problema, moguće je dodati u sljedećem razvojnom ciklusu.

Zadnji ciklusi ne dopuštaju velike promjene:

Ako se gradnja igre usporedi procesu izgradnje kuće, svaki ciklus odgovara izgradnji nekog dijela kuće počeviši od temelja, pa prema krovu. Ako se namjerava izgraditi kuća s 3 etaže, nakon 3 etaže nije moguće izgraditi neboder, jer prethodni dijelovi nisu pogodni za dodatne katove, isto vrijedi i za razvoj softvera/igre.

Zahvaljujući spiralnom modelu, igra se može lako mijenjati i prilagođavati, posebno u prvim ciklusima, kasnije, kada se osmisli i razvije bitne značajke jezgre, bit će teže napraviti velike promjene, a to je kraj koji dovodi do jednostavnog zaključak: provodi se više vremena sa razmišljanjem u fazi dizajna, posebno na prvim razvojnim ciklusima, jer to su najvažniji ciklusi igre, to su ciklusi u kojima se odlučuje o osnovnim značajkama, nakon što su izgrađene, može se izgraditi ostatak (http://gamedevelopertips.com/spiral-model-for-game-development/, 2017.).

1.2 Temeljne funkcionalnosti

Svaki engine se sastoji od više različitih alata koji mogu upravljati svim podatcima koji su potrebni za izradu jedne igre, zato je potrebno da sadrže ove temeljne funkcionalnosti:

1. Grafički-engine – on je zaslužan za grafički prikaz na monitoru, grafički engine većinom sadrži:

Funkcije za učitavanje, upravljanje i prikaz tekstura prikaz efekata kao eksplozije, vatra, voda, snijeg, magla... ako se radi o 3D engine-u dolaze još: funkcije za učitavanje, upravljanje, prikaz i animiranje 3D-modela i

„Shader“ sustav za što realističniji prikaz svjetlosti i sjena na različite materijale(npr. željezo, drvo i koža)

2. Sustav za fiziku – današnje igre posjeduju što realističniji sustav za fiziku, što osim pored boljeg vizualnog prikaza, može imati i utjecaj na način igranja igre, primjer bačeni objekt(npr. bacanje granate) da li se taj predmet kada je bačen kotrlja niz brdo. Može se razlikovati između različitih vrsta fizike:

jako raširena „Rigid-Body“- fizika koja je prikaz Newton-ove mehanike na čvrsta tijela „Ragdoll“ – fizika gdje virtualni likovi padaju fizički ispravno neke igre simuliraju i mekana tijela(npr. odjeća, zastave) ili tekučina(voda)

3. Zvučni sustav – u današnje vrijeme skoro svi alati podržavaju 5.1 ili 7.1 „surround“ zvuk i tehnologije kao što su EAX, te određeni računalni hardware.

4. Spremanje stanja – kako bi se spremao prijeđeni dio tj. što se ostvari u igri, postoje dva načina:

serijalizacija predmetnog stabla: svi predmeti, njihova stanja i veze se spremaju samo se spremaju pojedini podatci. Prednost su male datoteke koje se mogu spremiti i na eksterne diskove.

Nedostatak je količina rada tj. programiranja, jer programeri moraju točno odrediti što se sprema.

5. Upravljanje – ne precizno upravljanje brzo je donijelo nezadovoljstvo i frustracije kod igrača, te za različite žanre postoji uređaj koji je prilagođen tom stilu igranja(npr. sportske igre, za njih su prikladni upravljači)

CASE2018 57

6. Upravljanje podatcima – za učitavanje i spremanje stanja igre potrebno je upravljanje tim podatcima, alati posjeduju:

učitavanje podataka iz zapakiranih datoteka upravljanje spremanjem podataka

7. Skriptanje – služe za programiranje tijeka igre, te prednost nad klasičnim programiranjem su:

skriptanje je lakše naučiti za dizajnere igara koji nisu profesionalni programeri skriptanje se može iterativno izvesti prilikom izvedbe programa, što skračuje vrijeme razvijanja „Game-engine“ postaje više univerzalan i može se proširiti i od strane korisnika

(https://de.wikipedia.org/wiki/Spiel-Engine, 2017.).

2. ANALIZA POSTUPKA IZRADE IGRE NA PLATFORMI

Ovo poglavlje će služiti za analiziranje svakog alata i to kroz unaprijed postavljena očekivanja. Svaki od pet alat bi trebao manipulirati sa 3D objektima, te bi trebao omogučiti izradu animacije sa pojedinim objektom. Alat bi trebao omogučiti stvaranje okoline sa gravitacijom i dodjelu fizičkih svojstava objektu tj. da se objekt ponaša kao stvarni objekt iz realnog svijeta. Modelu koji se koristi kao igrač njoj bi trebalo dodijeliti animacije uz kretnju koju igrač unese(npr. strelica prema gore lik iz igre izvršava animaciju skoka.) Kroz alat trebalo bi biti omogućeno uređivanje okoline, te na taj način izrada novih razina. Virtualna stvarnost je nova tehnologija smještanja igrača u izraditu okolinu, te kao izazov alati bi trebali pružati i mogućnost izrade takvih okolina. Alatu bi trebao biti cilj pojednostaviti izradu igre, te omogućiti novacima lakše snalaženje i izradu bez velikih predznanja u programiranju.

2.1 Razvoj u Unreal engine 4

UE4 je jedna od najpopularnijih platformi za izradu igara, posjeduje veliki broj korisnika i time širok asortiman predložaka i već gotovih materijala i modela koji su besplatni ili na prodaju. Manipulacija sa 3D objektima u UE4 je moguća, te izrada animacija i video isječaka u igiri su mogući. UE4 ne nudi načine monetizacije vlastite igre, ali nudi mogućnost prodavanja vlastitih modela, animacija, materijala, tekstura, dijelova koda itd. Platforma je namijenjena poduzećima koja znaju monetizirati vlastite igre.

Grafički-engine u UE4 je jako dobro izradit, te može raditi sa visoko kvalitetnim teksturama i modelima. Manipulacijom visoko kvalitetnih materijala omogućeno je korištenjem zahtjevne računalne opreme, jer bez potrebnih računalnih komponenti neće se izvuči najbolji rezultat vizualizacije, te manipulacija sa materijalima postaje usporena ili čak nemoguća. Moguće je korištenje lošijih tekstura i modela, ali time se ne koristi puni potencijal platforme i time se smanjuje konkurentnost sa ostalim proizvođačima. Grafički engine omogućuje izradu različitih vrsta pogleda i korištenje modela kao što su: 2D, 3D modeli, te izrada VR igara sa 3D modelima je moguća i podržana kroz UE4. Dostupni su različiti efekti za svjetlost i čestice koje se prilagođavaju po potrebi.

Slika 2.: Prikaz korištenja Grafičke jedinice engine-a

Sustav za fiziku u engine-u je prilagodljiv, te se može koristit sa svim mogućnostima prikaza i primjene fizike. Fiziku za igru je moguće mijenjati i prilagođavati po potrebi ili razvijanje novih okolina sa različitim vrstama fizike, npr. razvoj igre kojoj se radnja odvija u svemiru, u igri se prikazuje stanje gdje nema gravitacije, prikazuje se gravitacija planeta ili satelita, te pri slijetanju i na samom planetu vidljivi su različiti prikazi fizike kako bi se postigli što sličniji uvjeti stvarnosti.

Zvučni sustav u UE4 podržava ne komprimirane male „endinae“ od 16 bita, za najbolje rezultate su preporučeni 44100 Hz ili 22050 Hz. Specifikacije su: PCM, ADPCM, DVI ADPCM, te je format .wav. Zvučni kanal je Mono, Stereo, 2.1, 4.1, 5.1 6.1, 7.1.

Spremanje stanja u UE4 se odvija tako da za svaki objekt se kreira varijabla, te se njoj dodjeljuje vrijednost koju je igrač postigao ili koje su se desile tijekom igre. Ovim načinom developer mora dodijeliti tj. odrediti koje će se vrijednosti spremiti i time se znatno smanjuje prostor koji se zauzima na disku.

58 CASE2018

Slika 3.: Kreiranje spremanja podataka

Upravljanje u UE4 se veže sa pojedinim objektom, te se odabire vrsta hardware-a koja će se koristiti za upravljanje, te se ide u postavke i mapira gumbove pod akcije koje trebaju izvesti akciju. Svaka akcija kao što je kretanje prema naprijed se može podešavati i prilagođavati po potrebi u karticama ili kodu.

Upravljanje podacima u UE4 se odvija tako da se svi spremljeni podaci jednog stanja igre spremaju u jednu datoteku iz takve datoteke se onda pri ponovnom ulasku u igru izščitavaju stanja varijabli i korisnik nastavlja sa igrom iz one točke na kojoj je stao.

Skriptanje u UE4 je pomoću predefiniranih kartica koje predstavljaju određene funkcije, te se povezuju jedna sa drugom u nekom slijedu u kojem se i trebaju izvršavati, unose se vrijednosti koje definiraju igru i time se kreira jedan dio igre ili ponašanja u igri.

Razvoj po spiralnoj metodi:

Dizajn – određivanje značajki igre i njihovih funkcija: 2D pogled, 3D modeli u igri, animacije kretnji, kolizije i gravitacija u okruženju.

Implementacija – Ovdje se mogu razviti značajke koje su odlučene u fazi Dizajna. Prvi korak ove faze bi bio razvoj modela, tekstura i animacija. Kroz engine bi trebalo imati mogućnost preskakanja razvoja modela i tekstura.

Za kreiranje igre pogotovo kao početniku na tom području je potrebna pomoć, te materijali za vježbu ili za ispunjavanje ideje. UE4 posjeduje zbog svoje korištenosti jako velik “community” i tutoriala koji mogu početniku pomoći pri izradi vlastite prve igre, te uz veliku dostupnost visoko kvalitetnih modela i tekstura koji su besplatni korisnik može izraditi kvalitetnu igru, ali uz male korake i visok utrošak vremena. Problem kod visoko kvalitetnih model i tekstura je da se mora posjedovati računalo sa jako dobrim hardware-om da bi se moglo manipulirati takvim objektima, te izrada jednostavnih igara na slabijim hardware-skim komponentama može biti popračena rušenjem aplikacije i znatnim usporavanjem računala.

Daljnji korak u razvoju bila bi izrada animacija za modele u igri, te dizajniranje početne razine i kombinacija svih izrađenih dijelova u jednu igru.

Kreiranje novih razina je moguće sa izradom terena koji poslije se oblikuje po želji sa različitim alatim kao što je alat za obradu terena gdje se može podizati teren, te oblikovati planine ili uvale. Alat za oblikovanje posjeduje i oblikovanje erozija gdje se može realističnije kreirati planina. Teren se oblikuje sa različitim materijalim koji prestavljaju teksture zemlje, kamena, trave i usklađuju se u što sličniji stvarnom terenu. Bitan faktor realizacije terena je i vegetacija koja se pojedinačno postavlja na teren ili sa alatom odredi veličina prostora na koji se postavlja vegetacija, te određuje gustoča vegetacije na tom dijelu.

Playtest - u ovoj fazi potrebno je se pobriniti da je ono što se napravilo zabavno za igrača. Kroz ovu fazu se testiraju implementirani modeli, teksture, animacije, te da li je sve posloženo tako da se može iz početne točke doći do kraja igre.

Procjena - završne misli o tome što se učinilo ispravno i pogrešno tijekom proteklog ciklusa, stvara se novi skup problema ili grešaka koje su pronađene i onda se vraća na početni korak. Kroz UE4 vraćanje i izrada izmjena od trena uočavanja se može izvesti odmah bez vraćanja na fazu dizajna. Na dijelovima u kojima se uoči greška, npr. kriva tekstura u jednom dijelu igre, te klikom na objekt izmjeni se tekstura i sitne izmjene u kretnjama lika kako bi se stvorila igrivost koja je definirana u fazi dizajna, time se odmah može opet u fazu implementacije i nakon izmjena u fazu playtesta.

Slika 4.: Kreirana temeljna igra

CASE2018 59

2.2 Razvoj u Unity-u

Početno sučelje Unity-a nasuprot UE4 je jako siromašno, te može se odabrati između kreiranja novog projekta i učenja, te postavki gdje se sprema projekt. Kod kreiranja novog projekta se ne odlučuje za koju platformu se izrađuje projekt već kad je izrađen projekt, pri kreiranju izvršne datoteke odabire se za koje platforme se izrađuje, tako da nije potrebno paziti na upravljanje jer alat prilagodi upravljanje likova ovisno o platformi. Što se tiče kretanja i upravljanja sa pogledom tijekom izrade Unity posjeduje iste kontrole i skračenice kao UE4.

Grafički-engine u Unity-u pruža grafički prikaz prema današnjim standardima tehnike. Grafički engine koristi odgođeno sjenčanje i temelji se na OpenGL ili Direct3D, ovisno o ciljnoj platformi. Podržani su različiti modeli osvjetljenja zasnovani na shader-u. Dostupni su različiti efekti za svjetlost i prašinu koji se mogu ručno prilagođavati. Materijali koji se mogu koristiti u Unity-u su jako dobre kvalitete, te je moguća manipulacija s tim objektima, nije potrebno računalo sa iznimnim hardware-om već je moguća i izrada sa prosječnim računalima bez većih usporavanja rada.

Sustav za fiziku je prilagodljiv, u engine-u je moguće korištenje Rigidbody fizike za 3D i 2D modele, te su prilagodljivi po potrebi izrade igre.

Zvučni sustav u Unity-u koristi se standardnim kvaliteteama zvuka za izadu igara, te je moguć njihovo dodavanje korz stablo komponenata za svaki objekt.

Spremanje stanja u Unity se odvija na način da se svako dešavanje ili promjena spremi u predefiniranu varijablu, nije moguće korištenje kartica za izradu kao u UE4 već se sve ručno programira kroz različite alate koje Unity nudi.

Upravljanje u Unity se izrađuje pomoću skripte koja se dodjeljuje igraču tj. liku kojem se želi upravljati, te kroz skriptu se ostvaruju kretnje kroz neki input uređaj. Kroz „input manager“ se određuju kako će se odvijati kretnje, te koji će se hardware koristit za upravljanje.

Upravljanje podatcima - podaci se čitaju i ažuriraju u jednoj datoteci u kojoj su spremljene sve varijable koje određuju trenutno stanje igre ili uspjeh igrača kroz igru.

Skriptanje u Unity-u se odvija tako da se kreira objekt za lika, ali objekt je ograničen jer je više dizajniran kao manadžer komunikacije između različitih događaja. Kombinacija objekta i pisanog koda omogućuje veću varijaciju i detaljnjije upravljanje sa samim događajima. U skriptiranju su i sadržani moduli za input, te za vrijeme događaja je moguće da samo jedan događaj je aktivan u isto vrijeme.

Dizajn - određivanje značajki igre i njihovih funkcija: 2D pogled, 3D modeli u igri, animacije kretnji, kolizije i gravitacija u okruženju.

Implementacija – u ovoj fazi prioritet je razviti ili pronači materijale za izradu vlastite igre i većinom je to moguće kroz vlastitu trgovinu engine-a. Unity posjeduje bogatu ponudu materijala u svojoj trgovini koju obogaćuju materijali od samih korisnika.

Igri se izrađuju i animacije kako bi se prikazalo stvarno kretnje objekata i time pokušalo imitirati stvarnost. Unity i izrada terena je jako jednostavna, za svaki novi sloj koji se želi nanijeti kreira se novi layer sa tim materijalom i nanositi na temeljni kako bi se kreirao teren po želji. Prisutni su i različiti alati za oblikovanje terena gdje se može birati iz različitih primjera i prilagođavati ih po potrebi. Dodavanje vegetacije je isto pomoću kista, kojem se određuje veličina i gustoča vegetacije na određenom području.

Unity ne posjeduje kartice koje se povezuju i kreiraju kod za jednu akciju već se koristi C# programskim jezikom i time se piše programski kod ili koristi predložak koji je ponuđen i prilagođava se po potrebi.

Playtest:

Liku je dodana gravitacija koja ga povlači prema dolje i simulira gravitaciju planeta, igraču su omogučene kretnje i lik je popračen kamerom kako bi igrač vidio svog lika tokom igre. 3D objekte je moguće manipulirati po želji te dodavati različite oblike, dodavati pozadine ili kreiranje svog terena u kojem će se napraviti objekti koji se kreću uz pomoć skripte, a ne utječu na igrivost već služe za vizualni dojam.

Slika 5.: Kreirana temeljna igra u Unity-u

Procjena – u procjeni se promatra igrivost i zabavni faktor igre, te da li su posloženi svi elementi po dobrom rasporedu da bi se mogla započeti igra i završiti bez da se dođe do točke koja zbog krive pozicije elementa je nemoguća prepreka.

60 CASE2018

2.3 Razvoj u Cryengine

Cryengine i njegovo početno sučelje se razlikuju od prva dva engine-a, te sve potrebne osnovne kontrole su prikazane na samom početnom sučelju i bez objašnjenja ili tutoriala se teško može započeti sa radom. Potrebno je ulaganje dosta vremena za automatizaciju pokreta u izradi. Sami materijali kao što su modeli, teksture itd. moraju se ručno importirati u projekt i to sa pronalaženjem putanje na računalu i ubacivanje u projekt.

Grafički engine se ne razlikuje od predhodnih dva, te je moguć razvoj 2D, 3D i VR igara. Cryengine posjeduje isto sve elemente za prikaz sjena, čestica i obradu svjetlosti. Kvaliteta materijala je iznimna i jako je zahtjevna na sami hardware, te je moguća izrada fotorealističnih scena kao i u UE4.

Sustav za fiziku u Cryengine-u je osnovan na “Rigid body“ fizici koja je prikaz Newton-ove mehanike na čvrsta tijela. Moguće je izmjena na samoj fizici, ali je potrebno dobro poznavanje programiranja. Sama fizika je dodana u detalje svakog objekta i oblikuje se po želji, te postoji mogućnost dodavanja animacija.

Zvučni sustav u Cryengine-u koristi se sa današnjim standardima, te posjeduje ubacivanje glazbe po području i po mjestu izvođenja. Svaka kreirana glazba se povezuje po nekom redoslijedu kao „playlista“ koja se raspoređuje sa povezivanjem ili jednom linijom koda.

Spremanje i upravljanje podatcima - stanja u engine-u se odvija tako da se doda objekt i kartica za spremanje njegovog stanja. Moguće je kreiranje područja koje sa prekidačem izaziva spremanje stanja određenih objekata koji su definirani. Varijable kojima se vrijednosti spremaju su spremljene u jednu datoteku s novim stanjima, te se iz te datoteke pozivaju pomoću kartice koja već sadrži kod za izvršavanje takve akcije.

Upravljanje igrača organizirano je tako da su kontrole sastavljene u takozvane akcijske mape gdje se mapiraju gumbovi sa vrstama pokreta. Slijedeće akcije su dostupne:

onPress – akcijski gumb je pritisnut onRelease – akcijski gumb je pušten. onHold – akcijski gumb se drži. always – neprekidno

Skriptanje u Cryengine se odvija pomoću „LUA“ gdje postoje već kreirane kartice za određene radnje i one se međusobno povezuju kako bi kreirali događaj. Postoji i mogućnost otkrivanja koda kartica pomoću c++ jezika kako bi se izvela promjena i kreirala nova skripta koja će se koristiti u igri koju razvijate.

Dizajn - određivanje značajki igre i njihovih funkcija: 2D pogled, 3D modeli u igri, animacije kretnji, kolizije i gravitacija u okruženju.

Implementacija – kroz ovu fazu prvi korak je pronalazak materijala korz trgovinu Cryengine-a. Crytek je poznat po grafici koja je visoke kvalitete i jedno vrijeme su posjedovali najbolji rafički prikaz u svojim igrama, bili su oko 2-3 godine ispred svojih konkurenata.

Slijedeći koraci su izrada animacija i same razine za igru, te oblikovanje terena. Izrada animacija kroz Cryengine je moguća, ali većina animacija se izrađuje sa nekim trećim software-om zbog jednostavnosti i detaljiziranja. Animacije u engine-u se većinom prilagođavaju i dotjerivaju za igru.

Cryengine posjeduje oblikovanje terena i ubacivanje objekata slično prva dva engina, ali postoje razlike u korištenju tekstura i kreiranje materijala za primjenu na objekte, dok je u Unity-u i UE4 jednostavno kroz drag and drop funkciju u Cryenginu se moraju kreirati samostalno.

Slika 6.: Izrada razine

Playtest – Kada se dodaju svi objekti i odrede događaji u igri pokreće se igra kako bi se vidjele greške i potrebe za promjenu. Igra posjeduje brod koji se može upravljati i treba izbjegavati prepreke koje se stvaraju putem.

Procjena – kroz procjenu su vidljive greške u igri kao što je preuzak raspored prepreka i time brod nema mogućnost prolaza i dolazi do nemogućnosti prelaska nivoa. Kada se dese greške kao na slici gore prikazano potrebno je vratiti se u fazu implementacije gdje se dogodila pogriješka u odmjeravanju prolaza.

CASE2018 61

2.4 Razvoj u Game maker studio

Engine je dizajniran za izradu i manipulaciju jednostavnijih igara, pretežito se izrađuju 2D igre, ali moguće je korištenje i ograničenih 3D modela. Platforma posjeduje alat za izradu svojih materijala, alat je sličan “Adobe Photoshopu”. Trgovina materijala je dostupna i posjeduje besplatne materijale, ali svi materijali se mogo uz dobro znanje o izradi materijala samostalno izraditi. Materijali su 2D i time ne postavljaju velike zahtjeve na hardware, kvaliteta za 2D materijale je jako dobra.

Grafički engine se koristi sa 2D grafikom i ograničenom 3D grafikom, ne posjeduje načine za izradu grafičkih čestica, sjena ili svijetlosti. Svaki dodatak ili efekt se mora izraditi u obliku “sprite-a”, te se kroz oblikovanje framova kreiraju pokreti i time je omogućen prikaz nekih čestica.

Sustav za fiziku u Game maker studio-u postoji kao vrsta varijable. Usmjerava objekt kojem je dodijeljena fizika po određenoj brzini koja se definira prema dolje ili gore, ovisno o postavljenim vrijednostima.

Zvučni sustav u engine-u temeljen je na .ogg, .mp3, i .wav formatima glazbe sa kojom se može manipulirati. Sadržane su i funkcije koje se dijele na osnovne, proširene i funkcije koje su usmjerene na stream zvuk, pozicijski zvuk, kako bi stvorili 3D zvuk i grupirani zvuk.

Spremanje i upravljanje podatcima – kako bi se moglo spremati podatke potrebno je iskoristiti programerske vještine jer engine sam po sebi ne nudi nikakvu mogućnost osim samostalne izrade. Moguće rješenje je da se varijable koje mijenjaju stanje se dodijeljuju varijablama koje posjeduju mjesto spremanja u samostalno kreiranom .ini datoteci.

Upravljanje likova u engine-u se kreira tako da se liku kreira novi događaj koji se zove „step“, taj događaj se odvija frame po frame kako bi se stvorila animacija pokreta. Za svaki pokret npr. pokret u lijevo potrebno je dodijeliti i određeni gumb input uređaja za izvršavanje događaja.

Slika 7.: Kreiranje kretnji u GM:studio

Skriptanje se odvija pomoću „Drag and Drop“ (DnD) funkcije ili kroz „Game Maker Language“ (GML). DnD se izrađuje kroz već unaprijed kreirane kartice koje se sastavljaju u slijed odvijanja događaja i time se kreira akcija koja se dešava u određenom trenutku igre. GML izrada je slična DnD izradi razlika je u tome što nakon kreiranja događaja koji se želi, posjeduje se prilika individualizacije i izmjene svojstava ili kreiranje novih kroz pisanje i oblikovanje koda.

Dizajn - određivanje značajki igre i njihovih funkcija: 2D pogled, 3D modeli u igri, animacije kretnji, kolizije i gravitacija u okruženju. Problem kod izrade predstavlja 3D model, jer za korištenje 3D modela u Game Maker studio-u potrebno je izraditi vlastiti „importer“ za predmete poput 3D modela. Trgovina nudi samo 2D modele i za izradu 2D igara engine posjeduje prednost prema ostalim konkurentima, zbog zadržavanja jednostavnosti kod izrade ostaje i jednostavnost kod porgramiranja.

Kroz fazu implementacije izrađuju se i prikupljaju materijali, koje je moguće i izrađivati u engine-u (2D). Izrada animacija nije moguća zbog nedostatka mogućnosti korištenja 3D modela, ali se animacija izrađuje tako da se više različitih slika poreda po željenom redoslijedu i simulira pokret. Oblikovanje terena također nije moguće jer teren je 3D vrsta, ali moguća je izrada terena kao slike i slaganjem u slojeve moguće je dobiti željenu dubinu.

Playtest nakon slaganja svih komponenti i povezivanja pomoću različitih međusobnih događaja, provjerava se igrivost igre. Igra prikuplja bodove bez ikakvih grešaka, protivnici vas ozlijeđuju, ali postoji greška pri prelasku nivoa gdje ljsetve nisu dostupne samom igraču kako bi mogao nastaviti svojom igrom.

Procjena – prema procijeni i kroz testiranje se ustanovilo da igru treba vratiti u fazu implementacije i ispraviti greške kao što su udaljenost ljestvi ili pojačati snagu skoka igrača. Odluka kako če se greška ispraviti će se donijeti u fazi prije implementacije tj. u fazi dizajna, te odluka mora osigurati igrivost i određenu težinu igre.

62 CASE2018

2.5 Razvoj u Construct 2

Construct 2 je platforma za razvoj 2D igara, što znači da je moguće samo upravljati slikama poznatima kao „sprite“. U engine-u nije omogućeno izrađivanje novih materijala, moguće je samo njihovo slaganje. Construct posjeduje svoju vrstu događaja i nepotrebno je poznavanje programskog jezika, jer svi događaji posjeduju pod funkcije koje se mogu kombinirati i time stvoriti logiku igre uz promjenu vrijednosti po potrebi. Izrada igara u ovom engine-u je moguća za računala i mobline uređaje, razvoj u construct-u je bio u početcima namijenjen igrama koje se igraju preko pretraživača.

Grafički-engine u Construct-u može manipulirati sa 2D objektima. Svaki element koji sliči nekom efektu ili animaciji je kreiran kroz više različitih slika ili jednom slikom koja se preobrađuje sa nekim funkcijama, npr. eksplozija gdje postoji slika efekta eksplozije i kroz period od 3 sekunde slika od nastanka do nestanka izblijeđuje i stvara se efekt animacije.

Sustav za fiziku u engine-u se odvija na način da objekt može posjedovati neku vrstu fizike ili gustoče koja privlači drugi objekt. Problem kod ovog sustava je da objekt može preskočiti svoja standardna kretanja i stvoriti se na pozicijama koje po kretnji ne bi smjele se događati. Kada se desi takav pokret moguće je da se ne prepozna kolizija i time desi greška u bodovanju, takvu grešku je moguće iskorištavati u prednost igrača da ostvaruje bodove koje ne bi trebao ili se igrač zakine i ne računaju mu se bodovi koje bi trebao imati.

Zvučni sustav kod construct-a se može uspoređivati i sa boljim engine-ima što se tiče reprodukcije zvuka, može vračati ove tipove zvukovnih datoteka: .ogg, .wav, .m4a. Obrada zvuka nije moguća, ali je moguće izazvati zvukove ovisno o dešavanju u igri.

Spremanje i upravljanje podatcima se odvija na način da se željena stanja odabranih objekata spremaju, a moguće je i onemogućiti spremanje stanja određenih objekata. Kroz JSON spremanje se može odvijati i na serverskoj strani, te stanje koje je spremljeno može se dijeliti s drugim korisnicima.

Upravljanje igrača se izrađuje događajima, npr. za zaslone na dodir može se odrediti dodir prema desno i koja će se radnja desiti u igri. Ovisno za koji uređaj se razvija igra moguće je kreirati događaje i po određenom uređaju za input. Construct posjeduje input za uređaje kao što su tipkovnica, „gamepad“ i zaslon na dodir.

Skriptanje u Construct-u se odvija kroz Sccira, nije potrebno poznavanje programskog jezika već se samo unose potrebne vrijednosti u određenom događaju. Sccira skriptanje je izrada događaja koji su predefinirani, nije moguće raditi izmjene na programskom kodu događaja. Funkcije koje su dostupne u construct-u prekrivaju veliku većinu potreba za izradu igre u 2D obliku.

Slika 8.: Primjer skripta u Construct 2

Dizajn - određivanje značajki igre i njihovih funkcija: 2D pogled, 3D modeli u igri, animacije kretnji, kolizije i gravitacija u okruženju. Construct nije u mogućnosti rada sa 3D modelima, te je moguća izrada vlastitih materijala kroz engine ili preuzimanje sa trgovine. Ovaj engine ograničava izradu i mogućnost kreativnog isticanja igre, ali početniku olakšava izradu i utrošak na učenje programskog jezika.

Implementacija igre kroz engine je jako jednostavna i uz logičko zaključivanje i stvaranje događaja moguća je izrada igre u jako kratgom vremenu, ali nedostatak je mogućnost izrade složenih igara. Construct nudi kvalitetne 2D materijale na korištenje i import u engine se odvija uz nekoliko klikova i jednostavan je. Kroz „Drag and drop“ funkciju može se dizajnirati razina i sa događajima povezati objekte koji su postavljeni u igru i dodijeliti objektima radnju u igri.

CASE2018 63

Playtest – u ovoj fazi se testira se je li došlo do greške u samoj igri, u fazi implementacije je li došlo do greške gdje objektu nije dodijeljen neki event, te taj objekt nema utjecaj na igru i igrivost, ali je grafička greška koja se prikazuje na zaslonu.

Procjena – kod grafičkih grešaka koje se dese tijekom igranja, a nemaju utjecaj na igru nema potrebe ispravljanja greške odmah. te objava igre i držanje roka ne bi ovisili o tome. Greške koje imaju utjecaj na igru su prioritetne i mogu utjecati na datum objave same igre, sitne grafičke greške se mogu ispraviti sa ažuriranjem i dodavanjem novih elemenata u igru.

3. DISKUSIJA RAZVOJA

Game engine Unreal engine 4

Unity CryEngine GameMaker: studio

Construct 2

Grafički engine koji koriste alati, podrška za 2D i 3D grafiku?

DA DA DA Djelomično Djelomično

Posjeduje li engine sustav za fiziku? DA DA DA DA DA

Posjeduje li engine-i zvučni sustav? DA DA DA DA DA

Može li se alatom odvijati spremanje i upravljanje podataka?

DA DA DA DA DA

Je li moguće izraditi upravljanje igrača, te prilagođavati ga?

DA DA DA DA Djelomično

Posjeduje li engine svoj jezik za skriptanje? DA NE DA DA DA

Posjeduju li engine mogućnost prikupljanja i izrade materijala za igru?

Djelomično Djelomično Djelomično DA DA

Je li moguća implementacija svih podataka potrebnih za igru kroz engine?

DA DA DA DA DA

Je li moguće zaigrati tek kreirani dio igre (Playtest)?

DA DA DA DA DA

Je li moguće ispraviti grešku koja je primjećena tijekom izrade, ili ukoniti ili prilagoditi funkcionalnost?

DA DA DA DA DA

Je li moguća izrada kroz sve faze spiralnog modela prilagođenog za izradu igara?

DA DA DA DA DA

Svaki engine posjeduje grafički engine, ali nisu svi na istoj razini UE4, Unity i CryEngine posjeduju grafički engine koji omogućuje korištenje 2D, 3D i VR grafike, te njihovu manipulaciju. Game Maker studio pruža ograničeno korištenje grafike, moguće je korištenje ograničene 3D grafike i 2D grafika, dok Construct omogućuje korištenje samo 2D grafike.

Svi engine-i posjeduju sustav za fiziku, ali sustavi se razlikuju od engine-a do engine-a, dok se u Construct 2 i Game Maker studio-u ne može koristiti fizika za 3D modela koristi se fizika koja mijenja gustoću objekta i time se dobiva privlačnost ili težina objekta koja simulira fiziku. Ostali engine-i se mogu koristiti sa složenijom fizikom koja predočava fiziku bližoj stvarnosti jer se radi sa 3D objektima i time je povećan osjećaj realnosti. Kroz VR izradu igara engine-i mogu staviti igrača u svijet sa potpuno ne stvarnom fizikom na koju je naviknuto tijelo, te kroz različite uređaje bi se time moglo i tijelo zavarati.

Svaki engine posjeduje zvučni sustav kojim se dodaje glazba u igru i pokušava stvoriti atmosfera za korisnika. Kvaliteta glazbe koja se može koristiti se ne razlikuje, ali razlikuje se korištenje i korištenje glazbe jer neki engine-i pružaju 3D prostor i time različite mogućnosti postavljanja pokretaća glazbe na tom području.

Alati su u mogućnosti odvijanja spremanja podataka i upravljanja tim podacima. Construct sprema podatke u jednostavne datoteke, a alati poput UE4, Unity i CryEngine pružaju uređivanje postupka spremanja, moguća je i izrada vlastitog načina spremanja sa Visual Studio-om koji se instalira pri instalaciji engine-a.

Kroz alate je moguća izrada upravljanja lika. Svaki alat posjeduje načine za odvijanje izrade. Kod UE4 odabire se platforma za koju se izrađuje igra i time dobiva mogućnosti kreiranja i uređivanja upravljanja za odgovarajuću platformu (npr. za mobilne uređaje). Ovisno o platformi za koju se izrađuje igra, postoje već definirani načini upravljanja koji se mogu prilagoditi i drugim input uređajima koji se koriste na raznim platformama. U Unity-u je potrebno kroz C# uređivati i kreirati upravljanja likova, u CryEngine-u mogu se koristiti već gotova rješenja koja proizlaze iz skript jezika engine-a, ili se mogu samostalno izraditi i prilagoditi kroz Visual Studio. Game Maker studio i Construct kroz svoje već gotove skripte omogućuju izradu upravljanja, te je moguće prilagođavanje. Construct ne može izraditi upravljanje za sve input uređaje.

Skriptanje kroz engine bi trebalo olakšati izradu radnji u igri koje bi se trebalo ručno izraditi i time bi stvorili veliku količinu programskog koda u kojem se mogu nači greške. Engine kroz svoj jezik za skriptanje posjeduje već gotove forme koje se logički povezuju i stvara događaj. Svi engine-i osim Unity-a posjeduju svoj jezik kroz kartice u koje se upisuju vrijednosti prilagođene i povezane za kreiranje događaja koji je zamišljen u razvoju. U Unity-u se taj dio posla odvija kroz skripte u C# jeziku koji je pojednostavljen i posjeduje knjižnice iz kojih se pozivaju potrebne funkcije, te obrađuju i prilagođavaju po potrebi. Kroz vlastiti jezik engine smanjuje potrebu za poznavanjem nekog programskog jezika i time omogućuje izradu igre i dizajnerima igre.

64 CASE2018

UE4, Unity i CryEngine omogućuju prikupljanje materijala za izradu vlastite igre sa njihove trgovine sa modelima, teksturama itd., ali ne posjeduju alate za izradu modela za igru, te je potrebno kroz software treće strane izraditi novi model. Izrada animacija i upravljanje svim vrstama modela je moguća u engine-ima, te izrada materijala za npr. model stola se može izraditi ali sa već prikupljenim teksturama. Game Maker studio i Construct imaju alat za izradu svojih „sprite“-ova, to su većinom 2D materijali koji se izrađuju kroz alat za crtanje. Posjeduju i vlatitiu trgovinu materijalima koja je dostupna svim developer-ima uz korištenje neke vrste pretplate.

Svi engine-i pružaju potpunu implementaciju svih materijala za izradu igre, dok su Game Maker studio i Construct ograničeni na to da za implementaciju nije potrebna implementacija složenih 3D materijala. Moguća je i obrada pojedinih materijala kroz engine sa alatima koji su implementirani i koriste se u razvoju animacija, obradi zvuka itd.

Playtest je moguć kroz sve engine, kada se izradi i poslože dijelovi igre. Izvršavanjem kreiranog može se testirati razina. Svi engine-i osim Constructa test odvijaju kroz engine, a Construct se koristi pretraživaćem instaliranim na računalu.

Ispravak grešaka je moguć odmah nakon Playtesta. Čim se uoči neka greška može se zaustaviti postupak testiranja i vratiti na dio koji se želi prepraviti, te ga prilagoditi, obraditi i dodati sadržaj koji se želi.

Korištenjem spiralnog modela omogućeno je u svim engine-ima. Mogućnost popravka greške u trenutku uočavanja i prisutnost svih alata za izradu na jednome mjestu omogućuju potpunu fleksibilnost pri izradi igara.

4. ZAKLJUČAK

Istraživanjem 5 različitih engine-a mogla se vidjeti sličnost, ali specifičnosti koje ih razdvajaju. Engine poput UE4 je jedan od onih koji mogu pokriti sve funkcionalnosti koje su potrebne za razvoj bilo koje vrste igre, te je najkompletniji sa velikim izborom materijala i ponuđenih sadržaja za poduku. CryEngine i Unity su engine-i sa kojima je moguća izrada svih vrsta igara, ali kod Unity-a je potrebno koristiti programski jezik, dok CryEngine je što se tiče sučelja drugačiji od ostalih alata i korištenje i izrada se razlikuju u niansama. Unity pruža veliki broj materijala za izradu i time omogućuje izradu većih varijacija igre ukoliko se koristi C#. Game Maker studio je jednostavniji engine od prva 3 i izbacivanjem 3D grafike olakšava novim korisnicima snalaženje po alatu, te sa svojim načinom kreiranja koda uz gotove dijelove i logičko povezivanje, izrada postaje lakše shvatljiva za novog developera. Construct 2 je engine sa kojim je moguća izrada igara samo u 2D grafici, ali za to već posjeduje gotove događaje koji se povezuju logički i tvori igra. Game Maker studio i Construct posjeduju svoje alate za izradu 2D grafike i time uklanjaju potrebu za alatom treće strane.

Početniku koji se ne razumije u programske jezike i ideje koje želi ostvariti su sa 2D sadržajem preporučuje su Game Maker studio i Construct zbog već spremnih događaja. Ako je potrebno izraditi složeniju 2D igru i npr. s nekim 3D elementima preporučuju se druga 3 alata. Za složenije igre kao što su 3D igre preporučuju se alati CryEngine, Unity i UE4, ali uz znatno veće utroške vremena od 2D igre. VR igre je također moguće izraditi kroz CryEngine, Unity i UE4. Uz bolje poznavanje postupka izrade igara i dobro poznavanje programskih jezika moguća je izrada „trend“ vrste igre.

Literatura:

1 Claus Pias: Computer Spiel Welten, 1993

2 Pile Jr, John: 2D Graphics Programming for Games, Taylor and Francis Group, Broken sound Parkway NW, 2013.

3 Oliver Grau: Virtual Art. From Illusion to Immersion. MIT Press, Cambridge MA 2003

4 Marco Mignano: Spiral Model For Game Development: Techniques To Develop Games, URL(http://gamedevelopertips.com/spiral-model-for-game-development/) (7. 12. 2017)

5 Karl Pfetzing, Adolf Rohde: Ganzheitliches Projektmanagement. Gießen 2014

6 Jason Gregory, Jeff Lander: Game Engine Architecture. Taylor & Francis Ltd., 2009

7 Barry Boehm, Jo Ann Lane, Supannika Koolmanojwong, Richard Turner: The Incremental Commitment Spiral Model: Principles and Practices for Successful Systems and Software, RR Donnelley, Crawfordsville(Indiana), 2014.

8 Epic Games: Unreal engine,URL(https://www.unrealengine.com/en-US/blog )(13. 12. 2017)

9 Unity: Unity 2017.3, URL(https://unity3d.com/de) (14. 12. 2017)

10 CryTek: CryEngine, URL(https://www.cryengine.com/) (18. 12. 2017)

11 Yoyogames: GameMaker: studio, URL(https://www.yoyogames.com/gamemaker/features)(18. 12. 2017)

12 Scirra: Construct 2, URL(https://www.scirra.com/construct2 )(19. 12. 2017)

Podaci o autorima:

Daniel Marković e-mail: dmarkovi@veleri.hr dr. sc. Marin Kaluža e-mail: mkaluza@veleri.hr Marin Kaluža je viši predavač na Veleučilištu u Rijeci i nositelj nekoliko kolegija iz područja razvoja softvera i informacijskih sustava, te upravljanja i razvoja baza podataka. Doktorirao je na Filozofskom fakultetu u Zagrebu na problemima mjerenja i analize složenosti poslovnih sustava. Područje njegovog istraživanja je brzi, rapidni i agilni razvoj softvera, standardizacija i automatizacija u razvoju softvera i korisničkih sučelja. Vodio je projekte razvoja većeg broja informacijskih sustava iz područja školstva, industrijske proizvodnje, zaštite na radu, ekonomije i medicine.

CASE2018 65

mr. sc. Bernard Vukelić e-mail: bvukelic@veleri.hr Veleučilište u Rijeci Vukovarska 58 51000 Rijeka

66 CASE2018

CASE2018 67

KORIŠTENJE RJEČNIKA PODATAKA RELACIJSKE BAZE PODATAKA ZA POTREBE GENERIRANJA POSLOVNIH WEB APLIKACIJA

Ivona Čančar, Dino Abazović, dr.sc. Marin Kaluža

SAŽETAK

Grafički prikaz modela baze podataka poslovnog sustava dostupan je u strukturiranom tekstualnom obliku na RDBMS-u na kojem se nalazi baza podataka. To je tzv. rječnik podataka (eng. Data Dictionary - DD). DD sadrži sve podatke potrebne za konstruiranje modela podataka i aktivne baze podataka pa tako sadrži podatke o tablicama, redovima (vrijednosti - podaci), stupcima (atributima), ključevima, indexima i vanjskim ključevima.

Podaci iz DD-a na RDBMS-u mogu se koristiti za potrebe generiranja pripadne web ili desktop aplikacije, odnosno njenih osnovnih funkcionalnosti (izbornik, tabelaran pregled, pojedinačno ažuriranje).

U radu će se pokazati kako se DD na RDBMS-u za neku bazu podataka, koja je izrađena iz normaliziranog relacijskog modela podataka, može koristiti u postupcima generiranja aplikacijskih komponenti za određene osnovne elemente korisničkog sučelja pripadne web aplikacije. Pokazati će se proces transformacije relacijskog modela u niz stablastih struktura. Pokazat će se kako se takva transformacija može koristiti za potrebe izrade izbornika i stablastih tzv. parent/child stranica s listom. Pokazati će se primjer strukture aplikacijskih komponenti temeljen na MVC strukturi s proširenjem View Model pogodne za korištenje u generatoru web aplikacija koji se temelji na čitanju DD-a na bazi podataka.

1. UVOD

Model podataka je uvijek polazna osnovica za izgradnju web aplikacije za neki poslovni sustav. Iz tog razloga važno je prije izrade aplikacije izraditi potpun i normaliziran model podataka. Model podataka se poznatim algoritmima transformira u bazu podataka koja, kod aplikacija za poslovne sustave, često implementira relacijski model pomoću SQL-a na poslužitelju. Konstrukti iz logičkog relacijskog modela podataka transformaciju se u konstrukte na poslužitelju baze kao npr. tablica, atribut, primarni ključ, foreign key, column definition (data type, nullable, description). Svi konstrukti baze podataka dostupni su u rječniku podataka (Data Dictionary – DD) na poslužitelju pomoću standardne SQL SELECT naredbe.

Podaci iz DD-a na poslužitelju mogu se koristiti u postupcima izrade nekih dijelova aplikacije. U nastavku će se pokazati kako se može model baze podataka pokazati u nizu stablastih struktura. Pokazat će se i primjeri „dobre prakse“ u imenovanju konstrukata u bazi podataka, koja olakšava postupak interpretacije DD-a za potrebe izrade (generiranja) aplikacijskih dijelova. Objasniti će se često korišteni MVC obrazac strukturiranja aplikacijskih komponenti. Objasniti će se potreba za proširenjem MVC-a i pokazat će se proširena MVC struktura. Prikazati će se mogućnosti i opisati postupak generiranja aplikacijskih komponenti prema proširenom MVC strukturi. Pokazati će se rezultati generiranja aplikacije na primjerima generiranih izbornika, pregleda, i formi.

2. TRANSFORMACIJA RELACIJSKOG MODELA U NIZ STABALA

Relacijske baze podataka bazirane su na relacijskom modelu. Relacijski model uključuje pravila definirana matematičkim principima (relacijskoj algebri) i definira univerzalan jezik (SQL) s kojim klijent može upravljati bazom podataka. Osnovni konstrukti relacijske baze podataka su: tablice, stupci (atributi), redovi (vrijednosti - podaci), primarni ključ, vanjski ključevi (i postupci očuvanja referencijalnog integriteta).

68 CASE2018

Slika 4 Primjer stablaste strukture formirane iz baze podataka

Na Slici 1 prikazana je stablasta struktura tablica iz baze podataka formirana postupkom transformacije relacijskog modela. Pokazani elementi stabla su relacije (objekti) iz relacijskog modela ili tablice iz relacijske baze podataka.

Svaki element (neovisno o njegovoj razini u stablu) može biti: List (element u stablu koji nema svoje pod elemente), ili Grana (element u stablu koji ima svoje pod elemente). Pod element je pridružen nekom nad elementu, ako se u primarnom ključu, ili jedinstvenom indeksu koji je prirodni identifikator objekta kada je prisutan „surogatni ključ“ (npr. id), nalazi foreign key koji ukazuje na primarni ključ u nad objektu 8.

U 8 pokazan je algoritam pomoću kojeg se može izraditi PL-SQL procedura koja će u 2D tablici vratiti „niz stabala“. Dobiveni „niz stabala“ može se transformirati u neke dijelove izbornika u web aplikaciji. Na slici 2 prikazan je dio takvog izbornika.

Slika 5 Prikaz izbornika u web aplikaciji ARMeS

2.1 Tablica

Nazivi tablica, atributa, ključeva, ograničenja bitni su pri stvaranju aplikacije, jer olakšavaju postupak čitanja (interpretacije) modela. Ako se isti algoritam iz 8 koristi u stvaranju naziva tablica može se olakšati postupak razumijevanja/korištenja modela u razvoju aplikacije.

CASE2018 69

Tablica je kolekcija istovrsnih informacija, i u stupcima se nalaze atributi, a u redovima pojedinačne informacije cjelovito opisane vrijednostima u ćelijama 2.

Zbog potreba u spomenutom algoritmu iz 8 tablice se mogu grupirati u dvije skupine:

Temeljne – spadaju u neovisne zasebne jedinice. Često predstavljaju tipove objekata koji postoje u stvarnom svijetu. Neki primjeri takvih tablica su: Partner, Kupci, Dobavljači, Zaposlenik, Materijali, Artikli i slično.

Slabe i Agregirane – tablice koje ostvaruju identifikacijsku(e) vezu sa nekom „jačom“ tablicom. Npr. Naručene usluge identifikacijski ovisi o Narudžbi ili Roba na računu identifikacijski ovisi o Računu i Artiklu.

U nastavku će se pokazati primjer prilagodbe naziva tablica i atributa u relacijskoj shemi (Tablica 1). Povezanost relacija je razumljiva na prvi pogled, no prilagodbom naziva tablica i atributa koji su ograničeni vanjskim ključem postaje vidljiva roditelj-dijete struktura koja tvori stablo.

Tablica 1 Prilagodba naziva tablica i atributa

POČETNA RELACIJSKA SHEMA PRILAGOĐENA RELACIJSKA SHEMA

Zgrada (id, naziv, adresa, ...)

zgrada (pfx: Zgr) (id, naziv, adresa, ...)

Ulaz (id, naziv, zgrada (fk->id), broj katova, ...)

zgr_ulaz (pfx: ZgrUla) (pfx: ZgrUla) (id, naziv, idZgr (fk->id), broj katova, ...)

Stan (id, broj, ulaz (fk->id), površina, ...)

zgr_ula_stan (pfx: ZgrUlaStn) (pfx: ZgrUlaStn) (id, broj, idZgrUla (fk->id), površina, ...)

Vlasnik (id, oib, stan (fk->id), ime, prezime, ...)

zgr_ula_stn_vlasnik (pfx: ZgrUlaStnVla) (id, oib, idZgrUlaStn (fk->id), ime, prezime, ...)

U Tablici 1 u lijevom stupcu prikazan je primjer relacijske sheme sa prirodnim nazivima koji su dobiveni iz modela entiteti i veze (EV). U desnom stupcu je primjer korištenja algoritma iz 8 nad relacijskom shemom iz lijevog stupca. Iz desnog stupca može se izraditi SQL skripta za formiranje tablica u bazi podataka kao na Slici 3.

Slika 6 Primjer SQL CREATE skripte

Prefiks temeljne tablice (tzv. roditelj), to je u Tablici 1 tablica zgrada, prosljeđuje se u početni dio naziva na vezanoj „slabijoj“ tablici, to je na Slici 3 tablica zgr_ulaz. Isti postupkom stvoreni su nazivi tablica zgr_ula_stan i zgr_ula_stn_vlasnik iz primjera u Tablici 1.

Naziv atributa u „slabijoj“ tablici, to je na Slici 3 npr. tablica zgr_ula_stan, na kojima je postavljeno ograničenje vanjskog ključa, formira se koristeći prefiks iz povezane tablice koji se dodaje nazivu atributa koji je primarni ključ u povezanoj tablici, na Slici 3 to je atribut idZgrUla.

Na Slici 3 također je pokazan primjer naziva jedinstvenih indeksa i ograničenja vanjskog ključa koji će se objasniti u nastavku.

2.2 Atribut

Podaci su organizirani u skupine atributa. Svi podaci u jednoj tablici obuhvaćaju istu skupinu atributa 2. Atributi se u aplikaciji koriste na formama za ažuriranje, na pregledima u listama, itd. U tablicama na Slici 3. atributima je postavljen konstrukt DESCRIPTION koji se u aplikaciji može koristiti u tzv. prompt-u koji se nalazi obično lijevo od polja u kojem se upisuje podatak. Također, može se koristiti i na zaglavljima stupaca na listama za pregled.

Nazivi sličnih atributa u bazi trebali bi sadržavati iste prefikse kako bi se olakšalo razumijevanje i korištenje naziva atributa u postupcima pisanja (stvaranja) izvornog programskog kôda aplikacije.

CREATE TABLE `zgr_ulaz` (

`id` INT(10) NOT NULL AUTO_INCREMENT COMMENT 'id tblpfx: ZgrUla',

`idZgr` INT(10) NOT NULL COMMENT 'Zgrada',

`naziv` VARCHAR(64) NOT NULL COMMENT 'Naziv',

`br_kat` INT(3) DEFAULT NULL COMMENT 'Broj katova ulaza',

. . . ,

PRIMARY KEY (`id`),

UNIQUE KEY `u_ZgrUla_Zgr_naziv` (`idZgr`,`naziv`),

CONSTRAINT `c_ZgrUla_Zgr` FOREIGN KEY (`idZgr`) REFERENCES `zgrada` (`id`) ON DELETE RESTRICT ON

UPDATE CASCADE

) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='Ulaz zgrade';

CREATE TABLE `zgr_ula_stan` (

`id` INT(10) NOT NULL AUTO_INCREMENT COMMENT 'id tblpfx: ZgrUlaStn',

`idZgrUla` INT(10) NOT NULL COMMENT 'Ulaz', -- ULAZ

`brStan` VARCHAR(3) NOT NULL COMMENT 'Broj stana', -- BRST

`povrsina` DECIMAL(7,2) DEFAULT NULL COMMENT 'Ukupna površina stana', -- POVRSINA

. . . ,

PRIMARY KEY (`id`),

UNIQUE KEY `u_ZgrUlaStn_ZgrUla_brStan_brStanDod_aktivan` (`idZgrUla`,`brStan`),

CONSTRAINT `c_ZgrUlaStn_ZgrUla` FOREIGN KEY (`idZgrUla`) REFERENCES `zgr_ulaz` (`id`) ON DELETE

RESTRICT ON UPDATE CASCADE

) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='Stan zgrade';

70 CASE2018

Tako bi npr. svi atributi koji sadrže datum trebali imati prefiks dat, kao: datNarudzbe, datRacun, datOtvaranja, datPlacanja, i slično. Atributi koji sadrže neke vrste iznosa imati će prefiks izn, kao: iznNarudzbe, iznRacuna, iznPlacen, itd.

Naziv atributa na kojem je ograničenje vanjskog ključa prema drugoj tablici, formira se iz naziva atributa koji je jednostavni primarni ključ (sačinjen od jednog atributa) u povezanoj tablici, i njezinog prefiksa. Na Slici 3. to su atributi: idZgr, idZgrUla, idZgrUlaStn.

Ovdje je vidljivo i korištenje tzv. Camelcase načina pisanja naziva atributa.

Tipovi podataka (STRING, TEXT, DECIMAL, INT, DATE, ...) na Slici 3, koriste se u procesu izrade aplikacije prilikom definiranja izgleda korisničkog sučelja u različitim prikazima podatka, npr. prikaz DATE tip atributa na formi može pretpostaviti postavljanje tzv. date picker-a, ili DECIMAL tip atributa može definirati tzv. entry polje s validacijom decimalnih mjesta.

2.3 Primarni ključ

Primarni ključ je atribut (ili skupina atributa) čija vrijednost jedinstveno predstavlja pojedini red u tablici. Zbog toga što je vrijednost ključa uvijek jedinstvena, koristi se i za sprječavanje dupliciranja redova 2.

Primarni ključ ima slijedeće karakteristike:

Obvezan – vrijednosti atributa koji čine ključ su obavezne, a to znači da atributi koji čine primarni ključ moraju imati ograničenje NOT NULL

Jedinstven – ne postoje dva različita reda (sloga) koji imaju jednake vrijednosti u atributima koji čine primarni ključ Minimalan – ne postoji pravi podskup atributa koji čine primarni ključ s kojim bi se mogla osigurati jedinstvenost

Svaka tablica u bazi podataka mora imati definiran primarni ključ. Problem se javlja u slučaju kada je prirodni primarni ključ tablice složen, i kada se on koristi kao ograničenje vanjskog ključa u „slabijoj“ tablici. Tada je korisno primijeniti postupak modifikacije modela implementacijom tzv. ID modifikacije 9. Predloženim postupkom u bazi podataka neće postojati tablica koja ima složen primarni ključ, i da se pritom koristi u nekoj slabijoj tablici kao ograničenje vanjskog ključa. Odnosno, u svim tablicama, atributi koji čine ograničenje vanjskog ključa prema primarnom ključu „jače“ tablice biti će jednostavni (jedan atribut) jer će primarni ključ u „jačoj“ tablici također biti jednostavan.

Na Slici 3. u konstruktu DESCRIPTION na atributu koji čini primarni ključ tablice opisan je prefiks tablice. Tako je za tablicu zgrada postavljen prefiks Zgr, za tablicu zgr_ula_stn_vlasnik postavljen prefiks ZgrUlaStnVla, itd.

2.4 Vanjski ključ

Ograničenje vanjskog ključa na atributu ograničava vrijednost atributa u slogu na skup vrijednosti koji je dobiven iz slogova nad atributima koji čine primarni ključ u povezanoj „jačoj“ tablici.

Ako vrijednost atributa koji je ograničen vanjskim ključem nije NULL, tada takva vrijednost obavezno postoji u povezanoj „jačoj“ tablici u atributu koji čini primarni ključ.

Na Slici 3 pokazani su primjeri naziva ograničenja vanjskog ključa. Tako je u tablici zgr_ulaz postavljeno ograničenje c_ZgrUla_Zgr prema tablici zgrada, ili u tablici zgr_ula_stn_vlasnik ograničenje c_ZgrUlaStnVla_ZgrUlaStn prema tablici zgr_ula_stan.

2.5 Korištenje vanjskih ključeva koji su u primarnom ključu

Na Slici 1 vidi se jedna temeljna grana. Temeljne grane predstavljaju osnovne pojave sustava. To su početne točke za promatranje modela. Svaka temeljna grana opisuje sustav iz svog kuta.

Grana (G) može imati svoje elemente (E), ako relacija E ima identifikacijsku vezu prema relaciji G. To znači da E ima vanjski ključ (FK) prema G, i pritom taj FK sudjeluje u primarnom ključu u E 8.

Na taj način elementi i pod elementi u grani detaljnije (uglavnom sa više vrijednosti) opisuju granu. Svaka grana predstavlja neki oblik dokumenta sustava, odnosno neki tip informacije koji se koristi u sustavu. Grane koje na jednoj razini imaju više pod elemenata (šire grane) i grane koji imaju više pod razina (dublje grane) prikazuju kompleksnije tipove informacija. Također grane koje nemaju puno pod elemenata prikazuju jednostavnije tipove informacija koje se koriste u sustavu.

3. STRUKTURA APLIKACIJE

Model–View–Controller (MVC) je često korišteni obrazac raspodjele programa na relativno nezavisne komponente (pod programe). Time je omogućen nezavisan i istovremeni razvoj više komponenata. Često se u razvoju pojedinih komponenata koristi objektno orijentirana tehnika.

Obzirom da aplikacije za podršku poslovnim sustavima uglavnom uključuju složeniji model podataka (sačinjen od većeg broja tablica), te postoji puno poslovnih pravila koja se trebaju implementirati u aplikaciju, samostalan objektno orijentirani razvoj većih aplikacija za poslovne sustave je vrlo složen. Kako bi se olakšao razvoj aplikacije po MVC obrascu često se koriste razni skupovi već gotovih klasa koje sadrže prikladne metode koje se koriste u razvoju pojedinih MVC komponenata. Skup klasa koji se može primjenjivati u različitim komponentama MVC obrasca je framework. To znači da se u razvoju aplikacija za različite komponente mogu koristiti različiti framework-ovi.

CASE2018 71

Slika 7 MVC model

Model čini komponentu koja služi za predstavljanje poslovnih podataka, i za manipulaciju s podacima primjenom definiranih poslovnih pravila i logike. Modeli sadrže sljedeća svojstva: atribute – predstavljaju poslovne podatke, nazivi atributa – prikazuju opis poslovnih podataka, masovno dodjeljivanje – omogućuje dodjeljivanje vrijednosti većem broju atributa u jednom koraku, pravila validacije – osigurava da ulazni podaci budu u skladu s pravilima, izvoz podataka – omogućuje da podaci budu izvezeni u obliku niza podataka s prilagođenim formatom. Također, sadrže metode koje implementiraju poslovnu logiku 3.

Controller-i upravljaju zahtjevima korisnika i pristupaju podacima, odnosno šalju naloge modelu ili view-u. Sačinjeni su od akcija koje su osnovne jedinice kojima krajnji korisnici mogu pristupiti i poslati zahtjev za izvršenje 5.

Model uključuje više metoda za čitanje i manipulaciju podacima, a Controller sadrži algoritam koji u izvođenju poziva potrebne metode iz modela za izvršavanje korisnikove akcije.

View stvara sadržaj za prikaz korisnicima u obliku obrasca, tablice ili dijagrama. View poziva metode modela za čitanje. Ne koristi metode za manipulaciju modelom 4. View se poziva iz Controller-a sa zahtjevom tzv. Render, a po završetku vraća Controller-u sadržaj za isporuku korisniku.

Pojedini Controller-i bi trebali biti prošireni od osnovnog, base Controller-a. Na taj način omogućeno je dodavanje specifičnih akcija za Controller svakog modela, bez da se utječe na osnovni Controller koji se može uvijek ponovo generirati. Tako će npr. base Controller-i Zgrade i ZgrUlaz izgledati isto, dok će prošireni imati različite akcije.

3.1 Proširenje MVC obrasca aplikacijskih komponenti

Slika 8 Prošireni MVC obrazac arhitekture aplikacije

Na Slici 5 prikazan je prošireni MVC obrazac. Proširenje je vidljivo u ViewModel i SearchModel komponentama i dodatnim tzv. parent komponentama BaseController, BaseModel, BaseViewModel i BaseSearchModel.

U strukturi MVVM, izbačeno je korištenje Controllera, čiju ulogu preuzima ViewModel. ViewModel-u nije poznato što view prikazuje, niti mu je poznato otkud podaci dolaze. ViewModel predstavlja most između dizajnera i programera i zato treba biti što jednostavniji.

Neka pravila koja treba respektirati kod predloženog proširenog MVC obrasca (Slika 5):

View prikazuje određeni oblik podataka i nije mu poznat izvor podataka. ViewModel definira različite oblike prikaza određenog podataka iz modela, i nije mu poznat izvor podataka.

72 CASE2018

SearchModel definira različite oblike čitanja podataka iz modela Model sadrži stvarne podatke i osnovne metode za čitanje i ažuriranje pojedinačnih podataka Controller provodi korisnikove zahtjeve (akcije). Određuje logiku izvršavanja akcije. Poziva odgovarajuću metodu iz

SearchModel-a i prosljeđuje podatke View-u na postupak render-iranja sadržaja za prikaz korisniku.

Dodatna prednost korištenja proširene MVC strukture je u tome što je samo potrebno postojanje Controllera u memoriji za postojanost aplikacije i što oni sadrže većinu akcija i malo statičnih podataka 1.

3.2 Objašnjenje proširenja MVC obrasca

ViewModel predstavlja most između view-a i model-a. Svaki view ima pripadajuću ViewModel klasu. ViewModel dohvaća atribute modela te sadrži metode koje te atribute prikazuju u obliku tablice ili forme.

Zbog potrebe za različitim prikazom podataka, ViewModel se može proširiti pa se time atributi mogu grupirati u grupe ili utjecati na različite opcije poput naziva ili vidljivosti atributa. Iako se naziv atributa može mijenjati u modelu, u slučaju grupiranja elemenata dijelovi naziva atributa mogu se skratiti. Kada je potrebno proširenje ili prilagodba modela dodavanjem novih atributa, moći će se generirati base ViewModel, bez utjecanja na prošireni ViewModel, koji ostaje onakav kako je definiran.

SearchModel se poziva iz Controller-a, i sadrži skup metoda za različite vrste čitanja podataka iz model-a. Time je omogućena prilagodba model-a, koja će eventualno zahtijevati prilagodbu SearchModel-a, ali pritom neće biti potrebe za prilagodbom Controller-a.

Na Slici 5. vidljivo je da su Model, ViewModel i SearchModel komponente sačinjene od dva dijela: osnovni (base) i prošireni (extended).

BaseModel sadrži svojstva koji predstavljaju atribute iz tablice u bazi podataka, sadrži metode za prikaz dodatni podataka o modelu dostupnih u tablicama baze podataka (title, primary key, relations, name, attribute labels, ...), sadrži metode za ažuriranje podataka u tablici na bazi. Obzirom da se BaseModel u potpunosti može opisati iz pripadnih konstrukata u bazi podataka, moguće je izraditi program koji će za svaku tablicu u bazi podataka generirati izvorni programski kôd njene BaseModel klase.

BaseViewModel sadrži metode prikaza pojedinih property iz Model-a na listi ili formi. Obzirom da se konstrukti tip podataka i ograničenje vanjskog ključa u bazi podataka mogu koristiti u definiranju izgleda korisničkog sučelja za prikaz atributa na listi, na formi, u filteru iznad liste, i ovdje je moguće izraditi program koji će za svaku tablicu u bazi podataka generirati izvorni programski kôd njene BaseViewModel klase.

BaseSearchModel sadrži osnovnu search metodu nad modelom sa svim atributima tablice iz koje je model stvoren. Ta metoda uključuje i title property za svaki atribut koji je ograničen vanjskim ključem, a to znači da metoda uz čitanje podataka iz osnovne tablice modela, čita podatke i iz povezanih tablica za sve njezine atribute koji su ograničeni vanjskim ključem. Model title property se može sastojati od više atributa koji mogu i ne moraju biti prirodni identifikatori reda. Zbog toga u title svojstvu modela mogu biti i atributi koji su ograničeni vanjskim ključem. U takvom slučaju title svojstvo modela dobiva elemente iz title svojstva tablice na koju ukazuje atribut koji je u title svojstvu modela i ograničen je vanjskim ključem. Prema tome, title svojstva u modelima koji su stvoreni nad tablicama agregacijama imat će title svojstva sačinjena od title svojstava modela koji su stvoreni iz povezanih tablica na agregaciju. Sva ograničenja vanjskih ključeva mogu se pročitati iz baze podataka, pa je moguće izraditi program koji će za svaku tablicu u bazi podataka generirati izvorni programski kôd njene BaseSearchModel klase.

Prema svemu prije navedenom u ovom poglavlju izvorni programski kôd klasa BaseModel, BaseViewModel, BaseSearchModel može se generirati. Također, programi za generiranje mogu se prilagoditi za generiranje proširenih klasa nad pripadnim base klasama koje se tada dalje ručno mogu prilagođavati i dopunjavati.

4. GENERIRANJE APLIKACIJE

Za potrebe razvoja web aplikacije korišten je Yii framework 6 za php programski jezik. Ovaj framework uključuje komponentu Gii koja je prilagođena i korištena za generiranje aplikacijskih komponenti prema proširenoj MVC strukturi opisanoj u prethodnom poglavlju.

Izrađeni su prilagođeni generatori za Model, i CRUD** akcije. Spomenuti generatori dovoljni su za generiranje svih aplikacijskih komponenti zahtijevanih u proširenoj MVC strukturi (Slika 3). Model generator omogućuje generiranje modela za sve tablice u bazi podataka. CRUD generator omogućuje generiranje Controller-a (sa svim CRUD akcijama) REST API klase, view-eve, ModelView klase, te ModelSearch klase za sve Model-e u aplikaciji. To znači da je generiranje spomenutih aplikacijskih komponenata omogućeno „jednim klikom miša“.

Generatori se mogu proširivati i prilagođavati i time dobiti dodatne funkcionalnosti koje će biti primijenjene na sve modele i CRUD-ove. Upravo se u ovom koraku vidi važnost u formiranju naziva tablica i atributa opisanih u prethodnom poglavlju, Također generator može koristiti prefikse atributa (npr. dat, izn) i time se mogu definirati dodatni uvjeti i svojstva u generiranim aplikacijskim komponentama.

** CRUD – skraćenica za Create, Read, Update, Delete 7

CASE2018 73

4.1 Model

Slika 9 Generator modela

Na slici 6 prikazan je generator Model-a. Osim što se mogu generirati tablice pojedinačno moguće je koristiti wildcard (*), te time stvoriti sve modele za sve tablice u bazi.

Generator generira base modele koji sadrži svojstva (atribute tablice), i osnovne metode za manipulaciju s modelom (tablicom na bazi). Kako bi se osiguralo da generirani BaseModel uvijek odgovara strukturi pripadne tablice na bazi, a to znači da se postupak generiranja BaseModel-a može periodično ili po potrebi ponovo provesti, BaseModel je proširen (extend) pripadnim Model-om koji se također može generirati, i sve dodatne prilagodbe koje nisu podržane generatorom, ručnim postupkom programiranja provode se nad takvim proširenim Model-om.

U prošireni Model se također mogu uključiti različiti statični atributi ili funkcije koje mogu služiti za osnovne SQL upite kao npr. svojstvo title, defaultOrder, tableAlias i slično.

4.2 CRUD

CRUD se odnosi na akcije unosa, čitanja, ažuriranja i brisanja 7. Na Slici 7. pokazana je forma CRUD generatora koji omogućuje generiranje potrebnih komponenti za spomenute akcije. To znači da će se za neki model u aplikaciji generirati njegove pripadne klase: Controller, ViewModel, SearchModel, view-ovi (index, view, te osnovni _create, _detail, _grid i _search), i REST API. I ovaj generator omogućuje korištenje wildcard-a (*) i time može stvoriti izvorni programski kôd (spomenutih klasa) za sve modele.

Slika 10 CRUD generator

Na slici 8 pokazan je rezultata pred pregleda generatora, pokazuje što će biti generirano.

74 CASE2018

Slika 11 Generirane CRUD forme

Proširenjem CRUD-a moguće je definirati dodatne mogućnosti nad modelima kao što su ovlasti nad tablicama, osnovni modeli pretraživanja (SearchModel) koji se može prilagođavati, kao i svaka od operacija CRUD-a.

U osnovne view-ove moguće je uključiti dodatne stupce poput stupca Akcije koji mogu sadržavati sve akcije nad tablicama, ili samo dodatne akcije specifične za taj model. Moguće je dodati i stupac s oznakama kojim se mogu označiti pojedini redovi, tj. zapisi.

5. REZULTATI GENERIRANJA

Izbornik se zbog prijašnje definiranog načina nazivanja tablica može jednostavno složiti. Obično ima više elemenata od ukupnog broja tablica u bazi. Na temelju stablastih struktura tablica iz baze (Slika 1) nastaju elementi u izborniku. Također, na temelju prefiksa tablica iz kojih se mogu prepoznati tzv. roditelj-dijete veze, može se složiti osnovni izbornik. Ali zbog potrebe dodavanja ikona, različitog grupiranja, ili mijenjanja redoslijeda u izborniku potrebno je doraditi generirani izgled izbornika.

Na temelju prijašnjeg primjera modela, Zgrada bi bila na prvoj razini, Ulaz na drugoj, Stan na trećoj a Vlasnik na četvrtoj razini. Stoga, da bi se došlo do vlasnika potrebno je krenuti od Zgrade na Ulaz pa na Stan, i zatim na Vlasnika.

Slika 12 Prikaz putanje do pregleda Vlasnika

5.1 Lista

Na Slici 10. pokazan je generirani izgled pregleda tablice ZgrUlaStan (Stan) iz prijašnjeg primjera.

Slika 13 Pregled modela ZgrUlaStan

CASE2018 75

Na pregledu su vidljivi gumb za unos, gumbi vezanih izvještaja i funkcija, kao i generirani atributi sa zapisima. Osim generiranih atributa (stupaca), generirani su i filteri i osnovno sortiranje. Pored generiranih stupaca za atribute moguće je dodati dodatne stupce kao npr. stupac za označavanje/odznačavanje zapisa, stupac sa akcijskim gumbima, boolean stupac i slično.

5.2 Forma, tipovi podataka i vanjski ključevi

Na slici 11 u nastavku vidljiva je forma za generirani model ZgrUlaStan (Stan) za pregled iz Slike 10.

Slika 14 Forma za model ZgrUlaStan

Forma prikazuje unos podataka za model ZgrUlaStan za polja (atribute) koje sadrži pripadna tablica. U ovom slučaju atributi su tekstualnog tipa, tipa upaljeno/ugašeno ili tipa padajuće liste koja pokazuje title property iz povezanog modela (tzv. „Select2“ tip).

U nastavku su i drugi tipovi prikaza atributa:

Datumski tip – unos datuma korištenjem kalendara. Zbog prijašnjeg definiranog načina nazivanja datuma sa prefiksom dat, moguće je odrediti način unosa za sve atribute datumskog tipa.

Valutni tip – unos iznosa preko „predloška“. Zbog prijašnjeg definiranog načina nazivanja iznosa sa prefiksom izn, moguće je odrediti način unosa za sve atribute valutnog tipa. Predložak iznosa mogao bi izgledati u obliku 0,00 kn. Ukoliko korisnik unese npr. 500, taj podatak pridružit će se predlošku te će krajnji prikaz biti 500,00 kn.

Select2 – za odabir vezanih atributa iz drugih tablica. Kod slučaja Narudžbe kupac će se birati iz tablice Partnera, pridružujući odabranu vrijednost iz tablice Partner u polje kupca. U padajućoj listi pokazan je stupac title property iz povezanog modela.

Padajuća lista – podatak se bira iz padajuće liste dohvaćajući mogući odabir koji je pridružen ENUM tipu podatka u tablici u bazi.

Da/Ne – odabir za atribut koji je tipa tinyint u tablici u bazi. Textbox – unos više teksta. Opcionalni odabir – odabir između ponuđenih opcija korištenjem radio gumba.

6. ZAKLJUČAK

U radu je pokazan postupak transformacije baze podataka u niz stablastih sturktura. Pokazani su i primjeri „dobre prakse“ u imenovanju konstrukata u bazi podataka. Objašnjena je potreba za proširenjem MVC obrasca strukture aplikacije. Objašenjen je način stvaranja proširenog MVC obrasca.

Korištenjem generatora moguće je stvoriti veći dio aplikacije osnovnog izgleda, tj. dijelove koji su jednaki za sve modele i time dobiti osnovni izgled aplikacije. Generator omogućuje dobivanje osnovnih funkcionalnosti pregled podataka, forme za unos i izmjenu (ažuriranje), i akcije brisanja i pretraživanja. Korištenjem generatora smanjuje se vrijeme potrebno za dobivanje koristive aplikacije i izbjegava se trošak vremena na pisanje kôda za osnovne funkcionalnosti.

Kako se generatori mogu proširiti sa različitim funkcionalnostima moguće je smanjiti vrijeme stvaranja aplikacije, tj. jednom kad se generator ispravno posloži moguće ga je primijeniti za drugu aplikaciju značajno smanjujući vrijeme utrošeno za njezinu izgradnju. Zbog tog razloga su generatori korisni prilikom stvaranja aplikacije.

76 CASE2018

Literatura

1 https://www.w3c-lab.com/what-is-the-difference-between-mvc-and-mvvm/

2 https://documentation.progress.com/output/ua/OpenEdge_latest/index.html#page/gsdbe/elements-of-a-relational-database.html

3 http://www.yiiframework.com/doc-2.0/guide- structure-models.html

4 http://www.yiiframework.com/doc-2.0/guide- structure-views.html

5 http://www.yiiframework.com/doc-2.0/guide- structure-controllers.html

6 http://www.yiiframework.com/doc-2.0/guide-intro-yii.html

7 http://www.yiiframework.com/doc-2.0/guide-start-gii.html

8 Kaluža, M., Abazović, D.: Hijerarhijski prikaz sheme baze podataka kao temelj za pretraživanje, rudarenje i OLAP, Zbornik radova CASE 23, CASE, Rijeka, 2011.

9 Kaluža, M.: Modifications on data model, Zbornik radova IIS 2007, Fakultet organizacije i informatike, Varaždin, 2007.

Podaci o autorima:

Ivona Čančar e-mail: ivona@mapro.hr Dino Abazović e-mail: dino@mapro.hr Mapro d.o.o. Bože Vidasa 20 51000 Rijeka dr. sc. Marin Kaluža e-mail: mkaluza@veleri.hr Marin Kaluža je viši predavač na Veleučilištu u Rijeci i nositelj nekoliko kolegija iz područja razvoja softvera i informacijskih sustava, te upravljanja i razvoja baza podataka. Doktorirao je na Filozofskom fakultetu u Zagrebu na problemima mjerenja i analize složenosti poslovnih sustava. Područje njegovog istraživanja je brzi, rapidni i agilni razvoj softvera, standardizacija i automatizacija u razvoju softvera i korisničkih sučelja. Vodio je projekte razvoja većeg broja informacijskih sustava iz područja školstva, industrijske proizvodnje, zaštite na radu, ekonomije i medicine. Veleučilište u Rijeci Vukovarska 58 51000 Rijeka

CASE2018 77

ADITIVNE TEHNOLOGIJE I INDUSTRIJA 3D TISKANJA

Mateo Višković, univ. bacc. inf., doc. dr. sc. Tihomir Orehovački

SAŽETAK

Zahvaljujući brojnim prednostima, aditivne tehnologije svoju svrhu sve više pronalaze u različitim granama industrije. Da bi se razumjele njihove mogućnosti, potrebno je napomenuti kako 3D printanje nije samo ispisivanje materijala po trima osima, već su osnovni principi rada 3D pisača puno kompleksniji. Isti započinju izradom 3D modela koji se pohranjuje u određenome formatu ovisno o potrebama projekta. Spomenute modele je nakon toga potrebno konvertirati u kod čitljiv računalu. Slijedi odabir najprikladnije aditivne metode koji se svodi na vrstu materijala koji se koristi te na tehniku kojom će model biti izrađen. Odabir metode također ovisi i o industriji u kojoj je predviđena njena primjena. Prema tome je moguće razlikovati stereolitografiju, selektivno lasersko sinteriranje, modeliranje nanošenjem rastopljenog materijala, laminiranu objektnu proizvodnju, 3D tiskanje i druge aditivne metode. U ovom će radu biti opisane industrijske grane u kojima je primjena aditivnih tehnologija najzastupljenija kao i dostignuća koja su u istima ostvarena.

ABSTRACT

Thanks to their various advantages, additive technologies are increasingly found in different branches of many industries. In order to understand the possibilities of additive technologies, it is necessary to emphasize that 3D printing is not just casting materials by three axes yet basic principles by which 3D printing works are much more complex. They start by creating a 3D model which is stored it in a certain format depending on the demands of the project. Mentioned models need to be afterwards converted to code readable to computer. As a follow up, the most suitable additive method is chosen, which add up to the type of material used and the technique employed to make the model. The choice of method also differs depending on which industry is anticipated for its application. In that respect, it is possible to distinguish stereolithography, selective laser sintering, modeling by melted material, laminated object production, 3D printing and others additive methods. In this paper we will describe industrial branches in which the use of additive technologies is the most prominent as well as achievements that are reached in them.

1. UVOD

U kontinuiranom industrijskom napretku, aditivne tehnologije nam mogu pružiti željeni odmak od klasičnih načina proizvodnje. Sam princip rada može se razlikovati zbog materijala koji se koriste i načina na koji se modeli izrađuju. Upotrebom materijala različitih svojstava koje drugim metodama nije moguće kombinirati, otvaramo mogućnosti izrade preciznijih, čvršćih i po potrebi elastičnijih modela. Prilikom izrade modela, možemo razlikovati aditivne procese koji nanose vezivno sredstvo na prethodno naneseni materijal i procese koji direktno nanose materijal koji će sačinjavati model. Ovisno o vrsti procesa koji se koristi, također se otvaraju mogućnosti izrade kompleksnih dijelova kojih dosada nije bilo moguće izraditi. Osim kompleksnosti, smanjeno je i vrijeme same izrade kao i težina izrađenih dijelova. Nabrojene prednosti prepoznate su u gotovo svim industrijskim granama što je omogućilo aditivnim tehnologijama ulazak u različita područja. Otvaranjem novih područja aditivnim tehnologijama stvaraju se nebrojne mogućnosti za poboljšanjem i razvijanjem što se potkrjepljuje zavidim prihodom kojega ostvaruju.

2. PRINCIP RADA 3D TISKANJA

Kada je riječ o 3D tiskanju, najčešće sve započinje kreiranjem virtualnog modela koji se želi izraditi. Za izradu 3D modela koristi se CAD

†† proces pomoću kojega računala stvaraju pripadajuću dokumentaciju i dizajn. Upotrebom CAD-a postiže

se veća točnost proračuna te se smanjuje vrijeme od razvitka ideje do izrade gotovog modela što najčešće povećava produktivnost i kvalitetu dizajna. Izrada modela započinje odabirom odgovarajućeg 3D softvera ili 3D skenera u kojemu se model konceptualizira. Zatim se izrađeni model pohranjuje u datoteku odgovarajuće ekstenzije (kao što su stl, obj, 3mf i drugi) koja je čitljiva 3D pisaču. Jednom kada je datoteka učitana na 3D pisač, ista se konvertira u numerički kontrolirani računalni jezik G-kod čije se naredbe mogu vidjeti na slici 1.

††

Computer Aided Design (dizajn potpomognut računalom)

78 CASE2018

Slika 1. G-kod naredbe (Technosoft, 2011) [12]

Jedan od programa koji konvertira datoteke u G-kod je Slic3, a potreba za konverzijom dolazi iz razloga što G-kod kao i pisač koriste računalno potpomognutu proizvodnju gdje je bez G-koda nemoguće komunicirati sa strojem. Komunikacija se odvija tako što se pomoću G-koda navodi stroj po x, y i z osi, te mu se daju naredbe gdje treba sjeći, položiti i sinterirati materijal, a pisač koji se sastoji od mini sustava s numeričkim upravljanjem očitava naredbe G-koda. Iz navedenog je evidentno da datoteke pretvorene u G-kod pružaju nacrt i upute za sljedećih nekoliko tisuća poteza pisača što na kraju rezultira izradom gotovog 3D modela. Također je važno odabrati metodu kojom će se izvršiti proces izrade modela, a odabir metode mora se temeljiti na tipu modela koji želimo izraditi, njegovoj kompleksnosti, čvrstoči i preciznosti. U mnoštvu metoda možemo birati između onih koje tope materijale kako bi izradile slojeve, onih koje režu tanke slojeve materijala koje zatim spajaju zajedno te onih koje slažu tekuće termosetove koji se zatim očvršćuju u jednu cjelinu. Ovo su samo neke od mogućnosti koje se primjenjuju, a moguće je birati između više od četrdeset različitih proizvodnih postupaka. Iako su mnoge nedostupne za komercijalne svrhe, između onih dostupnih najčešće se primjenjuju stereolitografija, selektivno lasersko sinteriranje, direktno lasersko sinteriranje metala, modeliranje nanošenjem rastopljenog materijala, laminirana objektna proizvodnja, izravno taloženje metala laserom, 3D tiskanje i 3D tisak mlazom fotopolimera.

3. STEREOLITOGRAFIJA

Stereolitografija (SLA, eng. Stereolithography) razvijena je od strane tvrtke 3D Systems 1986. godine i ubraja se među jednu od najstarijih metoda brze izrade prototipova. Sam proces započinje izradom CAD modela koji se kao i kod svih metoda pretvara u odgovarajuću datoteku, a u ovome slučaju je to STL. Dobivene informacije upotrebljavaju se kao nacrt za izradu kod kojega se koriste različite vrste fotopolimera u tekućem stanju osjetljive na ultraljubičasto (UV) zračenje. Daljnji proces se odvija tako da se tekući polimeri skrućuju u slojeve koristeći laserski snop zraka odnosno UV zračenje. Nakon što je jedan sloj završen, platforma u posudi s polimerom vidljiva na slici 2 pomiče se prema dolje te se uranja u tekući polimer sve dok zadnje izrađeni sloj nije ispod površine na dubini između 0,5 i 0,25 mm.

Slika 2. Izrada stereolitografijom (PrintSpace 3D, 2016) [10]

CASE2018 79

Zbog preciznosti daljnje izrade, kroz površinski sloj posude prolazi oštrica koja poravnava prethodno izrađeni sloj koji se zbog adhezivnih svojstva materijala spojio s prethodno nanesenim. Navedeni postupak se ponavlja do završetka procesa, a debljina sloja odnosno pomak prema dolje i rezolucija ovise o opremi koja se koristi. Po završetku procesa, platforma se podiže iznad tekućeg fotopolimera radi cijeđenja proizvoda koji se tada dodatno čisti i po potrebi obrađuje. Kod ove metode bitno je uočiti da će završeni proizvod biti stepeničastog oblika zbog slojevitog procesa izrade. Ukoliko želimo smanjiti vidljivost stepenica između slojeva, to možemo učiniti manjim pomakom platforme tijekom izrade ili orijentiranjem modela na način da se dulja os postavi vertikalno. Međutim, tim se načinom povećava vrijeme izrade.

4. SELEKTIVNO LASERSKO SINTERIRANJE

Za razvitak procesa selektivnog laserskog sinteriranja (SLS, eng. Selective Laser Sintering) zahvale pripadaju sveučilištu u Teksasu gdje je isto 1987. godine razvijeno te patentirano dvije godine kasnije. Prvi SLS sistem lansiran na tržište 1992. godine imao je isti početni proces razvoja CAD modela kao i SLA, ali se razlikovao u daljnjem procesu. SLS je za razliku od SLA imao prednost korištenja desetak različitih materijala koji se nalaze u praškastom obliku. Proces se zbog korištenja praškastog materijala odvijao na način da bi se isti nanio na platformu, a zatim bi se pomoću laserske zrake CO2 solid-state lasera pogađao naneseni materijal koji se zbog svojih svojstava pri visokoj temperaturi sinterirao

‡‡ kao

što je prikazano na slici 3.

Iako se tijekom SLS postupka materijal nanosio u slojevima kao i kod SLA, razlikovali su se u načinu nanošenja koji se kod SLS odvijao tako da bi se sljedeći sloj praška nanosio na prethodno napravljeni sloj pomoću rotirajućeg cilindra. Taj bi cilindar iz komore s materijalom nanosio materijal u komoru za modeliranje, a sav materijal koji ne bi bio sinentiran služio je kao potpora modelu prilikom izrade. Krunić et. al. [7] naglašava da se „fizikalne karakteristike produkata stvorenih sinteriranjem mogu lako mijenjati promjenom gustoće, stvaranjem legura ili daljnjim pečenjem, a finalni proizvod može biti i mnogo čvršći nego onaj napravljen konvencionalnim metodama.“

Slika 3. Izrada Selektivnim laserskim sinteriranjem (PrintSpace 3D, 2016) [10]

5. DIREKTNO LASERSKO SINTERIRANJE METALA

Slika 4. Izrada direktnim laserskim sinteriranjem metala (Additively, n.d.) [1]

‡‡

Proces kod kojega se uslijed visoke temperature povećava adhezija čestica praha, što rezultira njihovim spajanjem u cjelinu.

80 CASE2018

DMLS (eng. Direct Metal Laser Sintering) metoda radi na principu topljenja metalnog pudera čijim se naknadnim skrućivanjem kreira slojevita struktura pune gustoće. Iz razloga što se svaki sloj izrađuje zasebno, omogućena je izrada prijelaza, šupljina i drugih unutrašnjih oblika koje ne bi bilo moguće izraditi lijevanjem ili nekim drugim načinom. Osim toga, prednosti DMLS metode su kraće vrijeme izrade koje omogućuje izradu modela unutar nekoliko sati, izrada nekoliko različitih modela različitih legura istovremeno te izrada modela visoke rezuolucije i kvalitete te najkompleksnije geometrije.

Sam proces izrade razlikuje se od ostalih metoda u tome što se kod DMLS metode koristi visoko napajani Yb optički svjetlosni laserski val snage 200W pomoću kojega se tope čestice metalnog praha u svrhu kasnijeg spajanja radi dobivanja željene forme. Metalni prah dostavljen platformom za isporuku materijala pomoću noža za pomicanje vidljivog na slici 4 nanosi sloj praha na platformu za gradnju, a svaki novi dostavljen sloj iznosi otprilike 20 mikrometara [13].

6. MODELIRANJE NANOŠENJEM RASTOPLJENOG MATERIJALA

Modeliranje nanošenjem rastopljenog materijala (FDM, eng. Fused Deposition Modeling) razvijeno od tvrtke Strarasys Corp. 1980-ih godina koristi se u svrhu konceptualnog modeliranja radi brze izrade modela na kojima se provjeravaju greške proizvoda. Osim toga, služi i za testiranje aerodinamičnosti, fluidnosti te ostala testiranja.

Premda se početni proces ne razlikuje od ostalih RP metoda, u proizvodnom procesu razlika je vidljiva već kod dostave plastike, najčešće u vlaknastom obliku namotane na kolotur. Dostavljena plastika ekstrudira se kroz mlaznicu malog promjera, a da bi materijal lakše tekao kroz mlaznicu i uspješno formirao sloj, mlaznica se sastoji od grijača koji održavaju temperaturu na višoj razini od temperature taljenja plastike. Jednom kada plastika prođe kroz mlaznicu koja se kreće u x-y ravnini, ona se stvrdnjava i tako kreira sloj. Nakon što je sloj izrađen, platforma vidljiva na slici 5 spušta se po z osi te se postupak ponavlja. „Ovisno o promjeru mlaznice, debljina sloja i vertikalna dimenzijska točnost mogu se kretati između 0,127 i 0,33 mm, a točnost izrade može postići čak i do 0,0254 mm. Osim velike točnosti, stroj ima mogućnost korištenja pomoćnog materijala koji se doprema kroz njegovu mlaznicu, a zbog uporabe mlaznica malog promjera ostaje mala količina neiskorištenog materijala.“ [14]

Slika 5. Izrada nanošenjem rastopljenog materijala (FDM) (CustomPartNet, 2008) [4]

7. LAMINIRANA OBJEKTNA PROIZVODNJA

Laminirana objektna proizvodnja (LOM, eng. Laminated Object Manufacturing) slovi za jednog od bržih RP postupaka u svrhu izrade većih modela složenije geometrije korištenjem materijala kao što su papir, polimeri ili kompoziti. Postupak razvijen u Kaliforniji od strane Helisys Corp. radi na hibridnom principu dodavanja i oduzimanja materijala. Princip rada je takav da se sloj materijala s ljepljivom prevlakom nanese na platformu kao što je vidljivo na slici 6 preko kojega zatim prelazi zagrijani valjak. Zbog svojstava ljepljive prevlake. ona se u dodiru s toplinom lijepi na platformu ili prethodno naneseni sloj. Jednom kada je sloj nanesen, isti se pomoću sustava pomičnih zrcala i laserske zrake izrezuje po predviđenim konturama modela. Sam postupak rezanja konture moguće je obaviti pomoću Solido noževa, te se po završetku rezanja platforma spušta za debljinu sloja. Po završetku izrade, model je potrebno odvojiti od viška izrezanog materijal i ovisno o korištenome materijalu nanijeti impregnacijsko sredstvo radi zaštite od vremenskih utjecaja.

CASE2018 81

Slika 6. Izrada laminiranom objektnom proizvodnjom (Ahn, et. al., 2012) [2]

8. IZRAVNO TALOŽENJE METALA LASEROM

LENS (eng. Laser Engineering Net Shaping) razvijen od tvrtki članica Cooperative Research and Development Agreement-a (CRADA) u Sandia National Laboratories-u ubraja se među prve RP postupke koji se služe metalima (nehrđajući čelik, aluminij, bakar, titan i drugi kompozitni materijali) prilikom izrade. Proces se odvija dodavanjem određene količine metalnog praha kroz četiri mlaznice vidljive na slici 7 u točku fokusa laserske zrake. Dodani materijal dolaskom u točku fokusa se pomoću Nd:Yag lasera snage 700W zavaruje na radnu površinu ili prethodno zavareni sloj. Zanimljivo je da se zbog mogućnosti kretanja mlaznice po x i y osi materijal najprije nanosi na konture modela, te se tek tada počinje ispunjavati unutrašnjost. Osim kretanja po x i y osima, ima mogućnost pomicanja i po z osi čime je omogućeno pomicanje platforme prema gore ili dolje radi izrade sljedećeg sloja. Da bi model ostao stabilan tijekom izrade, izrađuje se i potporna struktura koju je kasnije potrebno mehanički odvojiti od modela. Zbog izrade potporne strukture, onemogućena je izrada dijelova s izbočinama i unutrašnjim šupljinama jer bi se iste u dodiru s potpornom strukturom sjedinile.

Slika 7. Izrada izravnim taloženjem metala laserom (Popoola, et. al., 2016) [9]

Prema Cooperu G. [3], „LENS uređaj može postići točnost od ±0,5 mm u visinu i širinu, a debljina sloja može biti između 0,0245 i 1,016 mm. Zbog brzine izgradnje od 16,387 cm

3/h mora koristiti jedinicu za hlađenje lasera snage 20800W na

površini od najmanje 7m2.“

82 CASE2018

9. 3D TISKANJE

Slika 8. Izrada 3D tiskanjem (Rison prototype, 2015) [11]

3DP (kratica od eng. 3D printing) razvijena na MIT-u (kratica od eng. Massachusetts Institute of Technology) 1989. godine jedna je od mlađih tehnika modeliranja čiji je naziv postao pseudonim za gotovo sve RP tehnologije. Radni proces stroja za 3D tisak vidljiv na slici 8 počinje punjenjem komore praškastim materijalom slojem debljine 3,18 mm koji se zagrijavanjem komore i sam zagrijava. Radi lakšeg kasnijeg uklanjanja modela iz stroja prvi naneseni sloj služi kao potpora odnosno stalak prototipu. Iznad izrađenog sloja pomoću rotirajućeg klizača nanosi se novi sloj debljine 0,1 mm na kojem mlaznica prema informacijama dobivenima iz STL datoteke putem x i y osi ispušta (ovisno o mogućnostima printera) tekuće vezivo i boju. Kod ove metode također postoji pomična platforma po z osi koja se spušta za visinu sloja koji se može razlikovati između 0,080 i 0,250 mm. Uz prvi izrađeni sloj za potporu koristi se i sav materijal koji se nalazi u komori za izgradnju, a nije povezan tekućim vezivom. Ukoliko se želi utjecati na točnost i brzinu izrade modela, onda se to može učiniti orijentiranjem modela vertikalno ili horizontalno. Za modele s velikom količinom osjetljivih podataka, tiskanje se obavlja u vertikalnom položaju sa slojem izrade smanjenim na 0,089 mm i povećanom količinom veziva potrebnog za spajanje praha u svrhu kvalitetnije izrade tankih stjenki prototipa. Horizontalna izrada se primjenjuje ukoliko je potrebna smanjena točnost, ali brža isporučivost modela. Nakon izrade slijedi usisavanje praha iz komore u zasebni spremnik čime je omogućena ponovna upotreba neiskorištenog materijala. Model oslobođen od potpornog materijala se propuhuje u zasebnoj komori te se ostavlja radi sušenja. Duljina sušenja također ovisi i o orijentaciji izrade jer će se kod vertikalno orijentiranog modela ojačanjem stjenki modela produžiti vrijeme sušenja za razliku od horizontalno orijentiranog modela.

10. 3D TISAK MLAZOM FOTOPOLIMERA

Slika 9. Izrada pomoću 3D tisaka mlazom fotopolimera (CustomPartNet, 2008) [5]

CASE2018 83

3DP PJ (kratica od eng. 3D Printing-Photopolymer Jetting) postupak se koristi procesom polimerizacije pomoću UV lampe. Iako je sličan stereolitografiji gdje se model uranja u tekući polimer, kod 3DP PJ to nije slučaj jer se on koristi metodom inkjet. 3DP PJ informacije o slojevima koji iznose 0,015 mm i ostale specifikacije dobiva iz STL datoteke, a kretanjem po x i y osima pomoću dvije glave pisača vidljive na slici 9 koje su sastavljene od nekoliko stotina mlaznica čak i do 1536 nanosi fotopolimer na radnu površinu, svaki sloj zasebno. Kao i kod ostalih metoda, nanosi se potporni sloj, ali u ovome slučaju to se događa istovremeno s nanošenjem sloja kojim se kreira model. Nakon što su slojevi naneseni, oni se polimeriziraju korištenjem UV lampe i radna se površina spušta po z osi radi nanošenja novoga sloja. Postupak se ponavlja sve do završetka procesa kada je model potrebno odvojiti od potpornog dijela. Odvajanje se može izvršiti na nekoliko načina ovisno o korištenoj tehnologiji bilo to taljenjem u peći (postupak tvrtke Objet) ili topljenjem u vodi (postupak tvrtke 3D Systems).

Najvažnije obilježje svake metode, pa i ove je preciznost. Stoga je Objet Geometries iz Izraela razvila proces PolyJet koji postiže točnost između 0,1 i 0,3 mm i ProJet koji postiže točnost od čak 0,025 do 0,05 mm s mogućnošću kreiranja stjenki debljine od 0,6 mm koje se trenutno smatraju jednim od najkvalitetnijim kreiranim površinama u industriji brzog prototipiranja (eng. Rapid Prototyping, RP). U daljnjim istraživanjima tvrtka Objet Geometries razvila je novu generaciju RP tehnologija pod nazivom PolyJet Matrix. Primjena PolyJet Matrix-a u uređaju Connex 500 omogućuje istovremeno nanošenje različitih materijala. Leko (str. 21) [8] navodi da je „time otvorena mogućnost da model bude izgrađen od različitih materijala te ima različita mehanička i fizička svojstva. Pored toga, moguće je miješati materijale te tako dobivati kompozite specifičnih mehaničkih svojstava pod nazivom digitalni materijali (eng. Digital Materials). Miješanjem materijala moguće je proizvesti do 60 različitih plastomera i elastomera koji imitiraju svojstva standardnih materijala.“

11. INDUSTRIJA 3D TISKANJA

Prema istraživanjima specijaliziranim za aditivnu proizvodnju i 3D tiskanje koje provodi Wohlers Associates [16], ista je u obliku Wohlers izvještaja 2016. godine došla do zaključka da industrija aditivne proizvodnje (eng. Additive Manufacturing, AM) bilježi rast od 17.4% u odnosu na 2015. godinu. Gledajući samo 2016. godinu, ukupni prihod ove industrije iznosio je 6,063 milijardi dolara, a ukoliko se izuzmu dvije najveće tvrtke 3D Systems i ExOne koje trenutno stagniraju, industrija bi imala porast od čak 24.9%. Analizom podataka prikupljenih unatrag zadnjih deset godina po industrijskim sektorima, u grafu 1 je vidljivo da AM ostvaruje najveći rast (10.5%) u zrakoplovnoj industriji te u korištenju industrijskih strojeva (9%) dok najveći pad bilježi u potrošačkim proizvodima / elektronici od čak -10.9% te medicini / stomatologiji od -2.6%. Iako su AM u medicini / stomatologiji ostvarile pad, njihov udio od 11% u sveukupnom prihodu iznosi 667 milijuna dolara.

11.1 Primjeri upotrebe adtivnih tehnologija

Premda je opće poznato da se AM najčešće primjenjuje u zrakoplovnoj industriji u svrhu izrade modela radi testiranja protoka zraka, otpora i slično, ono što je manje poznato jest da se AM primjenjuje i u svrhu izrade raketnih motora. Dijelovi raketnog motora GE 2016. godine izrađeni su pomoću AM metode izravnog taloženja metala laserom [15]. Tako izrađene mlaznice za gorivo olakšane su za 25%, a dotadašnjih 18 dijelova koji su sačinjavali mlaznice pretvoreni su u jedan dio čime je za pet puta povećana izdržljivost mlaznica. Osim olakšanja procesa izrade, smanjena je i potrošnja goriva za čak 15%. Tvrtka si je upotrebom AM-a priskrbila 100.000 novih narudžbi u vrijednosti od 145 milijardi dolara. NASA trenutno u sklopu programa SpaceX radi na izradi prvog 100% tiskanoga raketnog motora, a može se pohvaliti i prvim bakrenim raketnim motorom čijih je 75% izrađen primjenom AM.

Graf 1. AM po industrijskim sektorima prema podacima iz Wohlers izvještaja

Osim zrakoplovne industrije, automobilska industrije također koristi AM u svrhu izrade konceptualnih modela čime je smanjen trošak proizvodnje kao i vrijeme razvoja. Primjena koja traje već nekoliko desetljeća se odnosi na izradu prototipova pa sve do gotovih dijelova kao što su spojke, mjenjačke kutije, dijelovi ovjesa, upravljački mehanizmi i dr. Zanimljiviji primjeri korištenja AM u automobilskoj industriji su izrada uskog unutarnjeg turbo kućišta na automobilu

84 CASE2018

Koenigsegg One:1, izrada dijelova za Williams F1 bolid, proizvodnja Hankook guma pa čak i tiskanje potpuno funkcionalnog automobila na međunarodnom auto show-u u Detroitu 2014. godine. Jedan od sektora gdje je AM također pronašao svoju primjenu je svakako medicina. Navedeno se osim već poznatih primjera izrade modela ljudskih kostiju za izučavanje istih te izrade prototipova ortopedskih pomagala odnosi i na izradu implantata, zamjenskih kostiju i presađivanja kože. Poznati su primjeri izrade krvožilnog sustava izrađenog PolyJet postupkom na temelju modela dobivenog CT skenom. Taj je model 2002. godine omogućio liječnicima uvid u anatomiju lubanja sijamskih blizanki koje su bile istom povezane. Upotrebom AM olakšana je odluka o operaciji te je vrijeme operacije s 97 skraćeno na 23 sata. Napredak korištenja AM-a u medicini također je vidljiv kroz primjere Kyoto University Graduate School of Medicine u Japanu gdje su tiskane prve umjetne kosti koje su upotrijebljene na ljudima, a u tijeku je razvijanje postupka presađivanja kože. Prvi test presađivanja je uspješno obavljen i trenutno se radi na tehnologiji za skeniranje rane kojom bi se direktno tiskala nova koža na ranu. Navedeni primjeri su samo dio mogućnosti AM-a, a svoju daljnju primjenu tek treba ostvariti upotrebom novih materijala kao i njihovom kombinacijom.

12. ZAKLJUČAK

Za aditivne tehnologije možemo reći da su dobrodošla revolucija u svakoj grani industrije. Njihovom se primjenom otvaraju nove mogućnosti izrade koje su dosada bile nemoguće putem postojećih konvencionalnih metoda. Primjenom postupaka kao što su direktno lasersko sinteriranje metala gotovo ne postoje oblici koje je nemoguće izraditi putem AM. Iako skupa nabavna cijena strojeva i materijala djelomično koči primjenu aditivnih tehnologija, njihovom se primjenom ostvaruju značajne uštede. Aditivne tehnologije imaju utjecaj i na cijenu gotovih proizvoda jer se lakšom i bržom proizvodnjom omogućuje nabava proizvoda bolje kvalitete po nižim cijenama. Prednosti aditivnih tehnologija su svakako uočene i iskorištene, no mjesta za njihov daljnji razvitak ne nedostaje. Stoga se temeljem svega što je izneseno u ovom radu može zaključiti da vrijeme aditivnih tehnologija tek dolazi.

Literatura:

1 Additively, (2016), Laser melting. [Internet], <raspoloživo na: https://www.additively.com/en/learn-about/laser-melting > [pristupljeno 17. siječnja 2018]

2 Ahn D.,Kweon J.,Choi H.,Lee S., (2012), Quantification of surface roughness of parts processed by laminated object manufacturing. [Internet], < raspoloživo na: https://www.sciencedirect.com/science/article/pii/S0924013611002391 > [pristupljeno 21. siječnja 2018]

3 Cooper G. K., (2001) Rapid Prototyping Technology: Selection and Application, New York: Marcel Dekker, Inc. <raspoloživo na: https://sseaimes.files.wordpress.com/2013/03/rapid-prototyping-technology-kenneth-cooper.pdf >, [pristupljeno 27. prosinca 2017]

4 Custompartnet, (2008), Fused depostition modeling. [Internet], <raspoloživo na: http://www.custompartnet.com/wu/fused-deposition-modeling > [pristupljeno 19. siječnja 2018]

5 Custompartnet, (2008), Jetted Photopolymer. [Internet], <raspoloživo na: http://www.custompartnet.com/wu/jetted-photopolymer > [pristupljeno 19. siječnja 2018]

6 Horvat, M., (2016), Pregled aditivnih postupaka proizvodnje, Završni rad, Odjel za proizvodno strojarstvo, Sveučilište sjever, <raspoloživo na: https://dr.nsk.hr/islandora/object/unin%3A851/datastream/PDF/view>, [pristupljeno 21. prosinca 2017]

7 Krunić, S., Perinić, M., Maričić, S., (2010), Načini brze izrade predserijskih proizvoda, Hrčak, izdanje 30, 2 (10), <raspoloživo na: https://hrcak.srce.hr/file/95455>, [pristupljeno 8. siječnja 2018]

8 Leko, H., (2015), 3D Pisači, Završni rad, Grafički fakultet Zagreb Sveučilište u Zagrebu, <raspoloživo na: http://eprints.grf.unizg.hr/2239/1/Z576_Leko_Helena.pdf>, [pristupljeno 10. siječnja 2018]

9 Popoola P., Farotade G., Fatoba O., Popoola P., (2008), Laser Engineering Net Shaping Method in the Area of Development of Functionally Graded Materials (FGMs) for Aero Engine Applications. [Internet], <raspoloživo na: https://www.intechopen.com/books/fiber-laser/laser-engineering-net-shaping-method-in-the-area-of-development-of-functionally-graded-materials-fgm > [pristupljeno 19. siječnja 2018]

10 Printspace3D, (2016),3D printing Processes. [Internet], <raspoloživo na: https://www.printspace3d.com/what-is-3d-printing/3d-printing-processes > [pristupljeno 12. siječnja 2018]

11 Rison prototype, (2015), 3D Printing technologies types and how it works. [Internet], <raspoloživo na: http://www.risonprototype.com/printing-technologies-types-and-how-works-a-25.html > [pristupljeno 23. siječnja 2018]

12 Technosoft, (2011),G- code supported blocks. [Internet], <raspoloživo na: http://www.technosoftmotion.com/ESM-um-html/index.html?help_gcode_word_list.htm > [pristupljeno 27. prosinca 2017]

13 Verma, A., Tyagi, S., Yang, K., (2014), Modeling and optimization of direct metal laser sintering process, International Journal of Advanced Manufacturing Technology, izdanje. 77, <raspoloživo na: http://web.b.ebscohost.com/ehost/pdfviewer/pdfviewer?vid=26&sid=a9a6941d-2c0c-4c57-ba81-9da9d4005d00%40sessionmgr102>[pristupljeno 13. siječnja 2018]

14 Višković, M., (2017), 3D pisači i njihova primjena, Završni rad, Odjel za informacijsko-komunikacijske tehnologije, Sveučilište Jurja Dobrile u Puli, <raspoloživo na: https://www.bib.irb.hr/893991 >, [pristupljeno 9. siječnja 2018]

15 Winick, E., (2017), Additive Manufacturing in the Aerospace Industry, engineering.com, < raspoloživo na: https://www.engineering.com/AdvancedManufacturing/ArticleID/14218/Additive-Manufacturing-in-the-Aerospace-Industry.aspx >, [pristupljeno 15. siječnja 2018]

CASE2018 85

16 Wohlers associates, (2017), Wohlers report, <raspoloživo na: https://wohlersassociates.com/ > [pristupljeno 20. siječnja 2018]

Podaci o autorima:

Mateo Višković, univ. bacc. inf. e-mail: mviskov@unipu.hr Mateo Višković je student prve godine diplomskog studija informatike na Fakultetu informatike (prije Odjel za informacijsko-komunikacijske tehnologije) Sveučilišta Jurja Dobrile u Puli. Zbog velikog interesa za programiranjem, posebice u jezicima C++ i Java, završio je Udemy online tečaj pod nazivom „Complete Java Masterclass“ dok trenutno pohađa tečaj iz područja programiranja za Web. Pored programiranja, predmet njegova interesa predstavljaju još i multimedija te 3D pisači i njihova primjena. doc. dr. sc. Tihomir Orehovački e-mail: tihomir.orehovacki@unipu.hr Tihomir Orehovački diplomirao je i doktorirao 2005. i 2013. godine, respektivno, na Fakultetu organizacije i informatike Sveučilišta u Zagrebu. Pedagoško-psihološko-didaktičko-metodičku naobrazbu stekao je tijekom akademske godine 2005./2006. na Visokoj učiteljskoj školi u Čakovcu (danas Učiteljski fakultet Sveučilišta u Zagrebu, Odsjek u Čakovcu). Od 1. listopada 2015. godine zaposlen je na radnom mjestu docenta na Odjelu za informacijsko-komunikacijske tehnologije (danas Fakultet informatike) Sveučilišta Jurja Dobrile u Puli gdje je nositelj kolegija vezanih uz programiranje. Član je Povjerenstva za akademsko priznavanje inozemnih visokoškolskih kvalifikacija i razdoblja studija te Odbora za znanstveni i umjetnički rad Sveučilišta Jurja Dobile u Puli. Autor je 75 znanstvenih radova objavljenih u zbornicima međunarodnih konferencija, časopisima i knjigama te 10 stručnih radova objavljenih u zbornicima domaćih skupova. Znanstveno se i stručno usavršavao na brojnim radionicama i institucijama u zemlji i inozemstvu. Bio je voditelj projekta financiranog sredstvima HRZZ. Osim toga, sudjelovao je u istraživačkim aktivnostima projekata financiranih sredstvima Europske Unije, Zaklade Adris, Ministarstva znanosti i obrazovanja te Sveučilišta u Zagrebu. Bio je suorganizator i predavač na 2 radionice vezane uz upravljanje međunarodnim projektima i 7 radionica vezanih uz primjenu društvenih Web aplikacija u obrazovanju. Aktivni je recenzent za 15 međunarodnih znanstvenih časopisa, 2 znanstvene knjige i 11 međunarodnih znanstvenih konferencija. Vršio je dužnost člana Programskog odbora, voditelja tematskih cjelina i sekcija sljedećih međunarodnih znanstvenih konferencija: International Conference on Information Systems Development (ISD), ACM International Conference on Intelligent User Interfaces (IUI), International Conference on the Quality of Information and Communications Technology (QUATIC) - Track on Quality in Web Engineering te International Conference on Information Technology (ICIT). Bio je član Organizacijskog odbora, urednik knjige sažetaka i tehnički urednik zbornika radova međunarodne znanstvene konferencije ISD 2014. Član je sljedećih međunarodnih strukovnih udruženja: Association for Computing Machinery, European University Information Systems E-Learning Task Force, Institute of Electrical and Electronics Engineers i International Society for Web Engineering. Za svoj znanstveni, nastavni i stručni rad primio je nekoliko međunarodnih i domaćih nagrada i priznanja. Dosad je pod njegovim mentorstvom 49 studenata obranilo završne i diplomske radove. Fakultet informatike u Puli, Sveučilište Jurja Dobrile u Puli Zagrebačka 30, 52100 Pula

86 CASE2018

CASE2018 87

PROGRAMIRANJE UREĐAJA ZA INTERNET STVARI

Mislav Hager, univ. bacc. inf., doc. dr. sc. Tihomir Orehovački

SAŽETAK

Pojam Internet stvari (eng. Internet of Things, IoT) predstavlja mrežu međusobno povezanih uređaja. Premda kao koncept postoji već duže vrijeme, tek je u posljednjih nekoliko godina došlo do porasta primjene ove tehnologije. Internet stvari povezuje uređaje i fizičke objekte iz okoline u globalnu mrežu temeljenu na IP protokolu. Iako su primjene IoT-a brojne, u prvom je redu riječ o aplikacijama koje korisniku omogućuju dijeljenje resursa. Svrha IoT-a je omogućiti umrežavanje različitih stvari i objekata iz svakodnevnog života te njihovu međusobnu komunikaciju putem Interneta, bez ljudske interakcije, a sve s ciljem poboljšanja uvjeta i načina na koji živimo. Tehnološki napredak i razvoj senzora, aktuatora, skladišta podataka i mrežnih mogućnosti proširuju horizonte mogućih scenarija primjene Interneta stvari. U ovom je radu prikazan i objašnjen cjelokupan scenarij pripreme i korištenja senzora za temperaturu i vlažnost zraka te računala Raspberry Pi, od instalacije operativnog sustava na računalo do izrade programa i senzora za temperaturu i vlažnost zraka provedbe prikupljanja podataka.

ABSTRACT

The term Internet of Things (IoT) represents a network of interconnected devices. As a concept, Internet of Things has been around for a number of years, but its expansion has only started a few years ago. Internet of Things connects devices and physical objects from the environment in a global network based on IP protocol. IoT offers a variety of different services, primarily applications that enable the user to share resources. The purpose of IoT is to support networking of different things and objects from everyday life as well as communication among them via the Internet, without human interaction, with the aim to improve conditions and ways we live. Technological advances and development of sensors, actuators, data warehouses and networking capabilities give us a glimpse into what the future of Internet of Things could look like.This paper presents and discusses the use of temperature and humidity sensors and entire set up of Raspberry Pi computer, from installation of the operating system to coding and data gathering.

1. UVOD

Broj korisnika Interneta se kontinuirano povećava te je život bez njega postao nezamisliv. Internet je, između ostaloga, omogućio učinkovitiji prijenos podataka, povezivanje ljudi, a u posljednjih nekoliko godina i uređaja. Koncept Interneta stvari (eng. Internet of Things, IoT) koji se odnosi na interakciju umreženih uređaja i senzora postao je dio naše svakodnevnice. Osim toga, isti se zbog svojih karakteristika i specifičnosti smatra novom razvojnom epohom Interneta. Ono što je bitno napomenuti je da se Internet stvari odnosi na povezanost ljudi, uređaja kao što su uklopljeni sustavi i senzora koji koriste Internet u svrhu međusobne komunikacije, prikupljanja i razmjene podataka. Spomenute je uklopljene sustave moguće isprogramirati da reagiraju na našu prisutnost, pokret, glasovne naredbe, pokret oka pa čak i na autonomna fiziološka ponašanja kao što su otkucaiji srca. Dostignuća u području umjetne inteligencije i strojnog učenja rezultirala su time da uređaji anticipiraju, reagiraju, odgovaraju i poboljšavaju svijet koji ih okružuje. Tako će nam primjerice hladnjak poslati poruku sa popisom namirnica koje nedostaju kako bismo ih kupili prilikom povratka kući. Osim toga, putem svog pametnog telefona možemo upravljati klimatizacijom kod kuće, video nadzorom nadgledati prostor sa udaljene lokacije i slično.

Postoje dva ključna čimbenika odgovorna za uspjeh IoT-a. Prvi su otvoreni API-ji (eng. Application Programming Interface) i standardni protokoli na različitim razinama otvorenih sustava, a drugi je ekosistem koji će definirati otvorene API-je za programere i nuditi odgovarajuće kanale za isporuku novih aplikacija. Takva API sučelja imaju veliku važnost na razini modula za analizu i obradu podataka jer programerima omogućuju utjecaj na osnovnu komunikacijsku infrastrukturu te korištenje i kombiniranje podataka koje generiraju različiti IoT uređaji, a sve sa ciljem stvaranja novih, dodanih, vrijednosti [1]. U ovom će radu na praktičnom primjeru biti opisano programiranje uređaja za Internet stvari.

2. RASPBERRY PI

Raspberry Pi (skr. RPi) prikazan na slici 1 je računalo razvijeno u Cambridgeshireu u Velikoj Britaniji od strane Raspberry Pi Foundation. Isti je proizveden s namjerom promicanja računalnih znanosti u školama te poticanja mladih ljudi na bavljenje tehnologijom [2]. Raspberry Pi ne dolazi s predinstaliranim operativnim sustavom već ga je primjenom odgovarajućeg programa potrebno instalirati na SD karticu. Minimalna veličina SD kartice je 2GB, ali se preporuča veličina od 4GB ili više.

Premda se za kontrolu resursa preporuča Raspbian operativni sustav, Raspberry Pi najčešće koristi Linux koji se temelji na Debian 7 „Eheezy“ distribuciji dizajniranoj za Raspberry Pi. Raspbian je vrlo popularan zbog njegovog jednostavnog

88 CASE2018

načina održavanja te brzine i lakoće korištenja. Kao glavna prednost ovog operativnog sustava ističe se mogućnost odabira obrazovnih materijala ili projekata koji su sadržani unutar distribucije. Spomenuto korisnicima olakšava učenje programiranja uređaja te nudi mogućnost korištenja mnogih dodataka za hardver.

2.1 Sklopovlje

U ovom će potpoglavlju biti opisane hardverske komponente računala Raspberry Pi [7].

Slika 1. Gornja strana računala Rpi [7]

A: Procesor

Raspberry Pi 2 koristi ARM tip procesora kakav se može naći u uređajima kao što su iPhone 3G i Kindle 2 te su shodno tome njegove mogućnosti usporedive sa navedenim uređajima. ARM je linija 32-bitnih mikroprocesora koje razvija tvrtka ARM Holdings. ARM procesori koriste skraćeni skup instrukcija (eng. Reduced Instructions Set, RISC) što im omogućava solidne performanse u malom pakiranju i malu potrošnju energije. ARM čipovi općenito se rade u velikom broju arhitektura i s različitim jezgrama prilagođenim za pružanje različitih mogućnosti u različitim cjenovnim rangovima. ARM Cortex-A7 čip je četverojezgreni, 32-bitni sustav na čipu, brzine 900 MHz, temeljen na ARMv7-A arhitekturi. Manji je, jednostavniji i energetski učinkovitiji u odnosu na prethodnike [3]. Uz to, Raspberry Pi 2 dolazi s 1 GB radne memorije.

B: GPIO (eng. General-Purpose Input/Output)

Model Raspberry Pi 2 ima 2 × 20 izvoda, što je standard još od modela B+. Ovi izvodi su fizičko sučelje između Raspberry-a i okoline odnosno omogućuju Raspberry-ju interakciju s fizičkim svijetom kroz upravljanje ulazima i izlazima. U slučaju ulaza, moguće ih je promatrati kao prekidače koji se mogu uključivati i isključivati odnosno koje Raspberry može uključivati ili isključivati, ako je riječ o izlazu. Ulazi ne moraju uvijek dolaziti od fizičkog prekidača, nego se mogu prikupljati sa senzora ili signala koji potječe s drugog računala. Izlaz također može biti bilo što, od paljenja LED diode do slanja signala ili podataka drugom uređaju. U slučaju da je Raspberry spojen na mrežu, moguće je sa udaljene lokacije upravljati uređajima koji su priključeni na njega te dobivati podatke s tih uređaja. Od ukupno 40 izvoda GPIO-a, njih 26 su izvodi za ulaz i izlaz, dok ostali izvodi daju energiju i uzemljenje. U nastavku će biti objašnjeno kako koristiti izvode GPIO-a za očitavanje podataka sa senzora.

C: Kombinirani analogni video i audio izlaz

Na modelu Raspberry Pi 2, analogni audio i video izlazi su dostupni na standardnom 3.5 mm 4-polnom konektoru.

D: Vanjski USB priključci

Raspberry Pi 2 ima četiri USB 2.0 priključka, za razliku od modela koji su prethodili modelu B+, koji su imali samo dva. Isti također pruža bolju podršku za priključivanje dodatnih perifernih uređaja bez značajnih smetnji u radu računala te zaštitu od prevelikog napona struje. U slučaju povećane potrebe perifernog uređaja za energijom koju računalo ne može zadovoljiti, može se koristiti vanjski izvor energije.

E: Ethernet ulaz

Model Raspberry Pi 2 ima, kao i modeli B i B+, standardni RJ45 Ethernet ulaz. Također, moguće je i bežično povezivanje na Internet pomoću USB priključka.

F: Priključak za serijsko sučelje kamere (eng. Camera Serial Interface, skr. CSI)

Pomoću ovog izlaza moguće je izravno povezati kameru na računalo.

G: HDMI (eng. High-Definition Multimedia Interface) izlaz

CASE2018 89

HDMI konektor omogućava digitalni video i audio izlaz. Računalo podržava četrnaest različitih video rezolucija, a HDMI signal je, pomoću vanjskih adaptera, moguće pretvoriti u DVI (koji koriste mnogi monitori), kompozitni signal (analogni video signal kojeg obično prenosi žuti RCA konektor) ili SCART (europski standard za povezivanje audio-vizualne opreme).

H: Ulaz za napajanje

Na računalima Raspberry Pi nema prekidača za uključivanje, nego se za napajanje koristi mikro USB konektor. On ne predstavlja još jedan USB ulaz, nego služi samo za napajanje. Ova vrsta konektora se koristi jer su jeftini i široko dostupni.

I: Priključak za serijsko sučelje zaslona (eng. Display Serial Interface, skr. DSI)

Na ovaj konektor se može priključiti ravni trakasti kabel koji se može koristiti za komunikaciju s LCD ili OLED zaslonima.

J: LED diode za prikaz stanja

Pet LED indikatorskih dioda pružaju vizualne podatke o stanju. LED diode vezane uz Ethernet mrežu nalaze se na samom Ethernet ulazu.

3. DHT22/AM2302 SENZOR

DHT22/AM2302 je digitalni senzor za mjerenje temperature i vlažnosti. Riječ je o trenutno najjeftinijem senzoru dostupnom na tržištu koji pruža kalibrirane digitalne izlaze za temperaturu i relativnu vlažnost zraka. AM2302 je žičana verzija spomenutog senzora u praktičnom plastičnom kućištu. Može mjeriti temperaturu do 80° C, a vlažnost zraka u opsegu od 0-100% što ga čini idealnim za upotrebu u interijeru.

Kako bih ga osposobili, potrebno je ispravno spojiti žice senzora s pinovima Raspberry Pi-ja. To je izvedivo preko takozvane ekperimentalne pločice (eng. Breadboard) iz razloga da se realizira ispravan strujni krug i omogući prikupljanje podataka sa senzora. Pravilno spojene žice sa pinovima Raspberry Pi-ja prikazane su na slici 2.

Slika 2. Prikaz spojenih žica senzora s pinovima RPi-ja [4]

3.1 Čitanje podataka

Najpopularniji Git repozitorij sa kojeg programeri preuzimaju kodove i projekte otvorenog koda napisane u različitim programskim jezicima je GitHub. Git repozitoriji su popriično zastupljeni i u Raspberry Pi projektima što će biti ilustrirano na sljedećem primjeru u kojem je korišten Git razvijen od strane hardverske kompanije otvorenog koda pod nazivom Adafruit.

Sljedeće naredbe Raspbian OS-a obuhvaćaju preuzimanje Python koda sa GitHub-a te preuzimanje i instaliranje biblioteke Adafruit_Python_DHT [7].

sudo apt-get install git

cd~

git clone https://github.com/adafruit/Adafruit_Python_DHT.git

cd Adafruit_Python_DHT

sudo apt-get update

sudo apt-get install build-essential python-dev

sudo python setup.py install

cd examples

sudo ./AdafruitDHT.py 2302 4

Možemo primjetiti da se u naredbi sudo ./AdafruitDHT.py 2302 4 nalaze još dva parametra od kojih je 2302 verzija senzora koji se koristi, a 4 predstavnja GPIO pin koji se koristi za dohvaćanje podataka sa senzora. Uspješno testiran kod bi trebao ispisati temperaturu i vlažnost u terminalnom prozoru Raspbian OS-a kao što je prikazano na slici 3.

90 CASE2018

Slika 3. Prikaz uspješno testiranog koda [7]

Na slici 4 je prikazano testiranje biblioteke mijenjanjem direktorija u mapu examples i pokretanjem koda u Python datoteci AdafruitDHT.py.

Slika 4. AdafruitDHT.py [7]

4. THINGSPEAK PLATFORMA

ThingSpeak je jedna od platformi za Internet stvari koja pomaže u prikupljanju podataka sa senzora te u pohrani istih na cloud. Spomenuta platforma također pomaže u razvoju aplikacija za Internet stvari, a uključuje i aplikacije namijenjene analizi i vizualizaciji prikupljenih podataka [5]. Glavni elementi ThingSpeak platforme su kanali koji sadrže polja podataka te lokacijska i statusna polja.

ThingSpeak API je također dostupan na GitHub-u i uključuje kompletni ThingSpeak API za procesiranje HTTP zahtjeva, pohranjivanje numeričkih i alfanumeričkih podataka, obradu numeričkih podataka, praćenje lokacije i ažuriranje statusa [5].

Slika 5. Generiranje ThingSpeak API ključa [7]

Prvi korak nakon registracije na platformi ThingSpeak je kreiranje kanala za podatke te generiranje API ključa (prikazano na slici 5) koji je neophodan za ažuriranje podataka. API ključ se zatim uključuje u Python kod te će se pokretanjem koda

CASE2018 91

podaci sa senzora ažurirati na ThingSpeak kanalu. Na GitHub-u već postoji primjer korištenja ThingSpeak kanala pomoću Python koda za temperatu procesora (CPU) u koji je samo potrebno dodati API ključ našeg kanala. Kompletan kod Python skripte CPU_Python.py prikazan je na slici 6.

Slika 6. CPU_Python.py [7]

Nakon kompajliranja koda te uspostavljanja veze sa ThingSpeak serverom putem API ključa, podaci o temperaturi procesora su uspješno preneseni. Poslije provedenog testiranja nad temperaturom procesora, potrebno je podatke o temperaturi i vlažnosti zraka prenijeti na ThingSpeak kanal. Osim toga, potrebno je prilagoditi i uskladiti biblioteku Adafruit_Python_DHT sa već korištenim kodom za uspostavljanje veze sa ThingSpeak kanalom kako bi podaci sa senzora bili ažurirani. Za uspostavljanje veze u kodu prikazanom na slici 7 pomoću biblioteke Adafruit_Python_DHT, u odgovarajuće varijable bilo je potrebno spremiti podatke senzora i prenijeti ih kao argumente fukcije za ažuriranje podataka. Podaci o temperaturi i vlažnosti su spremljeni u polja 3 i 4. Isti su zatim stavljeni u beskonačnu petlju, koja će čitati podatke sve dok je RPi uključen ili dok se čitanje podataka ručno ne prekine.

Slika 7. Prikaz koda za ažuriranje podataka temperature i vlažnosti na ThingSpeak putem API ključa [7]

U polje 2 na ThingSpeak kanalu je također dodan i Google Maps dok Soba1 sadrži grafički prikaz temperature i vlažnosti zraka kao što je prikazano na slici 8.

92 CASE2018

Slika 8. Konačni prikaz ThingSpeak kanala sa ažuriranim podacima [7]

5. BLYNK PLATFORMA

Blynk je Android platforma isključivo dizajnirana za Internet stvari. Osim što može prikazivati podatke senzora te ih pohranjivati i vizualizirati, ista također omogućuje kontroliranje hardvera na daljinu.

Ono po čemu se Blynk još ističe su virtualni pinovi koji mogu slati podatke iz mikrokontrolera u Blynk App i primati ih nazad. Sve što se spoji na hardver biti će u mogućnosti komunicirati s Blynk-om. Virtualni pinovi imaju mogućnost slanja podataka sa aplikacije, njihove obrade u mikrokontroleru te njihovog slanja natrag na pametni telefon. Potrebno je naglasiti kako je Auth Token jedini način da se pametni telefon poveže na RPi. Auth Token ima istu ulogu kao API ključ, a definira se kao jedinstveni identifikator koji je potreban za povezivanje hardvera sa pametnim telefonom [6]. Auth Token se kreira pritiskom na gumbom Create koji je prikazan na slici 9.

Slika 9. Kreiranje novog projekta u Blynk Android aplikaciji i generiranje Auth Tokena [7]

Da bih se omogućilo normalno komuniciranje sa virtualnim pinovima i općenito sa Blynk-om, uređaji bi trebali podržavati JavaScript. Iz tog je razloga na RPi potrebno instalirati Node.js. Riječ je okruženju namijenjenom izvršavanju JavaScript programskog koda na strani poslužitelja. Prikupljanje podataka sa senzora vrši se pomoću NPM upravitelja Node.js paketa dok se instalacija provodi izvođenjem sljedećih naredbi [7]:

curl - sLS https://apt.adafruit.com/add | sudo bash

sudo apt-get install node

git clone https://github.com/vshymanskyy/blynk-library-js

cd blynk-library-js

sudo apt-get update && sudo apt-get upgrade

sudo apt-get install build-essential

sudo npm install -g npm

CASE2018 93

sudo npm install -g onoff

sudo npm install -g blynk-library

Pokretanjem skripte blynk.js i prosljeđivanjem Auth Tokena kao argumenta naredbe prikazane na slici 10, uspješno je provedeno spajanje na Blynk cloud.

Slika 10. Povezivanje RPi-a s cloudom Blynk-a [7]

Obzirom da je RPi uspješno spojen na Blynk, mogu se preuzeti i instalirati odgovarajuće biblioteke za čitanje podataka sa senzora.

wget http://www.airspayce.com/mikem/bcm2835/bcm2835-1.46.tar.gz

tar zxvf bcm2835-1.46.tar.gz

cd bcm2835-1.46

./configure

make

sudo make check

sudo make install

sudo npm install -g node-dht-sensor

Instalacija nije uobičajena jer se biblioteka bcm2835 mora dodatno raspakirati, što malo odužuje proces. Kako bi prikaz podataka bio omogućen, potrebno je u Blynk App-u povući i ispustiti (eng. drag and drop) widgete te im odrediti virtualne pinove. Kao što je prikazano na slici 11, nakon uspješno dodanih widgeta i virtualnih pinova te prilagodbe skripte za prosljeđivanje podataka, podaci će biti spremni za ažuriranje. Odabrani su pinovi V3,V4 i V7 te će se preko njih vršiti prijenos podataka pomoću Auth Tokena.

Slika 11. Primjer dodavanja Gauge widgeta Temperatura na virtualni pin 3 [7]

Dijelovi koda koji su se morali prilagoditi su varijabla AUTH u koju se mora unijeti odgovarajući AuthToken, varijable sensorType i sensorPin u kojima su vrijednosti postavljane na 22 i 4, respektivno, i funkcija blynk.virtualWrite kojoj je prvi argument broj virtualnog pina, a drugi argument željeni podatak sa senzora (temperatura ili vlažnost zraka). Navedeno je prikazano na slici 12.

Nakon izvršene prilagodbe koda, moguće je započeti sa ažuriranjem podataka na Blynk aplikaciji pokretanjem blynk_s.js odnosno izvršenjem sljedeće naredbe [7]:

sudo NODE_PATH=/usr/local/lib/node_modules node ./blynk_s.js

94 CASE2018

Slika 12. Prikaz koda za ažuriranje podataka temperature i vlažnosti zraka na Blynk-u putem AuthTokena [7]

Izvršenjem naredbe i pokretanjem skripte u aplikaciji, temperatura i vlažnost zraka se uspješno ažuriraju te grafički prikazuju kao što je ilustrirano na slici 13.

Slika 13. Konačni izgled aplikacije Blynk na Android OS-u [7]

6. ZAKLJUČAK

Internet stvari koji povezuje uređaje i fizičke objekte iz okoline u globalnu mrežu temeljenu na protokolu IP čini infrastrukturu za razvoj novih mobilnih i Web usluga. Brzi porast broja uređaja sa sposobnostima komunikacije i aktivacije približava viziju Interneta stvari gdje su funkcije osjeta i djelovanja neprimjetno uklopljene u pozadinu i nove mogućnosti su ostvarene kroz pristup novim bogatim izvorima informacije. Evolucija u digitalno društvo i nastanak digitalne ekonomije pod utjecajem jačanja i širenja društvenih mreža danas služi kao temelj na kojemu se može razvijati koncept Interneta stvari. Tehnološki napredak te razvoj senzora, aktuatora, skladišta podataka i mrežnih sposobnosti pruža nam uvid u neke od mogućih scenarija budućeg razvoja i primjene Interneta stvari.

Postojeći projekti Interneta stvari su vrlo raznoliki i primjenu pronalaze u svim sferama ljudskog djelovanja, od obrazovanja i medicina, preko prometa, domaćinstva i poljoprivreda, pa sve do trgovine i zabave. Većina tih projekata ima zajednički cilj, a to je olakšati čovjeku život. Iz tog razloga sve veći broj proizvođača tehnološke opreme teži tome da njihovi proizvodi imaju implementiranu mogućnost spajanja na bežičnu mrežu te korištenja u konceptu tehnologija Interneta stvari. Shodno tome možemo očekivati da će se skoroj budućnosti prefiks „pametno“ pojavljivati na sve većem broju različitih proizvoda i uređaja.

Internet stvari nekome može djelovati zastrašujuće ili prijeteće jer nas približava automatiziranom, robotskom svijetu. Sve je veći broj radnih mjesta koja su djelomično ili u potpunosti automatizirana, a dom je samo jedan od sljedećih koraka u tom procesu. Međutim, to ne znači da će stvari razmišljati ili donositi odluke umjesto nas već nam Internet stvari

CASE2018 95

omogućuje da svoju energiju i vrijeme usredotočimo na puno važnije stvari od paljenja svjetla ili promjene temperature na termostatu.

Literatura:

1 Smith, I. G.: Internet of Things 2012 New Horizons, Halifax, UK., 2012.

2 Raspberry Pi, About. https://www.raspberrypi.org/about/ (datum pristupa 15.9.2016.)

3 ARM: http://en.wikipedia.org/wiki/ARM_Cortex-A7 (datum pristupa 15.9.2016.).

4 Adafruit Industries; https://learn.adafruit.com/dht-humidity-sensing-on-raspberry-pi-with-gdocs logging/wiring Adafruit Industries (datum pristupa 18.9.2016.)

5 Mathworks: https://www.mathworks.com/help/thingspeak/ (datum pristupa 16.9.2016.)

6 Blynk: http://docs.blynk.cc/#getting-started-getting-started-with-the-blynk-app-4-auth-(datum pristupa 17.9.2016.)

7 Hager, M.: Programiranje uređaja za Internet stvari, završni rad. Odjel za informacijsko – komunikacijske tehnologije, Sveučilište Jurja Dobrile u Puli, Pula, 2016.

Podaci o autorima:

Mislav Hager, univ. bacc. inf. e-mail: mhager@unipu.hr Mislav Hager je 2016. godine stekao akademski naziv sveučilišnog prvostupnika informatike na Odjelu za informacijsko-komunikacijske tehnologije (danas Fakultet informatike) Sveučilišta Jurja Dobrile u Puli. Na istom trenutno pohađa drugu godinu diplomskog studija informatike. Glavna područja interesa su mu razvoj mobilnih i Web aplikacija u kontekstu Interneta stvari. U slobodno vrijeme bavi se programiranjem hardvera i proučavanjem robotike. doc. dr. sc. Tihomir Orehovački e-mail: tihomir.orehovacki@unipu.hr Tihomir Orehovački diplomirao je i doktorirao 2005. i 2013. godine, respektivno, na Fakultetu organizacije i informatike Sveučilišta u Zagrebu. Pedagoško-psihološko-didaktičko-metodičku naobrazbu stekao je tijekom akademske godine 2005./2006. na Visokoj učiteljskoj školi u Čakovcu (danas Učiteljski fakultet Sveučilišta u Zagrebu, Odsjek u Čakovcu). Od 1. listopada 2015. godine zaposlen je na radnom mjestu docenta na Odjelu za informacijsko-komunikacijske tehnologije (danas Fakultet informatike) Sveučilišta Jurja Dobrile u Puli gdje je nositelj kolegija vezanih uz programiranje. Član je Povjerenstva za akademsko priznavanje inozemnih visokoškolskih kvalifikacija i razdoblja studija te Odbora za znanstveni i umjetnički rad Sveučilišta Jurja Dobile u Puli. Autor je 75 znanstvenih radova objavljenih u zbornicima međunarodnih konferencija, časopisima i knjigama te 10 stručnih radova objavljenih u zbornicima domaćih skupova. Znanstveno se i stručno usavršavao na brojnim radionicama i institucijama u zemlji i inozemstvu. Bio je voditelj projekta financiranog sredstvima HRZZ. Osim toga, sudjelovao je u istraživačkim aktivnostima projekata financiranih sredstvima Europske Unije, Zaklade Adris, Ministarstva znanosti i obrazovanja te Sveučilišta u Zagrebu. Bio je suorganizator i predavač na 2 radionice vezane uz upravljanje međunarodnim projektima i 7 radionica vezanih uz primjenu društvenih Web aplikacija u obrazovanju. Aktivni je recenzent za 15 međunarodnih znanstvenih časopisa, 2 znanstvene knjige i 11 međunarodnih znanstvenih konferencija. Vršio je dužnost člana Programskog odbora, voditelja tematskih cjelina i sekcija sljedećih međunarodnih znanstvenih konferencija: International Conference on Information Systems Development (ISD), ACM International Conference on Intelligent User Interfaces (IUI), International Conference on the Quality of Information and Communications Technology (QUATIC) - Track on Quality in Web Engineering te International Conference on Information Technology (ICIT). Bio je član Organizacijskog odbora, urednik knjige sažetaka i tehnički urednik zbornika radova međunarodne znanstvene konferencije ISD 2014. Član je sljedećih međunarodnih strukovnih udruženja: Association for Computing Machinery, European University Information Systems E-Learning Task Force, Institute of Electrical and Electronics Engineers i International Society for Web Engineering. Za svoj znanstveni, nastavni i stručni rad primio je nekoliko međunarodnih i domaćih nagrada i priznanja. Dosad je pod njegovim mentorstvom 49 studenata obranilo završne i diplomske radove. Fakultet informatike u Puli, Sveučilište Jurja Dobrile u Puli Zagrebačka 30, 52100 Pula

96 CASE2018

CASE2018 97

IZRADA INDIE IGRE U UNITY 3D OKRUŽENJU I NJENO PLASIRANJE NA GOOGLE PLAY TRGOVINU

Edi Crnković, univ. bacc. inf., doc. dr. sc. Tihomir Orehovački

SAŽETAK

Industrija video igara danas predstavlja najrašireniju i najprofitabilniju granu zabavne industrije, više nego filmska i glazbena industrija zajedno. Razvojem mobilnih uređaja, igre su postale dostupnije igračima jer ih isti mogu preuzeti sa online servisa kao što su Google Play i Apple Store. Osim toga, spomenuti servisi omogućuju svojim korisnicima da igre koje su sami izradili učine dostupnima za preuzimanje i igranje svima koji su za to zainteresirani. Takav pristup uvelike je pridonio popularnosti indie pristupa razvoju igara koji svakom pojedincu omogućuje da uz minimalna ulaganja ostvari profit. U ovom je radu opisan cjelokupni postupak razvoja indie igre, od osmišljavanja ideje i razvoja igre u okruženju Unity 3D pa sve do oblikovanja poslovnog plana i plasiranja igre na Google Play trgovinu.

ABSTRACT

The video game industry is today the most widespread and the most profitable branch of entertainment industry, more than the film and music industry together. With a development of mobile devices, games became more available to players because they can download them from online services such as Google Play and Apple Store. In addition, these services allow their users to make games they made available for download and play to anyone who is interested. This approach has greatly contributed to the popularity of indie game development approach that allows every individual to make a profit with minimal investment. This paper describes the overall process of developing indie games, from designing ideas and game development in Unity 3D environment, to business plan design and game placement on the Google Play Store.

1. UVOD

Pojam igre se često povezuje sa osjećajima zabave, užitka i estetike [1, 2] koju percipiraju svi oni koji su u istu uključeni. U dvadesetom su stoljeću igre dobile novu, digitalnu dimenziju, u kojoj uzrok spomenutih hedonističkih dimenzija kvalitete nije više nužno interakcija sa dva ili više drugih igrača, već i interakcija sa strojem. U praksi postoje dva temeljna pristupa razvoju igara: neovisni ili indie i visokobudžetni ili AAA.

Premda je svijet neovisnih (indie, skraćeno od eng. independent) video igara svoj procvat doživio u drugoj polovici 2000-ih, njihov je koncept daleko od novog. Naime, upravo su indie razvojni programeri zaslužni za to što su prve računalne igre ugledale svijetlo dana iz razloga što u to vrijeme industrija igara nije postojala. Indie naslove u pravilu razvijaju pojedinci ili mali timovi koji rijetko imaju financijsku potporu izdavača. Mnogi indie programeri se zapravo oslanjaju na grupno financiranje (eng. crowdfunding) ili osobne investicije kako bi pokrili troškove razvoja. Budući da nemaju veliki budžet, indie igre nisu grafički ni programski zahtjevne. Osim toga, mnoge od njih imaju stilizirane umjetničke dizajne. Indie igre se smatraju dostupnijima široj publici zbog dva razloga. Prvo, mnogo su jeftinije od AAA igara. Naime, indie naslovi rijetko koštaju više od dvadeset dolara. Drugo, indie igre su po prirodi jednostavne što znači da u njima može uživati široki spektar igrača neovisno o njihovim vještinama ili iskustvu u igranju. Primjeri indie igara su Braid [3] koja je prikazana na slici 1 i World of Goo [4].

Akronim AAA označava visokokvalitetne igre u koje je uloženo puno vremena (eng. A lot of time), puno resursa (eng. A lot of resources) i puno novaca (eng. A lot of money). Nasuprot indie naslovima, AAA igre razvijaju veliki studiji čiji su timovi sačinjeni od stotine ili čak tisuće ljudi. Osim toga, AAA projekte podupire izdavač (kao što je primjerice Activision) koji razvojnim timovima osigurava velike proračune. Zbog navedenog su AAA igre najčešće opsežnije, kompleksnije, detaljnije te imaju realističniju grafiku od indie igara. Zbog visokih ulaganja, cijena AAA igara je na tržištu značajno viša od indie igara te se kreće u rasponu od 40 do 60 USD. Primjeri AAA igara su Grand Theft Auto V [5] koja je prikazana na slici 2 i Where's My Water [6].

98 CASE2018

Slika 15. Braid [3]

Slika 2. Grand Theft Auto V [5]

2. UNITY

Aplikacija koja je opisana u radu ubraja se u kategoriju mobilnih indie video igara te su u ovom radu obrađeni osnovni koncepti potrebni za izradu 2D Android igre u Unity 3D razvojnom okruženju. Unity 3D jedan je od vodećih i trenutno najpopularnijih game engine-a na svijetu koji se koristi pri razvoju igara za PC, konzole, mobilne uređaje i Web. Njegova inicijalna verzija objavljena je 2005. godine te je bio podržan samo na OS X operativnom sustavu. Sam početak Unity-a usko je vezan uz tvrtku Unity Technologies koja je osnovana zbog razvitka samog engine-a. Fokus tvrtke je "demokratizirati razvitak igara" te ga učiniti pristupačnim ljudima diljem svijeta. Četiri godine kasnije, Unity Technologies je lansirao besplatnu verziju engine-a, nedugo nakon što je zabilježen značajan porast registriranih korisnika. Danas ta brojka prelazi milijun registriranih korisnika [7].

Unity dolazi u tri inačice:

Osobna inačica (eng. personal edition) Unity plus Profesionalna inačica (eng. professional edition)

Osnovni koncepti Unity3D engine-a su:

Aktiva (engl. assets) Scena Objekt igre (engl. GameObject) Komponenta Skripte Predlošci (engl. prefab)

CASE2018 99

Aktive su modeli, teksture, zvuk, video i animacije, a koriste ih engine za iscrtavanje (engl. Render engine), engine za zvuk i video (engl. Sound/video engine) te engine za animaciju (engl. Animation engine).

Scene sadrže objekte igre, a koriste se za izradu razina (eng. levels) igre ili izbornika. Pri tome svaka scena predstavlja posebnu razinu igre ili izbornik. Unutar scene gradimo igru postavljajući naše objekte. Kreiranjem igre u više scena postiže se mogućnost raspodjele učitavanja dijelova igre, te mogućnost testiranja određenih dijelova igre zasebno.

Objekti igre su spremnici komponenti u Unity-u poznatiji pod izrazom GameObject. Svaki objekt sadrži barem jednu komponentu. Riječ je o Transform komponenti koja engine-u daje informaciju o poziciji objekta u 3D prostoru koja je opisana pomoću X, Y i Z koordinate te njegovu veličinu i rotaciju.

Komponente su funkcionalni dijelovi svakog objekta igre. One dolaze u različitim oblicima. Mogu utjecati na ponašanje objekta koji ih sadrži, definirati pojavu i iscrtavanje ili utjecati na neke druge funkcije objekta unutar igre.

Za kreiranje skripti Unity podržava programske jezike JavaScript for Unity, C# i Boo. Skripte su važan i ključan koncept svakog razvoja igre i unutar Unity3D engine-a se smatraju komponentama. Pomoću skripti možemo upravljati objektima igre na način da unutar skripte napišemo željeno ponašanje te tu skriptu dodijelimo objektu igre.

Prefab je tip aktive koji je moguće koristiti u više scena te neograničeno mnogo puta unutar jedne scene.

3. PROCES IZRADE IGRE

Izrada igre je kompleksan projekt koji se sastoji od sljedećih temeljnih procesa:

oblikovanje ideje, razvoj igre, plasiranje i prodaja igre.

Kao što je prikazano na slici 3, spomenute je procese moguće dopuniti dodatnim logički i terminski povezanim procesima.

Slika 3. Proces izrade igre [8]

Između svakog od spomenutih temeljnih procesa se javljaju svojevrsni problemi. Nije potrebno puno znanja kako bi se oblikovala ideja igre, no problem koji se javlja nakon što imamo oblikovanu ideju su znanja i vještine potrebni za realizaciju ideje. To je prvi glavni problem sa kojim se suočavaju pojedinci koji se upuštaju u izradu igre. Drugi glavni problem nastaje nakon što se ideja realizira, a on se odnosi na plasiranje i prodaju igre. Načini na koji se može doskočiti spomenutim problemima će biti opisani u nastavku ovog poglavlja.

3.1 Oblikovanje ideje

Prvi korak u ovom procesu je validacija ideje na tržištu. Kada se oblikuje ideja za neku novu igru, potrebno je provjeriti da li takvih igara već ima. Ako postoje, koliko su uspješne? Ako su uspješne, možemo li postići istu ili veću razinu kvalitete od naše konkurencije? Ako takve igre ne postoje, što je tome razlog? Da li se nitko nije sjetio toga ili nema interesa za takav tip igre? Tek će odgovori na ova pitanja ukazati na to da li su nam ideje dobre ili loše.

Drugi korak je razrada ideje gdje inicijalnu skicu ideje nadopunjujemo sve dok cijela igra nije dekomponirana do najsitnijih detalja. U ovom je koraku vrlo važno dijeliti ideju sa što više ljudi, posebice sa onima koji predstavljaju uzorak ciljanih igrača. Oblikovanje ideje je kontinuirani proces sačinjen od stalnog planiranja, dorađivanja i komuniciranja, ali i napuštanja ideje te prelaska na novu ako postojeća jednostavno ne funkcionira onako kako smo zamislili.

100 CASE2018

Za potrebe ovog rada razvijena je igra Candy Freak [9] prikazana na slici 4 čija je ideja da igrač glavnog lika (bijelo čudovište) dovede sigurno kući kako bi isti mogao otključati sljedeću razinu. Pritom glavni lik sakuplja bombone koji mu pomažu pri stvaranju objekata pomoću kojih rješava prepreke. Svaka razina ima određene objekte koji otežavaju dolazak do cilja odnosno do kuće. Kako igrač napreduje prema višim razinama, prepreke su teže, pa samim time igra od igrača traži više koncentracije i razmišljanja.

Slika 4. Primjer razine u igri Candy Freak [9]

3.2 Razvoj igre

Proces razvoja igre moguće je raščlaniti na sljedećih nekoliko aktivnosti:

Prikupljanje i izrada 2D modela – modeliraju se svi objekti koji će biti potrebni za izradu razina odnosno mape na kojoj će se igra odvijati.

Oživljavanje modela – programiraju se objekti i stavljaju u život. Izrada mape – izrađuje se okruženje u kojem će se igra odvijati. Izrada sučelja – dizajnira se grafičko korisničko sučelje (eng. graphical user interface, GUI). Podešavanje grafičkih svojstava – dodaju se efekti kako bi igra izgledala realnije i ljepše Testiranje i ispravljanje pogrešaka.

3.2.1 Prikupljanje i izrada 2D modela

Vrlo važnu ulogu u popularnosti igre imaju smiješni, nezaboravni likovi jer kod igrača stvaraju želju za ponovnim i učestalim igranjem. Iz navedenog proizlazi kako je dizajn likova presudan za komercijalni uspjeh igre. Likovi bi trebali biti privlačni, realistični i zabavni kako bi se igrači sa njima mogli emocionalno povezati i poistovjetiti. Osim likova, važan je dizajn i ostalih objekata koji se javljaju u igri. Prije nego što se započne sa modeliranjem objekata, potrebno je donijeti odluku o stilu igre. Primjer dobre prakse nalaže odabir jednog stila i njegovo dosljedno korištenje u igri. Neki od 2D stilova su sljedeći [10]:

Pikselna umjetnost (eng. pixel art). Premda je izvorno stvoren zbog ograničenja starih igraćih konzola, mnogi ga moderni indie dizajneri koriste kao vizualni stil.

Ručno crtanje (eng. cel shading) je vrsta ne-fotorealističnog prikazivanja dizajnirane 3D grafike koje izgledaju ravno. Realizam (eng. realism) je stil koji se koristi u recentnim Nintendo igrama. Glavno obilježje su mu vrlo detaljne

teksture i realno prikazane karikature. Ravna estetika (eng. flat) ne koristi nikakve 3D elemente. Svaki objekt izgleda kao da je izrezan iz papira. Geometrijska estetika (eng. geometric) koristi primitivne oblike (kvadrate, pravokutnike, linije, itd.) često u neonskim

bojama na crnoj podlozi.

3.2.2 Izrada mape

Izrada razina je korak razvoja igre koji oduzima najviše vremena jer razine moraju biti pomno planirane te ih je nakon izrade potrebno testirati kako bi bili sigurni da se svaka razina može prijeći. Posebnu je pozornost potrebno posvetiti uklanjanju potencijalnih prečaca primjenom kojih bi igrač mogao alternativno doći do cilja. Razine se moraju razlikovati pri čemu svaka sljedeća treba biti izazovnija od prethodne te igraču predstaviti nove prepreke ili stare prepreke koje igrač mora riješiti na drugačiji način da bi došao do cilja.

3.2.3 Oživljavanje modela

Da bi se igrač mogao kretati i reagirati na pritisak gumba, moramo napraviti skriptu koja će njime upravljati. Unity sadrži ugrađen IDE

§§ za kreiranje skripti koji se naziva Monodevelop, no skripte se mogu kreirati u bilo kojem razvojnom

okruženju koje podržava jezik u kojem se one kreiraju. Najjednostavniji način je korištenje samog Monodevelop alata jer

§§

IDE - Integrirano razvojno okruženje

CASE2018 101

je on već integriran u Unit, a time i njemu prilagođen. U ovom radu je potrebe izrade skripti korišten JavaScript programski jezik. Postoje dvije osnovne funkcije koje sadrži skripta:

Start koji se koristi za inicijalizaciju varijabli prilikom stvaranja objekta kojem je skripta pridružena. Update koji sadrži svu logiku koja se izvršava u stvarnom vremenu. Poziva se jednom pri svakom iscrtavanju (engl.

per frame).

Unutar skripti može se pristupiti svim elementima objekata igre te po potrebi mijenjati ili upravljati njihovim sadržajem. Važno je napomenuti da su skripte igračevo „sučelje“ prema igri jer su odgovorne za upravljanje ponašanjem objekata ovisno o ulazu (eng. input) putem dodira na ekran.

Sljedeći programski kod prikazuje skriptu pomoću koje je riješen problem igri.

function Update () {

if (Input.GetMouseButtonDown(0) && rayHit.collider.tag == "stup") {

stup1 = true;

kutija1 = false;

daska1 = false;

objectStup.renderer.material.mainTexture = textureStup1;

objectKutija.renderer.material.mainTexture =textureKutija0;

objectDaska.renderer.material.mainTexture = textureDaska0;

AudioSource.PlayClipAtPoint(menuSound, transform.position);

}

if (Input.GetMouseButtonDown(0)&& stup1 == true && score >=1){

mousePoint.z = 2;

Instantiate(stup,mousePoint,transform.rotation);

Instantiate(particle, mousePoint,transform.rotation);

score -=1;

}}

Kada korisnik odabere stup, mijenja se njegova tekstura te se varijabla stup1 mijenja u istinu čime se kasnije, ako korisnik pritisne na prazno polje uz uvjet da ima rezultat (eng. score) veći ili jednak jedan, stvara jedan objekt. Na slici 5 vidimo tu promjenu.

Slika 5. Prije i poslije odabira čokolade u igri [9]

U nastavku se nalazi primjer koda za pritisak na gumb „skok“ kojem je tag postavljen na „gore“. Pritiskom na gumb, varijabla MisKliknutGORE postaje istina pri čemu će igrač, ako je na tlu, skočiti.

private var mousePoint : Vector3;

var Jump : float = 2.0;

var MisKliknutGORE: boolean = false;

var jumpSound:AudioClip;

function Update () {

var rayHit : RaycastHit;

if(Physics.Raycast(Camera.main.ScreenPointToRay(Input.mousePosition), rayHit)) {

mousePoint = rayHit.point;

if(Input.GetMouseButtonDown(0) && rayHit.collider.tag == "gore"){

AudioSource.PlayClipAtPoint(jumpSound, transform.position);

rigidbody.velocity.y = Jump;

MisKliknutGORE == true

}

}

102 CASE2018

Za animiranje modela mora se konstruirati Animation Controller (prikazan na slici 6) koji služi za podešavanje animacija te upravljanje istima unutar skripte. Animation Controller koristi automat stanja u kojem pojedina stanja predstavljaju osnovne animacije (eng. animation clips). U automatu stanja se povezuju animacije kako bi prijelaz među njima bio što prirodniji.

Slika 6. Prikaz automata stanja[9]

Skripte koristimo za upravljanje animacijama unutar scene. Unutar skripte možemo definirati odnosno kreirati događaje koji se izvode kada napravimo određenu akciju. U sljedećem primjeru koda je vidljivo kako se pomoću skripti pokreće određena animacija (u ovom slučaju skok).

if(MisKliknutGORE == true){ anim.SetBool("skok",true); }

if(MisKliknutGORE == false){ anim.SetBool("skok",false); }

3.2.4 Izrada sučelja

Izbornik razina odnosno sučelje jedan je od bitnijih dijelova igre jer na njemu igrač vidi napredak koji je ostvario kroz igru. Glavne funkcije izbornika u igri Candy Freak [9] su:

ponudi igraču razinu/razine koje može igrati, spremi napredak kroz igru, prikaži koliko je uspješno igrač dovršio svaku pojedinu razinu.

Napredak igrača se pamti pomoću PlayerPrefs.SetInt ("LevelUnlock",level); u koji se sprema napredak igrača. Nakon prelaska određene razine, njen se broj sprema te se otključava sljedeća razina. Primjerice, ako je igrač završio prvu razinu, u PlayerPrefs.SetInt,("LevelUnlock",level); će se spremiti broj jedan te će se time otključati druga razina. Programski kod za navedeno se nalazi u nastavku.

function Update () {

if(PlayerPrefs.GetInt("LevelUnlock")>0){levelLock2.renderer.material.mainTexture= NOlock;}

if(Input.GetMouseButtonDown(0) && rayHit.collider.tag =="2" &&

PlayerPrefs.GetInt("LevelUnlock")>0){Application.LoadLevel ("2");}

}

Najprije se PlayerPrefs uspoređuje s nulom kako bi se provjerilo da li je prva razina dovršena. Ukoliko jest, uklanja se tekstura lock koja prikazuje da je razina zaključana (ilustrirano na slici 7).

Ako igrač pritisne na određenu razinu (u ovom slučaju drugu), ponovno se PlayerPrefs uspoređuje s nulom te ako je isti veći od nule, igraču se omogućuje ulazak na drugu razinu.

CASE2018 103

Slika 7. Izbornik prije i poslije prelaska prve razine [9]

3.2.5 Podešavanje grafičkih svojstava

Iz perspektive razvoja igre, posebnu je pozornost potrebno posvetiti vizualnim efektima jer su isti namijenjeni pružanju direktne povratne informacije igračima. Navedeno implicira da se vizualni efekti mogu pojaviti u različitim oblicima. Tako se vizualni efekti mogu upotrijebiti u svrhu stvaranja nekog prizora (npr. učinak vjetra koji otpuhuje pijesak u pustinji) ili manifestacije nečega što igrač očekuje da će percipirati kada poduzme određenu radnju (npr. prigušeni bljesak pištolja kod pucnja). Osim navedenog, vizualni efekti se mogu koristiti i za komunikaciju igrivosti i mehanika igre. Primjerice, igrač će imati daleko veći osjećaj nadmoći ako se kod zamaha mača prikaži efekt čestica na vrhu istog nego kada je spomenuti efekt izostavljen odnosno kada nije implementiran u igri. Efekti dostupni u okruženju Unity su kako slijedi [12]:

Particle System koji simulira fluidne objekte kao što su tekućine, oblaci i plamenovi. Trail Renderer se koristi za stvaranje staza iza nekog objekta dok se isti kreće. Line Renderer je komponenta koja uzima niz od dvije ili više točaka u 3D prostoru i povlači ravnu liniju između svake

od njih. Lens Flares simuliraju učinak reflektiranja svjetala, a koriste se za predstavljanje stvarno sjajnih svjetala ili stvaranje

atmosfere na sceni. Halos su lagani prostori oko izvora svjetlosti koji stvaraju dojam sitnih čestica prašine u zraku. Projector je namijenjen stvaranju sjene i ostalih svjetlosnih efekata.

3.2.6 Testiranje i ispravljanje pogrešaka

Tijekom razvojnog ciklusa svih vrsta programskih proizvoda, pa time i igara, dolazi do manifestacije pogrešaka (bugova) koje rezultiraju raznovrsnim problemima. Da bi pronašli pogreške u igri, istu je potrebno temeljito testirati. Jednom kada se pogreška otkrije, potrebno ju je dokumentirati i otkloniti. Unity Debugger je sastavni dio Unity okruženja koji omogućuje pregledavanje koda tijekom izvođenja u svrhu pronalaženja i otklanjanja pogrešaka. Njegovom se primjenom primjerice može odrediti kada se poziva neka funkcija i koje vrijednosti joj se prosljeđuju, identificirati vrijednosti varijabli skripte u određenom trenutku tijekom pokretanja igre te pronaći logičke pogreške u skriptama tako da ih izvršimo korak po korak. Alternativni način pronalaženja pogrešaka u kodu je pomoću funkcije Debug.Log koja omogućuje ispisivanje poruke u konzoli kad se određeni događaj manifestira u igri. Primjer primjene funkcije je prikazan u sljedećem programskom kodu te ilustriran na slici 8. Kada igrač stigne do kraja određene razine, u konzoli se ispisuju varijable koje želimo provjeriti.

Function OnTriggerEnter (other:Collider){

If (other.gameObject.tag == "kraj"){

Debug.Log(string.Format("brzina:{0},broj bombona:{1},Name:{2}",brzina,bomboni,ime));}}

104 CASE2018

Slika 8. Ispis u konzoli

3.3 Plasiranje na Google Play trgovinu

Prije nego što se bilo koja aplikacija objavi, potrebno je istu testirati na reprezentativnom broju različitih uređaja te zatim zapakirati. Pakiranjem se dobiva apk datoteka koja je zapravo komprimirana zip datoteka i u sebi sadrži više direktorija i datoteka. Za objavljivanje igara na Google Play-u razvojni programeri moraju posjedovati Google korisnički račun te je prilikom prve prijave na Google Play potrebno uplatiti iznos od 25 američkih dolara na ime registracije. Programer pored učitavanja apk datoteke treba definirati dodatne informacije o igri. Potrebno je odabrati naziv za prikaz, sastaviti kraći i dulji tekstualni opis igre te krierati barem dvije snimke ekrana (eng. screenshots) izvođenja igre. Preporučljivo je kreirati nekoliko slika različitih veličina kako bi se igra lakše automatski promovirala unutar Google Play trgovine. Moguće je i objaviti videozapis igranja igre koji će biti prikazan među ostalim grafičkim prikazima. Prije objavljivanja, potrebno je još ručno opisati igru odabirom kategorije kojoj pripada te popunjavanjem upitnika o sadržaju čime se dobiva certifikat odobrenja sadržaja.

Nakon distribucije, igru je potrebno održavati i, ovisno o igri, nadograđivati. Nadogradnja igre podrazumijeva implementaciju dodataka u igru kao što su nove staze te popravaka nakon distribucije koji su poznatiji pod nazivom zakrpe (eng. patches). Nakon objave, programeru su dostupne razne mogućnosti praćenja uspjeha aplikacije pomoću alata Google Analytics. Moguće je vidjeti broj instalacija te filtrirati prikaz po verziji Android sustava, nazivu uređaja, jeziku i zemlji korisnika.

3.3.1 Mogućnosti zarade

Plan zarade mora biti osmišljen na samom početku jer će on bitno utjecati na razvoj i dizajn aplikacije. Potrebno je precizno znati u kome dijelu će se pojaviti opcija za kupovinu unutar aplikacije. Da bi se uhvatio pravi trenutak u tom kontekstu, potrebno je znati koje poteze igrači obično koriste, koji su dijelovi igre najteži, kada je najvjerojatnije da će igrači kupiti virtualne artefakte i slično.

Da bi se reklama prikazivala u igri, potrebno je imati Google Wallet račun i unutar aplikacije omogućiti korištenje Google-ovih API-ja za naplatu i/ili oglašavanje. Oglasi, reklame i plaćanje virtualnih artefakata neće demotivirati obožavatelje igara. Važno je osmisliti i napraviti dobru igru koja će privući što veći broj igrača na dulje vrijeme. Dodatak za monetizaciju je kreiran na način da radi samo na platformama sa Android operativnim sustavom. Da bi ugradili monetizaciju u neku igru, potrebno je odabrati jednog od mnogobrojnih poslužitelja reklama kao što su AdMob, UnityAds i ChartBoost te implementirati dodatak koji poziva funkciju za prikazivanje reklame. Jednom kada je usluga oglašavanja omogućena, kod za prikazivanje oglasa se može implementirati u bilo kojoj skripti na način kao što je prikazano u nastavku.

Advertisement.Show()

U igri Candy Freak [9], igrači su nagrađivani za gledanje oglasa do kraja trajanja istog pomoću koda koji je prikazan u nastavku. Nagrađivanjem se povećava angažman igrača što rezultira većim prihodom.

void ShowRewardedVideo () {

ShowOptions options = new ShowOptions();

options.resultCallback = HandleShowResult;

Advertisement.Show("rewardedVideo", options);

}

void HandleShowResult (ShowResult result) {

if(result == ShowResult.Finished) {

Debug.Log("Video completed - Offer a reward to the player");

coin = coin + 10;

}

else if(result == ShowResult.Skipped) {

Debug.LogWarning("Video was skipped - Do NOT reward the player");

}

else if(result == ShowResult.Failed) {

Debug.LogError("Video failed to show");

}

}

Ovaj dodatak učitava reklamu s identifikacijom programera, prikazuje je, te ako igrač klikne na reklamu, programer ostvaruje određeni prihod. Ovisno od lokaciji na kojoj se igrač nalazi i vrsti igre, spomenuti dodatak bira jednu od prikladnih reklama. Nakon što se završi sa prikazivanjem reklame, neovisno o tome da li je igrač kliknuo na reklamu ili istu samo ugasio, igra nastavlja sa svojim radom tamo gdje je stala prije prikazivanja reklame.

CASE2018 105

3.3.2 Oglašavanje igre

Marketing je, poslije objavljivanja igre, najvažnija faza koja vodi željenom cilju - velikom broju preuzimanja igre. Da bi se navedeno ostvarilo, nije dovoljno samo razviti dobru igru. Mnoge dobre igre na kraju ostvare samo nekoliko desetina ili stotina preuzimanja što nije dovoljno za ostvarivanje ozbiljnog prihoda. Kako do toga ne bi došlo, potrebno je koristiti jedan ili više kanala na oglašavanje igre [11]:

Promocija na društvenim mrežama kao što su Facebook, Twitter, Instagram. Reklamiranje igre u što više grupa koje su sadržajno bliske igri. Promocija igre po forumima. Plaćeni oblici oglašavanja od strane za to specijaliziranih Web mjesta i pojedinaca.

4. ZAKLJUČAK

Da bi indie programeri mogli konkurirati visokobudžetnim studijima, isti moraju posjedovati vrhunske dizajnerske i razvojne vještine. Međutim, često ni navedeno nije dovoljno, već indie programeri moraju ići korak dalje te razmišljati van okvira kako bi na tržište plasirali što kreativniju i inovativniju igru. U ovom su radu objašnjene glavne faze izrade mobilne indie igre. Kroz praktičan primjer opisani su procesi oblikovanja ideje, razvoja igre, njenog plasiranja na tržište te savjeti kako najlakše zaraditi od izrade mobilne igre. Kod izrade igre najvažnije je pronaći adekvatan alat kojim će biti moguće ostvariti sve što si je razvojni programer odnosno tim zamislio. U ovom je radu u tu svrhu korišteno Unity 3D razvojno okruženje. Razvoj novih tehnologija omogućio je pojedincima da bez prevelikih troškova mogu sami razvijati igre te da izrada igara više nije rezervirana za velike razvojne timove kao što je to bio slučaj do prije nekih deset godina. Obzirom da je broj igrača stalno u porastu, indie igre su postale paradigma koja razvojnim programerima osigurava dobru zaradu.

Literatura:

1 Lapaš, T., Orehovački, T.: Evaluation of User Experience in Interaction with Computer Games. In: Marcus, A. (ed.) DUXU, Part III, HCII 2015. Lecture Notes in Computer Science, vol. 9188, pp. 271-282. Springer, Los Angeles (2015)

2 Orehovački, T., Babić, S.: Inspecting Quality of Games Designed for Learning Programming. In: Zaphiris, P., Ioannou, A. (eds.) LCT, HCII 2015. Lecture Notes in Computer Science, vol. 9192, pp. 620-631. Springer, Los Angeles (2015)

3 Braid, http://store.steampowered.com/app/26800/Braid/,(pristupano 20.1.2018)

4 World of Goo, http://store.steampowered.com/app/22000/World_of_Goo/, (pristupano 20.1.2018)

5 Grand Theft Auto V, http://store.steampowered.com/app/271590/Grand_Theft_Auto_V/ , (pristupano 20.1.2018)

6 Where's My Water, http://lol.disney.com/games/where-s-my-water, (pristupano 20.1.2018)

7 Brodkin, J.: How Unity3D Became a Game-Development Beast, http://insights.dice.com/2013/06/03/how-unity3d-become-a-game-development-beast/ (pristupano 20.1.2018)

8 Jaylen, I. The iPhone App Development Process, http://www.seoskylimit.com/THE-IPHONE-APP-DEVELOPMENT-PROCESS/, (pristupano 20.1.2018)

9 Crnković, E.: Izrada 2D Android igre u Unity okruženju, završni rad. Odjel za informacijsko-komunikacijske tehnologije, Sveučilište Jurja Dobrile u Puli, Pula, 2016.

10 Townsend, D.: 2D Video Game Art Styles, https://spritelygames.com/blog/2015/2d-video-game-art-styles, 2016 (pristupano 20.1.2018)

11 Kim, J.: App Marketing, This is Real Android Marketing: MOBILE APPS, EVERYTHING YOU NEED TO KNOW ABOUT BOOSTING PROFITABILITY!, ITMagnet Publishing, 2014

12 Unity Visual Effects Reference, https://docs.unity3d.com/Manual/comp-Effects.html, (pristupano 20.1.2018)

Podaci o autorima:

Edi Crnković, univ. bacc. inf. e-mail: ecrnkovic@unipu.hr Edi Crnković je student druge godine diplomskog studija informatike na Fakultetu informatike (prije Odjel za informacijsko – komunikacijske tehnologije) Sveučilišta Jurja Dobrile u Puli. Na istom je 2016. godine obranio završni rad te stekao zvanje sveučilišnog prvostupnika informatike. Glavna područja interesa su mu razvoj mobilnih aplikacija za Android platformu. U slobodno vrijeme se bavi izradom igara u okruženjima Unity 3D i Unreal te radom u Adobe Photoshopu. doc. dr. sc. Tihomir Orehovački e-mail: tihomir.orehovacki@unipu.hr Tihomir Orehovački diplomirao je i doktorirao 2005. i 2013. godine, respektivno, na Fakultetu organizacije i informatike Sveučilišta u Zagrebu. Pedagoško-psihološko-didaktičko-metodičku naobrazbu stekao je tijekom akademske godine 2005./2006. na Visokoj učiteljskoj školi u Čakovcu (danas Učiteljski fakultet Sveučilišta u Zagrebu, Odsjek u Čakovcu). Od 1. listopada 2015. godine zaposlen je na radnom mjestu docenta na Odjelu za informacijsko-komunikacijske tehnologije (danas Fakultet informatike) Sveučilišta Jurja Dobrile u Puli gdje je nositelj kolegija vezanih uz programiranje. Član je Povjerenstva za akademsko priznavanje inozemnih visokoškolskih kvalifikacija i razdoblja studija te Odbora za

106 CASE2018

znanstveni i umjetnički rad Sveučilišta Jurja Dobile u Puli. Autor je 75 znanstvenih radova objavljenih u zbornicima međunarodnih konferencija, časopisima i knjigama te 10 stručnih radova objavljenih u zbornicima domaćih skupova. Znanstveno se i stručno usavršavao na brojnim radionicama i institucijama u zemlji i inozemstvu. Bio je voditelj projekta financiranog sredstvima HRZZ. Osim toga, sudjelovao je u istraživačkim aktivnostima projekata financiranih sredstvima Europske Unije, Zaklade Adris, Ministarstva znanosti i obrazovanja te Sveučilišta u Zagrebu. Bio je suorganizator i predavač na 2 radionice vezane uz upravljanje međunarodnim projektima i 7 radionica vezanih uz primjenu društvenih Web aplikacija u obrazovanju. Aktivni je recenzent za 15 međunarodnih znanstvenih časopisa, 2 znanstvene knjige i 11 međunarodnih znanstvenih konferencija. Vršio je dužnost člana Programskog odbora, voditelja tematskih cjelina i sekcija sljedećih međunarodnih znanstvenih konferencija: International Conference on Information Systems Development (ISD), ACM International Conference on Intelligent User Interfaces (IUI), International Conference on the Quality of Information and Communications Technology (QUATIC) - Track on Quality in Web Engineering te International Conference on Information Technology (ICIT). Bio je član Organizacijskog odbora, urednik knjige sažetaka i tehnički urednik zbornika radova međunarodne znanstvene konferencije ISD 2014. Član je sljedećih međunarodnih strukovnih udruženja: Association for Computing Machinery, European University Information Systems E-Learning Task Force, Institute of Electrical and Electronics Engineers i International Society for Web Engineering. Za svoj znanstveni, nastavni i stručni rad primio je nekoliko međunarodnih i domaćih nagrada i priznanja. Dosad je pod njegovim mentorstvom 49 studenata obranilo završne i diplomske radove. Fakultet informatike u Puli, Sveučilište Jurja Dobrile u Puli Zagrebačka 30, 52100 Pula