razvoj poslovnih razvoj poslovnih ii informati … · 2019-03-28 · case2019 3 sadrŽaj zlatko...
TRANSCRIPT
CASE 2019CASE 2019
25.02.-26.02.2019, Zagreb
RAZVOJ POSLOVNIH I INFORMATIČKIH SUSTAVA
RAZVOJ POSLOVNIH I INFORMATIČKIH SUSTAVA
Brončani pokroviteljiBrončani pokrovitelji
Srebrni pokroviteljSrebrni pokrovitelj
Zlatni pokroviteljZlatni pokrovitelj
CASE2019 1
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, 2019
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: [email protected], internet: www.case.hr
2 CASE2019
CASE2019 3
SADRŽAJ
Zlatko Sirotić, univ.spec.inf. TESTIRANJE KONKURENTNIH TRANSAKCIJA U BAZI PODATAKA
7
Marko Havoić, dr.sc. Marin Kaluža, Sabrina Šuman SMJERNICE ZA MIGRACIJU KOMPONENTI POSLOVNOG SUSTAVA NA IAAS CLOUD OKRUŽENJE
19
Antun Delinger, mag.oec., doc.dr.sc. Tihomir Orehovački PRIMJER RAZVOJA - SUSTAV ZA EVIDENCIJU RADA AUTOSERVISA
27
Hrvoje Španja, dr.sc. Marin Kaluža, Sabrina Šuman PREGLED MOGUĆNOSTI ZAŠTITE IZVORNOG PROGRAMSKOG KODA
43
Ivan Matak, univ. bacc. inf., doc. dr. sc. Tihomir Orehovački MOGUĆNOSTI OKRUŽENJA VUE.JS I NJEGOVIH PAKETA
57
Vlatko Matić, univ. bacc. inf., doc. dr. sc. Tihomir Orehovački IZRADA RAČUNALNE IGRE U OKRUŽENJU GAMEMAKER
65
4 CASE2019
CASE2019 KONFERENCIJA
CASEdev - Prvi dan konferencije (25.02.) tradicionalno je posvećen razvojem IS-a.
Razvoj rješenja lakši je primjenom prototipnog razvoja rješenja. Jedan od načina temelji se na:
• REST web-servisima na serverskoj strani, napravljenima u Django REST Frameworku (DRF)
• Single-page web aplikaciji (SPA) napravljenoj u Angularu 6 za klijentsku stranu tj. internetski preglednik (browser). Serverska strana koristi web-servise javne informacijske infrastrukture (MUP).
Stalno se istražuju nove mogućnosti, nove tehnologije. Danas velik broj tvrtki razmišlja kako pojačati svoje sustave blockchainom, ne razmišljajući pritom treba li im ona zaista. Prikazom osnovne svrhe blockchaina dati ćemo uvid u kompatibilnost tih originalnih ciljeva s prirodom posla tradicionalnih tvrtki. U primjeni treba obratiti pažnju na "enterprise" blockchain sustave poput IBMovog Fabric-a, te rezimirati zašto ima ili nema ekonomskog rezona u ovoj tehnologiji.
Često se u bazi podataka izvode transakcije, kod kojih integritet podataka ovisi i o ostalim transakcijama koje se istovremeno izvode. Rad tih (konkurentnih) transakcija treba testirati u višekorisničkom radu, ili simulirati višekorisnički rad. Prezentirati ćemo testiranje (složenog) poslovnog pravila u Oracle bazi,. Prikazat će se testiranje na dva načina: pomoću Java Executora i (za one koji žele raditi samo s bazom podataka) pomoću job-ova u bazi.
Povratne informacije nakon penetracijskog testa pokazuju klijentima kako mogu napraviti ili poboljšati procedure za rješavanje računalno sigurnosnih incidenata što ne bi bilo moguće ako aplikacija nema pronađenih ranjivosti. Tijekom predavanja pokazati ćemo ogledne primjere ponašanja napadača i kako se ta ponašanja reflektiraju u sistemskim zapisima te kako to spriječiti.
Razvoj korištenjem NuGet paketima ima prednosti ali i probleme. Kako ih publicirati, kako kreirati vlastiti "NuGet source", kako natjerati "stari" dotNET projekt da vidi NuGet pakete izdvojeno od klasičnih referenci i kako iskoristiti SourceLink da nam omogući "debug" NuGet paketa.
Slušate o digitalnoj transformaciji na dnevnoj bazi, no ostaje puno pitanja oko toga što točno ona predstavlja, kako se provodi i što je točno. Je li digitalna transformacija samo za IT firme? Ili je samo za određene firme? Ima li veze sa internim poslovanjem i procesima ili i sa korisnicima? Predavanje ce dati odgovore na ta i druga pitanja, s naglaskom na razvoj agilnog poslovanja kroz digitalnu transformaciju.
Excel se i danas zadržao kao najrašireniji oblik programske podrške poslovnim aktivnostima. Jednostavnost korištenja, ugrađene formule i grafikoni, trenutno osvježavanje ćelija, te tablični prikaz podataka razlozi su njegove široke primjene. Nova platforma spreadsheet2application omogućuje portiranje Excel tablica u web aplikaciju nad bazom podataka, čime korisnički dokumenti i proračuni dobivaju brojne funkcionalnosti (prezentiranje, pretraživanja i filtriranja velike količine podataka, višekorisnički rad, izradu izvješća nad podacima, itd.
Microsoft PowerApps omogućuje naprednim korisnicima i profesionalnim razvojnim inženjerima nove načine izrade mobilnih aplikacija brzo i produktivno. Olakšava gradnju bogatih aplikacija bez pisanja koda, korištenjem online drag & drop razvojne okoline i jednostavnu mogućnost povezivanje s aplikacijskim servisima koji su smješteni u Microsoft Azure ili nekom drugi sustavu u oblaku. Želimo pokazati kako se mogu razviti potpuno funkcionalni prototipovi mobilnih i web aplikacija, korištenjem Azure i Office 365 PowerApps funkcija.
Data Governance, u današnjoj poplavi ogromnih količina podataka, kako strukturiranih tako i nestrukturiranih, ako želimo da nam podaci omoguće poslovne koristi, moramo znati njima upravljati. Koje podatke i kako želimo upravljati je područje koje nazivamo ovladavanje podataka U predavanju će biti predstavljeni ključni elementi područja ovladavanja podataka s posebnim naglaskom na rješavanje zahtjeva koje nam za zaštitu osobnih podataka postavlja GDPR.
Uredba GDPR propisuje da ukoliko dođe do povrede osobnih podataka, nadzorno tijelo, a u nekim slučajevima i ispitanici, trebaju o tome biti obaviještene unutar 72h od otkrivanja. No otkrivanje incidenata i povrede osobnih podataka velik je izazov jer dešava da prođu dani pa i mjeseci od incidenta do njegovog otkrivanja. Specijalizirani alati mogu pomoći otkriti incidente i povrede podataka u bazi podataka (u ovom slučaju MS SQL Server baza podataka) u stvarnom vremenu?.Pomoću alata IDERA SQL Secure možemo uraditi i audit baze podataka kako bi utvrdili koje su nam potencijalne slabosti naše baze, analizirali prava pristupa podacima, utvrdili slabe lozinke, pravila ponašanja servera i dr., te dobili detaljne izvještaje.
Prikaz GDPR izazova koje developer konzultant ima tijekom implementacije web rješenja u konzervativnom okruženju, koje ponekad zahtjeva implementaciju pretjeranih i možda nerealnih mjera, zbog zaštite
CASE2019 5
korisničkih podataka, tj. usklađenja sa GDPR propisima. Ključne riječi: microservices, security, encryption, cloud, kubernetes, monitoring, logging.
Primjeri uspješnih primjena metoda dubokog učenja u analizi teksta i slike u poslovnom okruženju digitalnog izdavaštva. Kako rezultati domaće pameti stoje u usporedbi s najboljima (usporedba rezultata computer vision modela Styria vs. Alibaba). Više o Styria projektima možete saznati na njihovoj službenoj stranici: https://www.styria.ai/
Radionice:
1. Styria.ai recommender sistemi omogućavaju preporuku sličnih oglasa koristeći sliku i tekst uz pomoć algoritama dubokog učenja. Na radionici ćemo vas upoznati sa evolucijom našeg recommender sustava, izazove na koje smo naišli, pogreške koje smo napravili te konačnu arhitekturu sustava kojeg danas koriste milijuni korisnika dnevno.
2. radionica: "back-end" servisi Aplikacije žive od komunikacije s Web API servisima i mikroservisima (tj. "front-end" tehnologijama i "back-end" servisima). U radionici ćemo kreirati ASP.NET Core 2.0+ Web API servis i pokazati kako iskoristiti sve prednosti. Posebnu pažnju ćemo obratiti pisanju kvalitetnog koda, uvesti dobre prakse u arhitekturi rješenja, predložiti kada mikroservisi imaju smisla, osvježiti C# sintaksu i pokazati načine ubrzanja izvođenja i povećanja performansi. Polaznici će sa radionice odnijeti gotovi servis koji služi kao polazna točka za izgradnju novih projekata.
CASEmobile - Drugi dan konferencije (26.02.) posvećen je mobilnim aplikacijama.
Tržište u 2018. godini pokazuje pad a jedan od najznačajnijih razloga je problem kretanja unutar virtualnog svijeta (virtualne stvarnosti). Unatoč velikim tehnološkim postignućima modernih sustava za virtualnu stvarnost kretanje unutar virtualne stvarnosti još uvijek kod velikog broja korisnika uzrokuje mučninu, jedan oblik kinetoze. U slučaju virtualne stvarnosti vidni sustav doživljavaj pokret dok sustav za ravnotežu i osjećaj u prostoru ne doživljavaju isti te uzrokuju razne simptome mučnine. U ovom predavanju analizirati će se različiti tipove kretanja te iskustvena kvaliteta za odabrani podskup načina kretanja.
Prednosti Embarcadero RAD Studio razvojne okoline, koja omogućuje u jednom potezu razvoj native aplikacija za više OSa. Različite platforme, pojava Internet of Things uređaja, stalno skraćivanje rokova i smanjenje budžeta razvoja samo su neki od izazova s kojima se susreću razvojni timovi. Da li je moguće brzo razvijati kvalitetni softver za različite platforme? Da li je jedan programer danas u stanju to sam učiniti? Da li razvijati native aplikacije prilagođene uređaju ili ići na univerzalna rješenja? Što je s podrškom za korporativne baze podataka i da li je moguće integrirati mobilne i cloud platforme s postojećim sustavima?
React Native - U protekle dvije godine, primjena cross-platform tehnologije je naglo porasla zbog naglog razvoja mobilnih aplikacija za raznolike platforme. Pozabaviti ćemo se cross-platform rješenju koje je uspjelo podići najviše prašine -. Poučen vlastitim iskustvima, izdvojiti ću prednosti i nedostatke razvoja mobilnih aplikacija nativno naspram razvoja mobilnih aplikacija u React Native-u. Naposljetku, osvrnuti ću se i na ostala popularna rješenja za cross-platform razvoj mobilnih aplikacija i koja je budućnost takvog načina razvoja mobilnih, ali i ostalih aplikacija.
Razvoj IoT sustava - Prezentacija pristupa razvoja IoT sustava i aplikacija na Sveučilišnom odjelu za stručne studije Sveučilišta u Splitu. Odabir odgovarajuće hardverske platforme veoma je bitan za optimiranje potrošnje energije senzorskog čvora. Dan je pregled softverskih platformi te bežičnih komunikacijskih tehnologija i standarda koji se primjenjuju na Odjelu za realizaciju različitih IoT aplikacija i sustava. Kroz primjere prikazati će se primjena različitih programskih alata za razvoj IoT sustava: LabVIEW platforme, C++ jezik na strani senzorskog čvora i Node.js na strani web poslužitelja. U trećem primjeru realizira se ZigBee mreža primjenom C++ jezika za realizaciju aplikacije. Četvrti primjer prikazuje LoRaWAN mrežu gdje su senzorski čvorovi programirani u C++ jeziku, a za prikupljanje i vizualizaciju podataka koriste se platforme otvorenog koda The Things Network i myDevices Cayene.
Migracija na IaaS cloud okruženje – Različiti su aspekata koje je potrebno razmotriti prilikom procesa odabira, evaluacije i planiranja migracije na IaaS cloud okruženje. Proces započinje sa odlukom o migraciji i odobrenjem uprave. U daljnjim koracima analiziraju se različiti faktori trenutnog sustava, te različite opcije dostupne kod cloud pružatelja usluga. Važno je prepoznati sve ili koliko je to moguće faktora koji će voditi ka uspješnoj migraciji. Prikazuju se faze, procesi i aktivnosti koje će pomoći u planiranju migracije.
Office365 PowerBI je omogućio revoluciju u pristupu vizualizaciji i kreiranju uvida u podatke kroz tzv. samoposlužni BI.
Ovim moćnim alatom imate uvid u veliki broj podataka, brze analize što dovodi do pravovremene odluke temeljene na aktualnim informacijama. Dođite i saznajte kako uključiti PowerBI u svoju aplikaciju i omogućiti korisnicima korištenje PowerBI mogućnosti na vlastitim podacima, kao i kako da ih podijele s kolegama i suradnicima. DeOffice365 PowerBI je omogućio revoluciju u pristupu vizualizaciji i kreiranju uvida u podatke kroz tzv. samoposlužni BI.
6 CASE2019
Sustav za upravljanje radom autoservisa. Cilj je omogućiti je lakšu komunikaciju s klijentima u poslovnoj domeni koja još uvijek nije uhvatila korak s najnovijim trendovima i tehnologijama, pomoću tri aplikacije – dvije mobilne Android aplikacije od kojih je jedna namijenjena klijentima, a jedna autoservisu te web aplikacije koja je namijenjena isključivo autoservisu. Klijenti se putem mobilne aplikacije mogu dogovoriti za novi termin pregleda vozila te pratiti povijest popravaka, a osoblje autoservisa putem web aplikacije odgovara na upite i eventualno potvrđuje dogovor za termin. Svaki odgovor autoservisa zabilježen je obavijesti koja dolazi na Android uređaj.
Xamarin i Xamarin.Forms su cross platform alati za razvoj nativnih mobilnih aplikacija bazirani je na .Net platformi korištenjem programski jezika C#, F# ili VB.Net. Cilj predavanja je predstaviti tehnologije, prenijete osnove alata i naučiti razliku između Xamarin-a i Xamarin.Forms-a.
Zaštita izvornog koda - Izvorni programski kod je autorsko djelo pojedinca ili grupe pojedinaca tj. tvrtke. Svaki aplikativni softver učitava izvorni programski kod iz izvršne datoteke u memoriju računala prilikom izvršavanja funkcija aplikativnog softvera. Opisati ćemo razne metode zaštite izvornog programskog koda za različite programske jezike, i objašnjavaju se njihove prednosti i nedostaci u odnosu na ostale. Uspoređuju se mogućnosti čitanja izvornog programskog koda nakon primjene opisanih metoda zaštite. Predlaže se najsigurnija metoda zaštite izvornog programskog koda za analizirane programske jezike.
Vue.js je okruženje koje omogućuje programiranje i razvoj aplikacija kombinacijom HTML i JavaScript jezika. Osim okruženja Vue.js, za pomoć pri razvoju okruženja i aplikacija mogu se koristiti paket za dizajn komponenti Vuetify, Vuex store management i besplatna baza podataka Google Firebase. U uvodnom dijelu rada raspravlja se općenito o Vue.js okruženju i njegovim paketima. Kroz sljedeća se poglavlja opisuju mogućnosti okruženja, od jednostavnijih prema kompleksnijim, uključujući izradu stranice i povezivanje sa bazom podataka. Svaka mogućnost okruženja potkrijepljena je primjerom implementacije.
Game Maker Studio - Računalne igre se neprestano razvijaju i napreduju. Jednostavnija razvojna okruženja omogućuju novim korisnicima razvoj projekata te da pritom uče programirati i implementirati nove ideje. Kompleksnija okruženja služe kako bi napredniji korisnici ili stručnjaci mogli razvijati kvalitetnije nove projekte u što manjem vremenu. Jedno od najpopularnijih okruženja za izradu igara je Game Maker, koji se može svrstati između dvije navedene kategorije. U ovom radu opisan je proces izrade računalne igre u tom okruženju, ali i sam Game Maker te njegovi osnovni koncepti.
Radionice:
3. R&D for .NET runtime and libraries - Danas sa sve većom potražnjom za Edge (IoT, Mobile) i Cloud Computing, svaka nepotrebna potrošnja procesora ili memorije uzrokuje više trošenja baterije (kraće trajanje baterije) ili potrošnje energije u oblaku, što uzrokuje povećanje troškova ili za korisnika cloud operatora. To je bio razlog zašto je Microsoft uložio mnogo u istraživanje i razvoj performansi za .NET runtime i knjižnice koje su nam davale `Span` i` Memory `i pod` C` / `C ++` performanse u upravljanom kodu. Kako bi se natjecali s Pythonom, R i Matlab / Octaveom u znanstvenim svjetovima kao što su Data Science (strojno učenje, duboko učenje) .NET kao jezik za opće namjene poduzeća potrebni su xplat knjižnice koje uzimaju performanse u računu. Ovo je priča o stvaranju, održavanju i prijenosu takvih knjižnica u suvremenom horizontalnom i vertikalnom xplat .NET-u.4. Xamarin.Forms - Dublje će se ući u tehnologiju Xamarin.Forms. Demostrirat će se kako koristit Xamarin.Forms u praksi, proći će se osnovne stvari i na kraju radionice izradit osnovnu aplikaciju. Cilj radionice je razumiti kako jednostavno napravit aplikaciju za iOS i Android platformu korištenjem Xamarin.Forms frameworka.
Podaci o autoru:
Ante Polonijo, dipl.ing., dipl.oec. Tajnik konferencije CASE d.o.o., Antuna Barca 12, 51000 Rijeka tel. +385 51 217 875, fax. +385 51 218 043 e-mail: [email protected]
PROFESIONALNA KARIJERA:
- predavao Električna mjerenja na srednjoj stručnoj školi za elektroniku, programirao u Cobol-u u “Inžinjerskom birou” (u Zagrebu), organizator informatike i 13 godina šef ERC-a u “HEP DP Elektroprimorje” Rijeka te šef organizacije i programiranja u DINI Omišalj.
- Od 1986-2009.g. radi u HGK Županijska komora Rijeka na radnom mjestu savjetnika informatike i statistike, te voditelja odsjeka makroekonomske analize. (Paralelno od 1990-94 radio 1/3 radnog vremena kao voditelj grupe za informatiku u remontnom brodogradilištu “V.Lenac” 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.
CASE2019 7
TESTIRANJE KONKURENTNIH TRANSAKCIJA U BAZI PODATAKA
TESTING CONCURRENT TRANSACTIONS IN THE DATABASE
Zlatko Sirotić, univ.spec.inf.
SAŽETAK
Često se u bazi podataka izvode transakcije kod kojih integritet podataka ovisi i o ostalim transakcijama koje se istovremeno izvode. Rad tih (konkurentnih) transakcija treba testirati u višekorisničkom radu, ili simulirati višekorisnički rad. Za testiranje rada npr. sto konkurentnih transakcija, vjerojatno nećemo moći koristiti sto testera (ljudi), već odgovarajuće alate za testiranje. Možemo koristiti specijalne alate za tu namjenu, ili možemo sami napraviti testove na relativno jednostavan način, kako je prikazano u ovom radu.
ABSTRACT
The database often performs transactions where data integrity depends on other transactions that run concurrently. The operation of these (concurrent) transactions should be tested in multiuser work, or simulated multiuser work. For testing a hundred concurrent transactions, instead of using a hundred testers (people), we will use appropriate test tools. We can use special tools for that purpose, or we can make tests on our own in a relatively simple way, as shown in this paper.
1. UVOD
Često se u bazi podataka izvode transakcije kod kojih integritet podataka ovisi i o ostalim transakcijama koje se istovremeno izvode. Rad tih (konkurentnih) transakcija treba testirati u višekorisničkom radu, ili simulirati višekorisnički rad. Za testiranje rada npr. sto konkurentnih transakcija, vjerojatno nećemo moći koristiti 100 testera (ljudi), već odgovarajuće alate za testiranje. Možemo koristiti specijalne alate za tu namjenu, ili možemo sami napraviti testove na relativno jednostavan način.
U radu će se prikazati testiranje (složenog) poslovnog pravila u Oracle bazi, koji smo prikazali na CASE 16 (2004. godine): "Kako spriječiti 'začarani krug' (rješavanje određenog tipa poslovnih pravila u Oracle bazi podataka)".
U 2.točki prikazuju se Oracle specifične i ANSI standardne varijante SQL hijerarhijskih upita u Oracle bazu. U 3.točki i 4. točki ponovit ćemo (radi lakšeg razumijevanja sljedećih točaka) dio teksta iz navedenog rada sa CASE 16. U 3. točki prikazat ćemo rješenje koje sprečava pojavu petlje (u hijerarhijskoj strukturi podataka) u jednokorisničkom radu, ali to rješenje nije dobro za višekorisnički rad (vrlo lako se nađe primjer koji to pokazuje). U 4. točki prikazuju se dva rješenja koja bi trebala biti dobra i za višekorisnički rad. Jedno koristi tzv. autonomne transakcije, a drugo (bolje, jer javlja manje lažnih grešaka) koristi (naš) trik – simulaciju "ROLLBACK TO SAVEPOINT" u okidaču baze podataka. Iako navedena rješenja intuitivno izgledaju pouzdano (u smislu da ne dozvoljavaju grešku, tj. pojavu petlje), nije dat formalni dokaz. Prema tome, jako je važno da ta rješenja dobro testiramo.
Prikazat će se testiranje na dva načina: u 5. točki pomoću Java Executora, a u 6.točki (za one koji žele raditi samo s bazom podataka) pomoću jobova u bazi.
2. VARIJANTE SQL HIJERARHIJSKIH UPITA U ORACLE BAZI
Oracle baza je dugo godina imala specifičnu varijantu sintakse za hijerarhijske upite, pomoću CONNECT BY klauzule. Slijede dva primjera – jedan kod kojeg naredba javlja grešku ako već postoji petlja u podacima, i drugi primjer, koji ne javlja grešku:
-- varijanta koja puca kod petlje
SELECT empno, ename, mgr, LEVEL
FROM emp
START WITH mgr IS NULL
CONNECT BY PRIOR empno = mgr;
-- varijanta koja NE puca kod petlje
SELECT empno, ename, mgr, LEVEL, CONNECT_BY_ISCYCLE iscycle
FROM emp
START WITH mgr IS NULL
CONNECT BY NOCYCLE PRIOR empno = mgr;
8 CASE2019
Oracle ANSI standard za hijerarhijski upit koristi tzv. recursive common table expressions (recursive CTE). Oracle baza podržava recursive CTE od Oracle verzije 11.2 (2009. godine) – od tada WITH klauzula (u SELECT naredbi) može biti rekurzivna.
-- varijanta koja puca kod petlje
WITH each_level (empno, ename, mgr, rlevel) AS
(SELECT empno, ename, mgr, 1 rlevel -- kao START WITH
FROM emp
WHERE mgr IS NULL
UNION ALL -- kao CONNECT BY
SELECT emp.empno, emp.ename, emp.mgr, rlevel + 1
FROM emp, each_level
WHERE emp.mgr = each_level.empno
)
SELECT * FROM each_level;
-- varijanta koja NE puca kod petlje
WITH each_level (empno, ename, mgr, rlevel) AS
(SELECT empno, ename, mgr, 1 rlevel -- kao START WITH
FROM emp
WHERE mgr IS NULL
UNION ALL -- kao CONNECT BY
SELECT emp.empno, emp.ename, emp.mgr, rlevel + 1
FROM emp, each_level
WHERE emp.mgr = each_level.empno
)
CYCLE mgr SET iscycle TO 'y' DEFAULT 'n'
SELECT * FROM each_level; -- prikazuje i stupac iscycle
3. SPREČAVANJE POJAVE PETLJE U HIJERARHIJSKOJ STRUKTURI PODATAKA U JEDNOKORISNIČKOM RADU
Često se želi zabraniti "začarani krug", tj. pojavu (zatvorene) petlje u jednostablastim ili višestablastim rekurzivnim strukturama podataka. Jednostablasta rekurzivna struktura je ona u kojoj točno jedan objekt nema "roditelja" (on je "vrh" stabla), a svi ostali imaju jednog "roditelja". Višestablasta rekurzivna struktura je sastavljena od više stabala, tj. barem dva objekta nemaju "roditelja", a svi ostali objekti imaju točno jednog "roditelja". Jedan primjer (jedno)stablaste strukture je dat poznatom Oracle tablicom djelatnika – "emp" (employes). Najjednostavniji opis tablice "emp" je:
CREATE TABLE emp (
empno NUMBER (4) NOT NULL PRIMARY KEY, ename VARCHAR2 (20) NOT NULL, mgr NUMBER (4) REFERENCES emp (empno) ) /
Želi se da baza spriječi petlju u tablici "emp", odnosno želi se onemogućiti da se dobiju podaci u kojima bi neki djelatnik bio menadžer drugom djelatniku, a drugi djelatnik bi (direktno ili indirektno) bio menadžer prvom djelatniku.
Prvo se tablicu "emp" puni sa 7 redaka. Djelatnik sa brojem 1 bit će "glavni šef", djelatnici sa brojevima 2 i 3 bit će "šefovi" (podređeni "glavnom šefu"), djelatnici 4 i 5, odnosno 6 i 7, bit će podređeni "šefu 2", odnosno "šefu 3":
INSERT INTO emp (empno, ename, mgr) VALUES (1, 'EMP 1', NULL);
INSERT INTO emp (empno, ename, mgr) VALUES (2, 'EMP 2', 1);
INSERT INTO emp (empno, ename, mgr) VALUES (3, 'EMP 3', 1);
INSERT INTO emp (empno, ename, mgr) VALUES (4, 'EMP 4', 2);
INSERT INTO emp (empno, ename, mgr) VALUES (5, 'EMP 5', 2);
INSERT INTO emp (empno, ename, mgr) VALUES (6, 'EMP 6', 3);
INSERT INTO emp (empno, ename, mgr) VALUES (7, 'EMP 7', 3);
Slika 1. Grafički prikaz početnih podataka u tablici EMP
CASE2019 9
Ovaj zahtjev je, očito, relativno lako definirati, a dosta je čest u praksi. Međutim, nije ga lako realizirati (isključivo) u bazi podataka, tj. bez pomoći klijentske strane. Ovdje se prikazuje rješenje tog zahtjeva u Oracle bazi podataka, bez pomoći programa na klijentu ili aplikacijskom serveru (dakle, rješenje je u cijelosti na strani baze).
Rješenje u jednokorisničkom radu je relativno jednostavno. Zapravo, rješenje bi bilo vrlo jednostavno kad ne bi dolazilo do jednog problema - problema mutirajućih tablica (mutating tables). Mutirajuća tablica je ona tablica koja se trenutačno modificira pomoću naredbe INSERT, UPDATE ili DELETE, ili ona tablica koja bi trebala biti ažurirana zbog efekta DELETE CASCADE deklarativnog ograničenja. Oracle ne dozvoljava da se mutirajuće tablice čitaju (niti ažuriraju) u "row" okidačima baze (database triggers), tj. okidačima koji se okidaju za svaki redak tablice, jer bi se kao rezultat (čitanja) mogla dobiti neka neočekivana vrijednost. Pojednostavljeno rečeno, Oracle ne dozvoljava da se čita tablicu dok traje proces njene izmjene u istoj sesiji baze.
Međutim, za razliku od "row" okidača, čitanje se može raditi u "statement" okidačima, tj. okidačima koji se okidaju jedanput za svaku naredbu INSERT, UPDATE ili DELETE. Klasično rješenje problema mutirajućih tablica jeste da se u "row" okidaču zapamti (npr. u PL/SQL memorijsku tablicu) koji su redovi ažurirani, a onda se u "after statement" okidačima čita PL/SQL tablica i primjenjuje se provjera poslovnog pravila na retke koji su zapamćeni u PL/SQL tablici. Obično se želi da okidači sadrže što manje programskog koda, tako da okidači najčešće samo pozivaju pohranjene (a najčešće i pakirane) procedure ili funkcije.
Okidač "bus_emp" ("before update statement" nad tablicom "emp" - okida se jedanput prije naredbe UPDATE) poziva (pakiranu) proceduru za čišćenje PL/SQL tablice (napomena: okidači će privremeno biti invalidni, dok se ne propusti paket koji pozivaju):
CREATE OR REPLACE TRIGGER bus_emp
BEFORE UPDATE ON emp
BEGIN
emp_closed_loop.clear_plsql_tab;
END;
/
Okidač "bir_emp" ("before insert row" - okida se jedanput za svaki uneseni redak) provjerava da li su u stupcima "empno" i "mgr" različite vrijednosti (inače javlja grešku):
CREATE OR REPLACE TRIGGER bir_emp BEFORE INSERT ON emp FOR EACH ROW BEGIN IF :NEW.empno = :NEW.mgr THEN RAISE_APPLICATION_ERROR (-20002, 'Djelatnik ne može biti nadređen samome sebi!'); END IF; END; /
Okidač "bur_emp" ("before update row") zabranjuje mijenjanje šifra djelatnika, zabranjuje da djelatnik bude nadređen samome sebi i poziva proceduru koja pamti redak u PL/SQL tablicu:
CREATE OR REPLACE TRIGGER bur_emp
BEFORE UPDATE ON emp
FOR EACH ROW
BEGIN
IF :NEW.empno <> :OLD.empno THEN
RAISE_APPLICATION_ERROR (-20001, 'EMPNO se ne može mijenati');
END IF;
IF :NEW.empno = :NEW.mgr THEN
RAISE_APPLICATION_ERROR
(-20002, 'Djelatnik ne može biti nadređen samome sebi!');
END IF;
IF :NEW.mgr IS NOT NULL
AND :NEW.mgr <> NVL (:OLD.mgr, 0)
THEN
emp_closed_loop.write_plsql_tab (
p_empno => :OLD.empno,
p_mgr => :NEW.mgr);
END IF;
END;
/
Okidač "aus_emp" ("after update statement" nad tablicom "emp" - okida se jedanput nakon naredbe UPDATE) poziva (pakiranu) proceduru za provjeru poslovnog pravila (ta je procedura krucijalni dio programskog koda):
10 CASE2019
CREATE OR REPLACE TRIGGER aus_emp
AFTER UPDATE ON emp
BEGIN
emp_closed_loop.test;
END;
/
Slijedi paket "emp_closed_loop", sa tri (već navedene) procedure:
CREATE OR REPLACE PACKAGE emp_closed_loop IS PROCEDURE clear_plsql_tab; PROCEDURE write_plsql_tab ( p_empno emp.empno%TYPE, p_mgr emp.mgr%TYPE); PROCEDURE test; END; /
CREATE OR REPLACE PACKAGE BODY emp_closed_loop IS TYPE rec_t IS RECORD ( empno emp.empno%TYPE, mgr emp.mgr%TYPE);
TYPE plsql_tab_t IS TABLE OF rec_t INDEX BY BINARY_INTEGER;
m_plsql_tab plsql_tab_t; m_rows BINARY_INTEGER;
PROCEDURE clear_plsql_tab IS BEGIN m_rows := 0; END;
PROCEDURE write_plsql_tab ( p_empno emp.empno%TYPE, p_mgr emp.mgr%TYPE) IS BEGIN m_rows := m_rows + 1; m_plsql_tab (m_rows).empno := p_empno; m_plsql_tab (m_rows).mgr := p_mgr; END;
PROCEDURE test IS l_mgr emp.mgr%TYPE; l_empno emp.empno%TYPE; BEGIN FOR i IN 1..m_rows LOOP l_empno := m_plsql_tab (i).empno; l_mgr := m_plsql_tab (i).mgr;
WHILE l_mgr IS NOT NULL LOOP SELECT mgr INTO l_mgr FROM emp WHERE empno = l_mgr;
IF l_mgr = l_empno THEN RAISE_APPLICATION_ERROR (-20003, 'Greška - zatvorena petlja!'); END IF; END LOOP; END LOOP; END;
END emp_closed_loop; /
Vidljivo je da procedura "test" čita tablicu "emp", pa tu proceduru nije moguće pozvati u "row" okidaču "bur_emp", već se to može napraviti samo u "statement" okidaču "aus_emp". Procedura "test" mogla se napisati i drugačije (konciznije), tako
CASE2019 11
da se koristi klauzula CONNECT BY naredbe SELECT. Međutim, u nastavku će se dograđivati postojeća verzija bez klauzule CONNECT BY. Sada se može testirati rješenje. Ako se nad početnim podacima primijeni sljedeća UPDATE naredbu, dobija se poruka o grešci (i to je u redu):
UPDATE emp SET mgr = 4 WHERE empno = 1; ERROR at line 1: ORA-20003: Greška - zatvorena petlja! …
Slika 2. Rješenje radi dobro u jednokorisničkom radu – ne dopušta petlju
Nažalost, navedeno rješenje radi dobro samo u jednokorisničkom radu! U višekorisničkome radu (ili, što je isto, u jednokorisničkom radu u kojem korisnik ima više sesija baze), može se desiti greška, kao u sljedećem primjeru:
-- 1. SESIJA UPDATE emp SET mgr = 3 WHERE empno = 2;
Slika 3. Naredba u prvoj sesiji je prošla i to je u redu
-- 2. SESIJA
UPDATE emp SET mgr = 2 WHERE empno = 3;
Slika 4. Prošla je i naredba u drugoj sesiji – to nije u redu
Dakle, obje naredbe su prošle i dobila se zatvorena petlja!
Slika 5. Dobila se zatvorena petlja
12 CASE2019
4. SPREČAVANJA POJAVE PETLJE U HIJERARHIJSKOJ STRUKTURI PODATAKA U VIŠEKORISNIČKOM RADU, POMOĆU AUTONOMNE TRANSAKCIJE I POMOĆU SIMULACIJE "ROLLBACK TO SAVEPOINT" U OKIDAČU BAZE
Glavna ideja za sprečavanje pojave petlje u višekorisničkom radu je da se, istovremeno dok se provjerava da li je došlo do petlje, gleda da li je tekući redak (tj. redak koji se trenutačno provjerava) zaključan. Ako je zaključan, može se pretpostaviti da bi moglo doći do zatvorene petlje, te javiti grešku. Međutim, kako provjeriti da li je redak (koji provjeravamo) zaključan? Ako se za tu namjenu koristi SELECT FOR UPDATE, zaključat će se redak sve do kraja transakcije, zato što se u okidaču Oracle baze ne može koristiti naredbu ROLLBACK TO SAVEPOINT (napomena: ovo ograničenje, kao ni ograničenje vezano za mutirajuće tablice, nije mana Oracle baze, već prednost, jer ta ograničenja sprečavaju da dođe do programskih grešaka koje bi se vrlo teško mogle otkriti). No, ako redak ostane zaključan sve do kraja transakcije, to će spriječiti druge da rade sa takvim retkom, što je neprihvatljivo.
Budući da od verzije 8i Oracle baza podržava autonomnu transakciju, može se razmišljati da se ona primijeni za rješenje problema zaključavanja. Naime, u autonomnoj transakciji može se koristiti ROLLBACK (zapravo, autonomna transakcija i mora na kraju imati ROLLBACK ili COMMIT). U tijelo paketa "emp_closed_loop" dodat će se nova autonomna procedura "test_lock":
PROCEDURE test_lock (p_mgr emp.mgr%TYPE) IS PRAGMA AUTONOMOUS_TRANSACTION; l_dummy NUMBER; BEGIN SELECT 1 INTO l_dummy
FROM emp WHERE empno = p_mgr FOR UPDATE NOWAIT; ROLLBACK; EXCEPTION WHEN OTHERS THEN IF SQLCODE = -54 THEN RAISE_APPLICATION_ERROR (-20004, 'Greška - moguća zatvorena petlja!'); ELSE
RAISE; END IF; END;
Nova procedura pozvat će se iz mijenjane procedure "test":
PROCEDURE test IS l_mgr emp.mgr%TYPE; l_empno emp.empno%TYPE; BEGIN FOR i IN 1..m_rows LOOP l_empno := m_plsql_tab (i).empno; l_mgr := m_plsql_tab (i).mgr;
WHILE l_mgr IS NOT NULL LOOP test_lock (l_mgr);
SELECT mgr INTO l_mgr FROM emp WHERE empno = l_mgr;
IF l_mgr = l_empno THEN RAISE_APPLICATION_ERROR
(-20003, 'Greška - zatvorena petlja!'); END IF; END LOOP; END LOOP; END;
Naredbe koje su uzrokovale grešku u prethodnoj točci sada neće uspjeti, jer će baza upozoriti da bi moglo doći do petlje ("moguća greška" a ne "sigurna greška", jer to što je redak zaključan ne znači da bi do greške sigurno došlo):
-- 1. SESIJA UPDATE emp SET mgr = 3 WHERE empno = 2;
-- 2. SESIJA UPDATE emp SET mgr = 2 WHERE empno = 3; ERROR at line 1: ORA-20004: Greška - moguća zatvorena petlja! …
CASE2019 13
Nažalost, rješenje sa autonomnom transakcijom može javiti dosta lažnih grešaka (false negative), zato što su autonomnoj transakciji (baš zato što je autonomna, tj. nezavisna od "glavne" transakcije) zaključani oni redovi koje je zaključala "glavna" transakcija. Zato autonomna procedura "zaključuje" da je došlo do zatvorene petlje i onda kad je očito da nije došlo do zatvorene petlje. Evo takvog slučaja, u kojem autonomna transakcija "pogrešno zaključuje":
-- dvije UPDATE naredbe u istoj sesiji UPDATE emp SET mgr = 2 WHERE empno = 6;
UPDATE emp SET mgr = 6 WHERE empno = 7; ERROR at line 1: ORA-20004: Greška - moguća zatvorena petlja! …
Iako bi bilo sasvim u redu da djelatnik broj 6 postane (direktno) nadređen djelatniku 7, druga naredba UPDATE javlja grešku zato jer autonomna procedura "test_lock" nalazi da je djelatnik 6 zaključan (zaključala ga je "glavna" transakcija, kroz prvu naredbu UPDATE).
Međutim, našli smo da je u Oracle bazi moguće simulirati SAVEPOINT / ROLLBACK TO SAVEPOINT naredbe u okidaču baze, primjenom trik rješenja. Rješenje se temelji na sljedećem: ako se poziva udaljena procedura (pomoću database linka) i ako se u njoj desi neobrađena greška, njeni se efekti u cijelosti poništavaju (za razliku od lokalne procedure). Istina, udaljena procedura nije potrebna, ali zato se radi kvazi-udaljena procedura, koristeći "lokalni" database link (link baze na sebe samu):
CREATE DATABASE LINK local_db_link CONNECT TO scott IDENTIFIED BY tiger USING 'local_alias' -- alias na lokalnu bazu /
Ova simulacija se još u nečemu ponaša kao "pravi" ROLLBACK TO SAVEPOINT. Naime, ako druga transakcija pokuša zaključati redak koji je već zaključala prva transakcija, i ako prva transakcija otključa taj redak sa ROLLBACK TO SAVEPOINT, redak i dalje ostaje zaključan za drugu transakciju (međutim, neka treća transakcija bi sad mogla bez problema zaključati otključani redak).
Sada se može mijenjati paket "emp_closed_loop". U odnosu na prethodnu verziju, paket sada ima proceduru "test_lock" navedenu (i) u specifikaciji, zato jer se procedura "test_lock" poziva iz procedure "test" kao udaljena procedura. Procedura "test_lock" koristi naredbu "RAISE_APPLICATION_ERROR (-20999, ...)" (koju procedura "test" ignorira, tj. ne smatra ju greškom), da bi otključala redak koji je prethodno zaključala (sa SELECT ... FOR UPDATE):
CREATE OR REPLACE PACKAGE emp_closed_loop IS PROCEDURE clear_plsql_tab; PROCEDURE write_plsql_tab ( p_empno emp.empno%TYPE, p_mgr emp.mgr%TYPE); PROCEDURE test; PROCEDURE test_lock (p_mgr emp.mgr%TYPE); END emp_closed_loop; /
CREATE OR REPLACE PACKAGE BODY emp_closed_loop IS
... kao prije, osim procedura TEST i TEST_LOCK ...
PROCEDURE test IS l_mgr emp.mgr%TYPE; l_empno emp.empno%TYPE; BEGIN FOR i IN 1..m_rows LOOP l_empno := m_plsql_tab (i).empno; l_mgr := m_plsql_tab (i).mgr;
WHILE l_mgr IS NOT NULL LOOP BEGIN emp_closed_loop.test_lock@local_db_link (l_mgr); EXCEPTION WHEN OTHERS THEN IF SQLCODE = -20999 THEN NULL; ELSE RAISE; END IF; END;
SELECT mgr INTO l_mgr FROM emp WHERE empno = l_mgr;
14 CASE2019
IF l_mgr = l_empno THEN RAISE_APPLICATION_ERROR (-20004, 'Greška - zatvorena petlja!'); END IF; END LOOP; END LOOP; END;
PROCEDURE test_lock (p_mgr emp.mgr%TYPE) IS l_dummy NUMBER; BEGIN SELECT 1 INTO l_dummy FROM emp WHERE empno = p_mgr FOR UPDATE NOWAIT;
RAISE_APPLICATION_ERROR (-20999, 'Nije važno'); EXCEPTION WHEN OTHERS THEN -- resource busy and acquire with NOWAIT specified IF SQLCODE = -54 THEN RAISE_APPLICATION_ERROR (-20004,'Greška - moguća zatvorena petlja!'); ELSE RAISE; END IF; END; END emp_closed_loop; /
No, mora se reći da i ovo rješenje ponekad može javiti "lažnu uzbunu", tj. javiti da je (možda) došlo do petlje, iako do toga nije došlo, kao npr. u primjeru:
-- 1.SESIJA UPDATE emp SET mgr = 6 WHERE empno = 2;
-- 2.SESIJA UPDATE emp SET mgr = 5 WHERE empno = 7; ERROR at line 1: ORA-20004: Greška - moguća zatvorena petlja!…
Nažalost, ovakva "lažna uzbuna" ne može se spriječiti, jer sesija baze ne može točno "znati" što druge sesije baze rade.
5. TESTIRANJE KONKURENTNIH TRANSAKCIJA POMOĆU JAVA EXECUTORA
Za potrebe testiranja, tablicu EMP ćemo napuniti sa 1000 redaka, na ovaj način:
1 korijenski redak (šifra 0)
njegovih 9 podređenih
njihovih 90 podređenih (po 10 za svakog)
njihovih 900 podređenih (po 10 za svakog).
-- 0
insert into emp (empno, ename, mgr) values (0, 'EMP 0', null);
-- 1-9
declare
ename varchar2(20);
begin
for j in 1..9 loop
ename := 'EMP ' || j;
insert into emp (empno, ename, mgr) values (j, ename, 0);
end loop;
end;
/
-- 10-99
declare
empno number(4);
ename varchar2(20);
begin
for i in 1..9 loop
for j in 0..9 loop
empno := i * 10 + j;
CASE2019 15
ename := 'EMP ' || empno;
insert into emp (empno, ename, mgr) values (empno, ename, i);
end loop;
end loop;
end;
/
-- 100-999
declare
empno number(4);
ename varchar2(20);
begin
for i in 10..99 loop
for j in 0..9 loop
empno := i * 10 + j;
ename := 'EMP ' || empno;
insert into emp (empno, ename, mgr) values (empno, ename, i);
end loop;
end loop;
end;
/
commit;
Testiranje ćemo raditi pomoću Java programa (u nastavku) koji ima sljedeće ulazne parametre:
brDretvi: broj Java dretvi (default je 10)
cekanje: vrijeme namjernog čekanja u pojedinoj dretvi (default je 1 sekunda), kako bi se simuliralo kašnjenje kod rada korisnika
brIteracija: broj ponavljanja testa (default je 1).
Glavna metoda main poziva metodu testiraj, u kojoj se kreira objekt (connectionTask) anonimne klase (podklasa od Runnable). U (nadjačanoj) metodi run dvaput se poziva metoda slucajni_broj, koja generira slučajne emp i mgr (brojeve između 200 i 300). Na temelju toga se radi UPDATE jednog retka i COMMIT. Kreira se fiskni broj executora sa newFixedThreadPool(brDretvi) i svakom se daje njegov zadatak sa executorService.submit(connectionTask).
import java.sql.*;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import static java.util.concurrent.TimeUnit.MINUTES;
public class TestEmp {
static int brDretvi = 10;
static int cekanje = 1; // 1 sekunda
static int brIteracija = 1;
public static void main(String[] args) {
if (args.length > 0) {
brDretvi = Integer.parseInt(args[0]);
};
if (args.length > 1) {
cekanje = Integer.parseInt(args[1]) * 1000;
};
if (args.length > 2) {
brIteracija = Integer.parseInt(args[2]);
};
for (int i = 1; i <= brIteracija; i++) {
testiraj();
};
};
private static void testiraj() {
String url = "jdbc:oracle:thin:emp/emp@localhost:1521:ORCL";
Runnable connectionTask = new Runnable() {
public void run() {
try (Connection con = DriverManager.getConnection(url);) {
con.setAutoCommit(false);
16 CASE2019
String query;
PreparedStatement stm;
// ORA-01436: CONNECT BY loop in user data
query =
"select distinct 0 from emp connect by prior empno = mgr";
stm = con.prepareStatement(query);
stm.executeQuery();
// s donjim postavkama dolazi do zatvorene petlje
// kod nesigurne verzije paketa
int mgr = slucajni_broj (200, 300);
// nije pogodno: slucajni_broj (0, 999);
int empno = slucajni_broj (200, 300);
query = "update emp set mgr = ? where empno = ?";
stm = con.prepareStatement(query);
stm.setInt(1, mgr);
stm.setInt(2, empno);
stm.execute();
Thread.sleep(cekanje);
con.commit();
System.out.println("Empno:" + empno + " Mgr:" + mgr);
} catch (Exception e) {
// System.out.println(e.toString().substring(34, 67));
System.out.println(e.toString());
}
}
};
try {
ExecutorService executorService =
Executors.newFixedThreadPool(brDretvi);
for (int j = 1; j <= brDretvi; j++) {
executorService.submit(connectionTask);
}
executorService.shutdown();
executorService.awaitTermination(30, MINUTES);
} catch (Exception e) {
System.out.println(e.toString());
}
};
private static int slucajni_broj (int min_p, int max_p) {
/*
Generira slučajni cijeli broj od min (uključujući) do max (uključujući).
Math.random vraća vrijednost od 0 (uključujući) do 1 (isključujući).
Zato se množi s max_p i zbraja min_p. Vraća se u cijeli broj.
*/
int broj = min_p + (int) (Math.random() * (max_p - min_p + 1));
return broj;
}
}
Testiranje možemo raditi npr. ovako – pokreće se 100 Java dretvi (time i 100 paralelnih transakcija), sa vremenom čekanja od 2 sekunde u transakciji, u 5 iteracija testiranja:
java –cp ”*”; TestEmp 100 2 5
Pokazuje se da nesigurna varijanta paketa emp_closed_loop vrlo brzo dovodi do greške. Sigurne (dvije) varijante tog paketa ne dovode do greške niti nakon puno ponavljanja. Naravno, to nije matematički dokaz da su to zaista sigurna varijante. Kao i uvijek, testiranjem se može dokazati da program ne radi dobro, ali se testiranjem ne može dokazati da program (uvijek) radi dobro.
6. TESTIRANJE KONKURENTNIH TRANSAKCIJA POMOĆU JOBOVA NA BAZI
PL/SQL paket (u nastavku) ima javne (public) procedure:
pokreni: parametar je broj jobova (default je 10)
zadatak: procedura je javna zato jer se poziva iz joba, pa mora biti navedena u specifikaciji paketa (inače bi se javilo: ORA-06576: not a valid function or procedure name).
CASE2019 17
U proceduri pokreni kreira se i pokreće zadani broj jobova. Kod poziva DBMS_SCHEDULER.RUN_JOB parametar use_current_session postavlja se na FALSE (default je TRUE), kako bi svaki job radio u posebnoj sesiji baze. Procedura zadatak (slično ekvivalentnom dijelu koda u Java programu) postavlja upit kojim se utvrđuje da li je došlo do petlje, a onda (ako nije došlo do petlje) slučajno generira šifru za mgr i empno, radi UPDATE, čeka jednu sekundu, i daje COMMIT (ovdje nema parametra za broj iteracija testiranja).
-- kao SYS
GRANT CREATE JOB TO emp
/
CREATE OR REPLACE PACKAGE test_emp IS
PROCEDURE pokreni (br_jobova_p NUMBER DEFAULT 10);
PROCEDURE zadatak;
END;
/
CREATE OR REPLACE PACKAGE BODY test_emp IS
PROCEDURE pokreni (br_jobova_p NUMBER DEFAULT 10) IS
BEGIN
FOR j IN 1 .. br_jobova_p LOOP
DBMS_SCHEDULER.CREATE_JOB (
job_name => 'TEST_EMP_' || j,
job_type => 'STORED_PROCEDURE',
job_action => 'TEST_EMP.ZADATAK',
enabled => TRUE,
auto_drop => TRUE -- default
);
DBMS_SCHEDULER.RUN_JOB (
job_name => 'TEST_EMP_' || j,
use_current_session => FALSE
);
END LOOP;
END;
PROCEDURE zadatak IS
mgr_l NUMBER (4);
empno_l NUMBER (4);
dummy_l NUMBER (1);
BEGIN
-- može se desiti ORA-01436: CONNECT BY loop in user data
SELECT DISTINCT 0 INTO dummy_l
FROM emp
CONNECT BY PRIOR empno = mgr;
mgr_l := TRUNC (DBMS_RANDOM.VALUE (200, 301));
empno_l := TRUNC (DBMS_RANDOM.VALUE (200, 301));
UPDATE emp
SET mgr = mgr_l
WHERE empno = empno_l;
DBMS_LOCK.SLEEP (1);
COMMIT;
END;
END;
/
-- pokretanje testiranja
exec test_emp.pokreni (50)
-- provjera da li su jobovi završili
select job_name
from user_scheduler_jobs
order by 1;
-- da li je došlo do petlje
select distinct 0
from emp.emp
connect by prior empno = mgr;
-- detalji rada jobova – prikaz grešaka
18 CASE2019
select error#, count(*)
from USER_SCHEDULER_JOB_RUN_DETAILS
where job_name like 'TEST_EMP_%'
group by error#
order by 1;
7. ZAKLJUČAK
Prvo smo se ukratko podsjetili na dvije varijante SQL hijerarhijskih upita – Oracle varijantu (koju je Oracle baza imala od početka) i ANSI varijantu (moguća od Oracle baze 11.2). Zatim smo ponovili prezentaciju sa CASE 16 (2004.), koja prikazuje tri rješenja za sprečavanje zatvorene petlje u hijerarhijskoj strukturi (tablica u bazi podataka). Zapravo, prvo rješenje je nesigurno - radi dobro samo u jednokorisničkom radu. Za preostala dva rješenja vjerujemo (nemamo formalnog dokaza) da rade dobro i u višekorisničkom radu.
Na tom primjeru prikazali smo testiranje konkurentnih transakcija pomoću Java Executora Pokazalo se da nesigurna varijanta vrlo brzo uzrokuje petlju u podacima. Ostale dvije varijante su dobro radile. Zatim smo prikazali testiranje konkurentnih transakcija pomoću jobova na bazi (DBMS_SCHEDULER paketa). To je testiranje dalo iste rezultate kao i prethodno, što je i očekivano, jer oba testiranja rade na sličan način, samo se za paralelno izvršavanje u prvom slučaju koriste Java dretve, a drugom slučaju jobovi na bazi.
Naravno, postoje i bolji načini testiranja konkurentnih transakcija – pomoću gotovih alata namijenjenih tome, od kojih su neki (možda) i besplatni. No, nije loše, barem iz edukativnih razloga, probati testiranje (i) pomoću vlastitih, jednostavnih programa.
Literatura:
1 Boyarsky, J., Selikoff, S. (2015): OCP: Oracle Certified Professional Java SE 8 Programmer II Study Guide: Exam 1Z0-809, Sybex
2 Kyte, T. (2009): Expert Oracle Database Architecture, Apress
3 Oracle priručnik (2010): Oracle Database Administrator's Guide 11g Release 2
4 Oracle priručnik (2010): Oracle Database Advanced Application Developer's Guide 11g Release 2
5 Oracle priručnik (2013): Oracle Database Development Guide 12c Release 1
6 Oracle priručnik (2013): Oracle Database JDBC Developer’s Guide 12c Release 1
7 Sierra K., Bates B. (2015):OCA/OCP Java SE 7 Programmer I & II Study Guide, McGraw-Hill Education
Podaci o autoru:
Zlatko Sirotić, univ.spec.inf.
ISTRA TECH d.o.o., Pula
e-mail: [email protected]
Autor radi oko 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, 2011.) kao vanjski suradnik, uglavnom na kolegijima Baze podataka 2 i Informatički praktikum 1.
CASE2019 19
SMJERNICE ZA MIGRACIJU KOMPONENTI POSLOVNOG SUSTAVA NA IAAS CLOUD OKRUŽENJE
Marko Havoić, dr.sc. Marin Kaluža, Sabrina Šuman
SAŽETAK
Postoji puno različitih aspekata koje je potrebno razmotriti prilikom odabira, evaluacije i planiranja migracije na IaaS cloud okruženje. Ove smjernice su namijenjene za vođenje kroz taj proces. Proces započinje sa odlukom o migraciji i odobrenjem uprave. U daljnjim koracima analiziraju se različiti faktori trenutnog sustava, te različite opcije dostupne kod Cloud pružatelja usluga. Važno je prepoznati sve, ili koliko je to moguće, faktore koji će voditi ka uspješnoj migraciji. Prikazuju se faze, procesi i aktivnosti koje će pomoći u planiranju migracije uz okviran popis dokumentacije koja ih prati.
ABSTRACT
There are many different aspects that need to be considered when selecting, evaluating, and planning migration to the IaaS cloud environment. These guidelines are intended for guidance through the that process. The process begins with the decision to migrate and the approval of the management board. Next steps are an analysis of different factors of current system, and an analysis of different options of available cloud providers. It is important to recognize all or as many as possible factors that lead to successful migration. Stages, processes, and activities that help in migration planning, along with a list of documentation that accompanies them, are shown in the paper.
1. UVOD
Cloud (Oblačno računalstvo ili računalstvo u oblaku) jedno je od područja IT industrije koje se nezaustavljivo razvija zadnjih godina. Danas gotovo svi izravno ili neizravno imaju doticaje sa nekom vrstom Cloud-a. Poduzeća svih veličina preoblikuju svoje klasične arhitekture u neku vrstu Cloud arhitekture. Pri tome se nameće problem što je potrebno sagledati za potrebe migracije poslovnog sustava iz lokalne na Cloud platformu. Odgovore možemo pronaći u bespućima Interneta ili kontaktirajući različite pružatelje Cloud usluga kojih u današnje vrijeme ima na pretek. U radu će se analizirati problem migracije klasične lokalne arhitekture poslovnog sustava na IaaS (Infrastruktura kao usluga) arhitekturu.
Svrha rada je definirati poznat, potpun, siguran i točan postupak migracije poslovnog sustava na Cloud platformu, pa će se dati odgovori na pitanja: Kako pristupiti migraciji sustava? Koje aspekte je potrebno sagledati u postupku migracije? Kojim smjernicama se voditi kod planiranja i tijekom migracije?
Cilj rada je definirati kriterije koje je potrebno ispitati i izvršiti, te iz definiranih kriterija pokazati dijagram aktivnosti i slijed dokumentacije procesa migracije.
2. PRETHODNA ISTRAŽIVANJA
Metoda istraživanja i kreiranja konačnog skupa kriterija uključivala je detaljnu analizu desetak primjera smjernica ili primjera iz poslovne prakse. Kao podloga za rad su se prvenstveno koristile smjernice i prakse koje se spominju u više izvora:
a) izvori poslovne prakse – „A Case Study of Migrating an Enterprise IT System to IaaS“ [1] - provedena studija migracije poduzeća na Amazon platformu. Unatoč financijskim i tehnološkim dobitima od migracije se privremeno odustalo radi psiho-socioloških razloga. Pokazane su smjernice i primjeri na što treba obratiti pažnju prilikom planiranja migracije.
b) smjernice za migraciju od različitih autora – Microsoft [2], Cisco [3], EdTech magazin [4], CIO časopis [5], AgileIT [6], Teledata [7]. Svaki izvor sadrži smjernice za postupke i procese koji se provode u pripremi, tijekom i nakon migracije na IaaS okolinu. Provjerene su sličnosti i različitosti u njima.
c) najvažniji elementi na koje treba paziti da se ne ugrozi migracija – Pentalog [8], Saviant [9], Charles IT [10] prikazuju najčešće greške koje se pojavljuju tijekom procesa migracije.
3. METODIKA RADA
Metodom analize dostupnih smjernica drugih autora i analize primjera iz poslovne prakse napravljena je sinteza te su definirane smjernice za migraciju. Prvi korak je prepoznavanje faza procesa migracije tj. definiranje istih. Potom slijedi sagledavanje svake faze i identifikacija procesa od kojih se sastoji, njihov opis te na posljetku prepoznavanje i analiza aktivnosti u svakom pojedinom procesu. Osim identificiranja i opisa navedenih faza, procesa i aktivnosti nastojati će se prikazati njihov kronološki slijed odnosno interakciju pojedinih procesa.
20 CASE2019
3.1 Faze procesa migracije
Prvi korak je prepoznavanje tj. definiranje faza migracije. Analizom primjera navedenih u poglavlju prethodna istraživanja prepoznate su sljedeće faze:
1 Planiranje migracije
2 Analiza sustava
3 Analiza Cloud rješenja
4 Odabir dobavljača
5 Planiranje procesa migracije
6 Testiranje
7 Migracija
8 Završetak migracije
9 Upravljanje IaaS infrastrukturom
U nastavku se prolazi kroz navedene faze te se objašnjavaju procesi i aktivnosti u svakoj od njih.
Planiranje migracije
Prvi korak kod planiranja migracije je odluka o migraciji. Odluku donosi vrhovno tijelo organizacije. U današnje vrijeme informacijske tehnologije sastavni su dio organizacije i svaka veća promjena nad informacijskim sustavom mijenja i način funkcioniranja organizacije ili utječe na njezin rad. Stoga delikatan proces kao što je migracija zahtjeva podršku svih struktura u organizaciji, a da bi se to osiguralo potrebna je podrška vrhovnog tijela što je najčešće uprava. Takvu podršku kao i sve ostalo što se radi tijekom procesa potrebno je dokumentirati (plan o migraciji).
Osim podrške potrebno je od istog tijela ishoditi odobrenje za potrebne resurse. Tako da se ova faza sastoji još od planiranja resursa te definiranja okvirnih troškova. U ovoj se fazi radi o projekciji istih kako bi se pokrenuo projekt jer tek kroz naredne faze će se moći znati ukupne troškove. Ono što je bitno da se u ovoj fazi osiguraju potrebni resursi za pokretanje projekta migracije kao što su ljudski resursi, vrijeme i novac.
Analiza sustava
Kada se osiguraju potrebni resursi za početak projekta migracije sljedeći korak koji se radi je analiza trenutnog informacijskog sustava i njegove arhitekture.
Interna IT analiza je najčešće zadatak postojećeg internog odjela informatike no ukoliko je taj zadatak preopširan ili interni odjel nema dovoljno kompetencije za provođenje istog ovo je pravo vrijeme za angažiranje konzultanata (pojedinaca ili tvrtke) koji će sudjelovati u provođenju interne analize.
Dijelovi sustava na koje posebno obraćamo pažnju su:
a) hardver
- broj mašina (posebno fizičkih, posebno virtualnih ako postoje), njihovu konfiguraciju (količina radne memorije, broj
procesora, broj jezgri po procesoru, diskovni prostor, vrstu diskovnog prostora, mrežne kartice, grafičke kartice).
- ukoliko postoje dedicirane (namjenske) mašine koje nije moguće virtualizirati odlučiti bili se iste ostavilo na lokaciji ili
postoji opcija za preseljenje. Odnosno možda je moguća nadogradnja tog dijela sustava mašinama tj. potencijalno
novim softverom kojeg je moguće koristit u Cloud okruženju
Izrađuje se dokument sa detaljnim specifikacijama istih kako bi se kasnije temeljem tog dokumenta izradila finalna specifikacija trenutnog sustava koja je ujedno podloga za traženje ponuda.
b) Softver
- prvenstveno se gleda licenciranje i hardverski zahtjeve. Kod licenciranja dali je moguće preseljenje licence, dali se
mogu uzeti nove licence, dali uopće postoje licence koje se mogu koristiti u cloud okruženju. Kod hardverskih
zahtjeva se gleda dali su isti specifični i mogu li se takvi replicirati u Cloud okruženju.
- Možda je sada pravo vrijeme za nadogradnju softvera kojeg bi se teško ili nikako mogao migrirati u Cloud okruženje.
Kao i kod analize hardvera izrađuje se specifikacija koja će biti dio finalne specifikacije sustava.
c) Servisi
- osim kompatibilnosti softvera i hardvera prilikom preseljenja servisa treba voditi računa o mrežnima zahtjevima istih
koji mogu biti specifični.
d) Mreža
- kod mreža treba obratiti ponajprije pažnju na propusnost mreže (bandwith) te latencije. Potrebno je imati na umu
latencije i propusnost od klijenata sve do servera i obratno. Prelaskom na Cloud vjerojatno će se dio prometa koji je
do sada tekao različitim mrežama koncentrirati na jednu vezu, onu prema Cloud, pa treba voditi računa o tome.
- također treba voditi računa ako postoje specifični zahtjevi kao što su razne vrste VPN*-ova i razne vrste
segmentacije mreže (VLAN†-ovi) koji će sada morati biti usmjereni kroz jedan link.
- topologija mreže je također iznimno bitna jer ako postoje uredi koji su povezani sa središnjicom odnosno lokacijom na kojoj se sada nalaze serveri treba računati na dodatna kašnjenja ako u novoj okolini moraju još dodatnim linkom iz središnjice pristupati novom Cloud sustavu. Moguće rješenje je i direktno povezivanje istih sa Cloudom odnosno
* VPN (Virtual private network) -Virtualna privatna mreža
† VLAN (Virtual Local Area Network) -Virtualna lokalna mreža
CASE2019 21
prebacivanje centralnog čvorišta na Cloud no to ovisi o potrebi za kontrolom i mogućnostima koje pruža Cloud okruženje.
Ukoliko ne postoji izrađuje se detaljna shema i opis trenutne mreže i njezinih dijelova.
e) Korisnici
- sagledati i analizirati korisnike i njihovo korištenje informacijskog sustava. Obratiti pažnju na moguće anomalije koje
do sada nisu uočene, a mogle bi imati utjecaj na planiranu migraciju.
f) Sigurnost
- Napraviti detaljnu specifikaciju sigurnosnih mjera koje se provode sada kako bi se iste mogle provoditi i nakon
migracije sustava (primjerice serveri koji su iza vatrozida sa specifičnim postavkama (web server -javne IP adrese)
moraju se i u Cloudu nalaziti iza istog.
- Potrebno je napraviti i procjenu rizika preseljenja pojedinih osjetljivih podataka kako bi se isto odvilo adekvatno i
osigurale potrebne zaštite istih tokom i poslije preseljenja
Jednom kada se sagledaju svi čimbenici trenutnog informacijskog sustava koji se dokumentiraju te se izrađuje specifikacija trenutnog sustava temeljem koje je moguće izraditi potencijalnu specifikaciju budećeg IaaS rješenja. Potom se može krenuti u analizu mogućih Cloud okruženja.
Analiza cloud rješenja
Prvi korak analize mogućih Cloud rješenja je pronalazak pružatelja usluga. U današnje vrijeme ih ima mnogo po različitim cijenama i uvjetima. Pa se u ovom koraku navode najvažnije karakteristike koje treba promatrati kod pronalaska i odabira budućeg pružatelja usluga.
Lokacija - prvo o čemu treba voditi brigu je lokacija. Pogotovo ako se radi o organizacijama koje se bave financijskim uslugama ili drugim uslugama koje sadrže osjetljive informacije. U tome su slučaju najčešće raznim propisima ograničene lokacije na kojima se može nalaziti informacijski sustav.
Informiranje o dostupnim pružateljima - Kada eliminiramo problem lokacije može se krenuti u potragu dostupnih pružatelja usluga. Uspostave se kontakti i zatraže inicijalne ponude prema specifikacijama koje su definirane u postupku analize sustava.
Analiza ponuda - Po dobivanju odgovara na upit može se krenuti u postupak analize ponuda.
Proces odlučivanja - Izdvajaju se prihvatljive ponude tj. one koje zadovoljavaju osnovne potrebe te se kontakt tih pružatelja usluga.
U daljnjem procesu odlučivanja analizirani su slijedeći parametri:
a) Platforma - Postoje razne platforme za virtualizaciju koje se mogu pronaći na sljedećoj poveznici
(https://en.wikipedia.org/wiki/Comparison_of_platform_virtualization_software ) cilj je odabrati onu koja troškovima i zahtjevima najviše odgovara. Sa time da bi naglasak trebao biti na zahtjeve dok bi troškovi trebali ostati u drugome planu.
b) Mogućnosti - Odnosi se na fleksibilnost pružatelja usluga u provođenju specifičnih zahtjeva koji se stavljaju pred njih. Dali se
isključivo drže klasičnog modela ili su spremni izaći u susret kada su u pitanju specifični zahtjevi. Te dali uopće imaju tehničke mogućnosti za ispunjavanje takvih specifičnih zahtjeva.
c) Jamstva i kompetencije - Koja jamstva budući pružatelj usluga može ponuditi. Ista se definiraju ugovorom o dostupnosti usluga (SLA
‡) i drugim
ugovorima o uslugama.
d) Dosadašnja iskustva (reference) - Ukoliko pružatelj usluga ima prijašnjih iskustava sa ovakvim ili sličnim sustavima to može biti prevaga za odabir istog.
Jer vjerojatno zna na koje probleme je moguće naići te njihova potencijalna rješenja.
Odabir - Skupivši navedene informacije od svih potencijalni pružatelja usluga može se krenuti u odabir pružatelja. Kao i sve procese i postupke do sada potrebno je dokumentirati.
Odabir dobavljača
Temeljem rezultata prethodnog procesa izvrši se formalni odabir pružatelja usluga. Kontaktira se istog te zatraži formalna ponuda. Eventualno se traži od dobavljača dodatna jamstva ako su potrebna. Te u ovome trenutku se može vratit na prvi korak gdje se radio okvirni troškovni plan migracije te ga dopuniti novim podacima. Temeljem istih može se donijeti finalna verzija plana migracije sa uključenim svim troškovima koji po završetku migracije ne bi smjeli previše odstupati od sada definiranih.
Kada su isplanirani resursi, odabrano pružatelj, sve do sada dokumentirano i podržano od strane najviših instanci u organizaciji može se krenuti na planiranje same migracije sustava.
Planiranje migracije
Za planiranje same migracije bi trebalo započeti definiranjem hodograma koji se tijekom faze procesa planiranje migracije dopunjava. Hodogram će ujedno biti i ključan dokument kojim se prati daljnji tijek migracije. To može biti jednostavna lista u tabličnom kalkulatoru u gdje se označavaju obavljeni poslovi i poslovi koje treba obaviti. Hodogram će ujedno i biti podloga za finalni dokument predaje/puštanja novog sustava u rad.
Slijedi definiranje migracijskog procesa koje se radi u suradnji sa odabranim pružateljem usluga. Nastoji se definirati korake i postupke migracije do najsitnijih detalja. U ovome trenutku su najbitniji podaci koji se dobe u fazi analize sustava
‡ SLA (Service Level Agreement) je dio ugovora o pružanju usluga
22 CASE2019
te podaci koji dobivaju od našeg dobavljača kako bi se izbjegli potencijalni problemi i na vrijeme otklonili nedostaci. Popunjava se detaljima ranije definirani hodogram i radi se detaljna lista sa slijedom migracije koja se popunjava ovisno o izvršenosti pojedinog zadatka. Kada se sve definira može se krenuti u pripremu cloud okoline. Tokom pripreme ako se naiđe na nove probleme, izazove ili promjene isti se unose u hodogram.
Testiranje
U fazu testiranja kreće se u sklopu faze planiranja migracije tj. procesa pripreme Cloud okoline. Gdje se testira svaki element sa liste slijeda migracije. Najčešće se testira dostupnost pojedinog segmenta sustava i ispravnost odvijanja procesa. Sve se dokumentira te ovaj dokument ujedno služi za izradu dokumenta plana budućih testiranja. Testiraju se elementi sustava te sustav kao cjelina višekratno tokom pripreme okoline. Faza testiranja je najčešće i trebala bi biti paralelni proces od samog početka pripreme nove okoline pa sve do puštanja iste u rad pa i tokom rada nove okoline.
Migracija
Faza migracije započinje kada je migracijska okolina spremna. U idealnom scenariju imamo spremu okolinu istovjetnu sa produkcijom te postupak je zapravo preusmjeravanje korisnika na novu okolinu promjenom mrežnih postavki, DNS
§
zapisa i sl.
Često se neko vrijeme paralelno koriste migracijska okolina i trenutna. Kako bi se eliminirale eventualne greške i nedostaci koji nisu uočeni u prethodnim fazama. Također je moguće osim idealne migracije gdje se korisnike prebacuje sa jedne na drugu okolinu provoditi postepenu migraciju odnosno komponentu po komponentu sustava zamjenjivati novom. Ovakav oblik migracije je i najčešći u praksi jer je fleksibilniji ukoliko dođe do problema pošto će problem biti identificiran i točno će se znati kod koje komponente je zapelo.
Faza migracije završava uspješnim izvođenjem svih zadataka definiranih hodogramom i slijedom migracije. Te uspješnim testiranjem svih komponenti novog sustave te sustava kao cjeline. Po završetku se izrađuje dokument o uspješnoj migraciji. Te provjerava još jednom dali su izvršeni svi zadaci definirani u hodogramu te se zaključuje isti. Ukoliko se radi za nekog daje se isti na potpis jer je on ključni dokument koji dokazuje da je napravljeno sve što je traženo.
Završetak migracije
Po završetku faze migracije izrađuje se finalni dokument o migraciji sa svime providnim i radimo analizu svega provedenog kako bi se eventualno uočilo nešto propušteno.
Upravljanje IaaS infrastrukturom
Ova faza se zapravo proteže od trenutka odabir pružatelja usluga gdje se definiraju odgovornosti i zadatci obje strane. Nije izravno vezana za uspješnost migracije kao procesa. No vezana je za uspješnost migracije kod daljnje upotrebe novog sustava. Također je vrlo važna sa sigurnosnog aspekta upravo radi definiranih odgovornosti kako bi sada iste sproveli u procese i zadatke koje je potrebno provoditi kako bi sustav neometanu funkcionira. Rezultat procesa bi trebao biti plan budućeg upravljanja IaaS infrastrukturom.
3.2 Česte pogreške procesa migracije
U ovome poglavlju ukratko se prolazi kroz najčešće prepoznate pogreške tokom planiranja i provođenje procesa migracije:
1. Zanemarivanje postojećih i provjerenih metoda i praksi – uvijek se je potrebno osloniti na provjerene metode, proučiti uspješne primjere i prakse te svoje postupke planirati prema njima.
2. Nepotpuno ili zanemarivanje dokumentiranja faza, procesa i svega što prati migraciju. Iako postupak dokumentiranja ponekad oduzima podosta resursa bez kvalitetne dokumentacije može se zapeti kada se naleti na veći problem. Jer dokumentacija sadrži podatke gdje što i kako se odvija i zašto je to tako. Također kroz dokumentaciju često se može uočiti potencijalni problem.
3. Prevelike uštede mogu prouzročiti probleme. Informacijski sustav je jedna od ključnih dijelova u poduzeću. Zahtjeva mnogo resursa pa time možda i pruža dosta prostora za uštedu. No ukoliko se previše orijentira na uštedu u odnosu na kvalitetu moguće da će se zapravo postići kontraefekt i napraviti veći problemi koji će potom koštati više resursa nego da se krenulo sa kvalitetnijim inicijalno skupljim rješenjima.
4. Zanemarivanje ugovora kao što su ugovori o razini usluge (SLA) i slični. Pošto u migraciji na IaaS dio toga prepušta na brigu drugoj pa možda i trećoj strani potrebno je jasno definirati ugovore o uslugama. Sa prihvatljivim rokovima i jasno definiranim odgovornostima.
4. REZULTATI I DISKUSIJA
Rezultat provedenog postupka je lista sa smjernicama koja sadrži faze, postupke koji bi se trebali provoditi kod migracije klasične na IaaS infrastrukturu. Popis istih može se vidjeti u tablici 1.
Osim tablice sa popisom ranije objašnjenih postupaka i faza nastojano je definirati dijagram koji pokazuje raspored faza i koraka kronološkim slijedom. Isti se može pogledati na slici ispod.
§ DNS (Domain Name System) - Domenski sustav imena
CASE2019 23
Tablica 1 - Prikaz faza i procesa
Slika 1 Dijagramski prikaz toka procesa migracije
24 CASE2019
Važno je napomenuti da definirani kronološki redoslijed ne mora biti identičan za svaku migraciju. Kao što je napomenuto u objašnjenju pojedinih faza one se često isprepliću i imamo često paralelne procese. Osim toga moguće je da za pojedini sustav postoje unaprijed odrađeni dijelovi (procesi, dokumenti) potrebni za migraciju. Npr. postoji detaljna dokumentacija trenutnog sustava pa nije potrebna izrada nove nego se pomoću iste mogu zatražiti unaprijed ponude te time i prije definirati finalni okvirni budžet i ubrzati sam tijek migracije.
U nastavku se nalazi i slika sa popisom dokumenata spominjanih kroz faze migracije. Popis dokumenta je okviran kao i nazivi dokumenata. Svaki od navedenih dokumenata može se i vjerojatno se sastoji od više manjih cjelina. Npr. „Analiza internog sustava“ se najčešće sastoji od skupa analize pojedinih komponenti sustava. Sama količina i vrsta dokumenta najčešće ovisi o kojekakvim potrebama, zakonskim i drugim obvezama i politici organizacija koje sudjeluju u migracijskom procesu.
Slika 2 Popis dokumenata
5. ZAKLJUČAK
Informacijski sustave je ključan dio svake moderne organizacije. Zahtjeva stalno ulaganje i razvijanje. Često se javljaju nove tehnologije, novi koncepti kao što je u ovom slučaju IaaS koji omogućuje da dio brige o istom za neku cijenu prepustimo drugima. No da bi u ovom slučaju mogli iskoristi mogućnosti IaaS-a potrebno je pronaći odgovarajućeg pružatelja usluga te provesti proces migracije.
Proces migracije informacijskog sustava je često stresan i ne vodi li se ispravno može završiti katastrofom stoga je bitno kako njemu pristupiti. Ovim radom nastojalo se prikazati kako pristupiti takvom procesi i na što obratiti pažnju.
Proučeni su primjeri od nekoliko različitih poduzeća i uzeti je u obzir vlasti primjer te su temeljem toga definirane smjernice koje se mogu slijediti u procesu migracije.
Navedene smjernice su namijenjene za korištenje svima koji se upuštaju u sličan proces migracije.
CASE2019 25
Literatura:
1 Khajeh-Hosseini,A.,Greenwood,D,Sommerville,I., Cloud Migration: A Case Study of Migrating an Enterprise IT System to IaaS, IEEE 3rd International Conference on Cloud Computing, 2010., preuzeto sa https://arxiv.org/ftp/arxiv/papers/1002/1002.3492.pdf [10.12.2018]
2 Rangwala, Y., Migration checklist when moving to Azure App Service, 2018., preuzeto sa https://azure.microsoft.com/en-us/blog/migration-checklist-when-moving-to-azure-app-service/ [10.12.2018]
3 Cisco Systems, Planning the Migration of Enterprise Applications to the Cloud, 2010. preuzeto sa https://www.cisco.com/en/US/services/ps2961/ps10364/ps10370/ps11104/Migration_of_Enterprise_Apps_to_Cloud_White_Paper.pdf [10.12.2018]
4 Snyder, J., EdTech, How to Get There from Here: Planning Your IaaS Migration Prerequisites, 2015., preuzeto sa, https://edtechmagazine.com/higher/article/2015/10/how-get-there-here-planning-your-iaas-migration-prerequisites [11.12.2018]
5 Plan.B, CIO, Your cloud migration checklist for before, during and after migration, 2018., preuzeto sa https://www.cio.co.nz/brand-post/content/642420/your-cloud-migration-checklist-for-before-during-and-after-migration/ [11.12.2018]
6 AgileIT, Step-by-Step Azure Migration Planning, 2018., preuzeto sa https://www.agileit.com/news/step-by-step-azure-migration-planning/ [11.12.2018]
7 Teledata, From cabinet to cloud: An IaaS migration checklist, 2018., preuzeto sa https://www.teledata.co.uk/download-our-iaas-migration-checklist [11.12.2018]
8 PentaBlog, How to fail your IaaS cloud migration in 5 steps, 2017.. preuzeto sa https://www.pentalog.com/blog/how-to-fail-your-iaas-cloud-migration-in-5-steps/ [14.12.2018]
9 Saviantconsulting, 10 Azure Migration Challenges and Ways to overcome them, 2018., pruzeto sa https://www.saviantconsulting.com/blog/overcoming-10-azure-migration-challenges.aspx [14.12.2018]
10 Charles, 5 common IaaS migration mistakes and how to avoid them, 2018., preuzeto sa https://www.charlesit.com/2018/09/11/5-common-iaas-migration-mistakes-avoid/ [14.12.2018]
Podaci o autorima:
Marko Havoić
e-mail: [email protected]
Izvanredni student 2. godine specijalističkog diplomskog studija na Veleučilištu u Rijeci. Nakon završetka stručnog preddiplomskog studija na Fakultetu organizacije i informatike u Varaždinu radi posljednje četiri godine na poslovima sistemskog održavanja.
dr.sc. Marin Kaluža
e-mail: [email protected]
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.
Sabrina Šuman
e-mail: [email protected]
Diplomirala 2002. na Filozofskom fakultetu, smjer matematika i informatika. Zaposlena je kao viši predavač na Veleučilištu u Rijeci gdje radi od 2005. godine te je nositelj kolegija: Informacijski sustavi za potporu upravljanju i odlučivanju, Grafika tekst i multimedija, Upravljanje kvalitetom informacijskih sustava na stručnom i specijalističkom studiju. Doktorand je na poslijediplomskom studiju odjela Informatike Sveučilišta u Rijeci. Sudjelovala je i sudjeluje na nekoliko znanstvenih projekata. Autor je niza recenziranih nastavnih materijala te jednog udžbenika. Objavila je više od 20 znanstvenih i stručnih članaka. Područja interesa: metode umjetne inteligencije, procesiranje prirodnog jezika, rudarenje podataka i teksta, poslovna inteligencija.
Veleučilište u Rijeci
Trpimirova 2/V, 51 000 Rijeka
tel. 051/321-300
fax. 051/211-270,
www.veleri.hr
26 CASE2019
CASE2019 27
PRIMJER RAZVOJA - SUSTAV ZA EVIDENCIJU RADA AUTOSERVISA
Antun Delinger, mag.oec., doc.dr.sc. Tihomir Orehovački
SAŽETAK
Popravak motornih vozila uobičajena je stvar za gotovo svakog čovjeka budući da je u današnje vrijeme posjedovanje automobila gotovo neophodno za normalan život. Kao i u svemu, postoji velika konkurencija između različitih servisa. S druge strane, autoservisima je nerijetko jedna od slabijih strana organizacija poslova i općenito komunikacija s klijentima. Upravo takvom tržištu namijenjen je sustav za upravljanje radom autoservisa. Cilj ovog rada je olakšati komunikaciju s klijentima u poslovnoj domeni koja još uvijek nije uhvatila korak s najnovijim trendovima i tehnologijama. Upravljanje radom autoservisa obavlja se pomoću tri aplikacije – dvije mobilne Android aplikacije od kojih je jedna namijenjena klijentima, a jedna autoservisu te web aplikacije koja je namijenjena isključivo autoservisu. Klijenti se putem mobilne aplikacije mogu dogovoriti za novi termin pregleda vozila te pratiti povijest popravaka, a osoblje autoservisa putem web aplikacije odgovara na upite i eventualno potvrđuje dogovor za termin. Svaki odgovor autoservisa zabilježen je u obliku obavijesti koja dolazi na Android uređaj klijenta.
SUMMARY
Car repairing and servicing has always been an usual task for almost everyone, especially if we consider that it is basicaly impossible to live without the car nowadays. As it is in almost every branch, there is a serious competition between car services. On the other hand, it is very often the case for car services that they are not good in organizing their work and, especialy, managing their clients. That is exactly the market that Car Service Management System targets. Main goal of this paper is to present new business model for car services and, more importantly, to present modern way of making appointments with a car service. With this system, car service work is being managed with three applications – two Android mobile applications (one client – oriented and the other car service oriented) and web application which is car services – oriented. Car service clients use their mobile app to arrange a new meetings and, afterwards, to keep record of their previous repairs. Car service staff use web application to manage orders from their clients as well as to keep track of the work they have to do and the work that has already been done. Every response that staff of a car service sends is being followed by the notification sent on client's mobile device.
1. UVOD
Današnje poslovanje uvelike je otežano bez upotrebe interneta, društvenih mreža i online aplikacija. Kada govorimo o uslužnim djelatnostima, ključno je olakšati komunikaciju klijenata i tvrtki. Velika konkurentnost i sve veća orijentiranost ka modernim rješenjima jednostavno prisiljavaju tvrtke svih djelatnosti da se priključe tom trendu. Jedan od načina za olakšavanje komunikacije i općenito pristupa potencijalnih klijenata su svakako društvene mreže i mobilne aplikacije pomoću kojih klijenti na jednostavan način stupaju u kontakt sa željenom tvrtkom i informiraju se o određenim uslugama. S obzirom da su društvene mreže ionako prihvaćene i dulje vrijeme u upotrebi od strane gotovo svih tvrtki, otvara se veliko tržište i potražnja za mobilnim aplikacijama toga tipa. Android je trenutno najrasprostranjeniji operativni sustav za mobilne uređaje. Prema tome, Android sustav predstavlja logičan izbor platforme za izradu aplikacije namijenjene poslovanju. Aplikacija razvijena za ovaj sustav vrlo se lako plasira na najpopularniju trgovinu aplikacija – Google Play – gdje ju mogu preuzeti milijuni korisnika. Kako su aplikacijska rješenja za objekte poput restorana i slično već razvijena u velikom broju i mala je potreba za istima, bilo je potrebno pronaći neku granu koja bi bila u povojima po pitanju upotrebe online aplikacija, ali i gdje bi potreba za korištenjem bila veća. Tako je uočena potreba za izradom aplikacije za upravljanje autoservisom u smislu komunikacije sa korisnicima i naručivanjem raznih usluga putem aplikacije gdje bi objema stranama posao bio olakšan. Sustav se sastoji od jedne Android aplikacije koja je namijenjena krajnjim korisnicima te jedne Android i web aplikacije namijenjene administraciji u autoservisu.
2. ANDROID MOBILNA APLIKACIJA NAMIJENJENA KLIJENTIMA AUTOSERVISA
Android aplikacija zamišljena je kao usluga na strani klijenta. Njena svrha je olakšati rad djelatnicima i klijentima autoservisa. Nakon registracije novog korisnika ili prijave postojećeg, korisnik može poslati zahtjev za dolaskom na servis koji sadrži sve informacije relevantne za popravak vozila kao i sam tip popravka. Nakon zaprimanja i pregleda poslanog zahtjeva, djelatnik autoservisa daje povratnu informaciju o raspoloživom terminu, cijeni popravka i slično. Aplikacija je izrađena u razvojnom okruženju Visual Studio 2017. Obzirom da Visual Studio nije namijenjen razvoju mobilnih aplikacija, isti se odvija kroz Xamarin.Android, softver koji omogućava razvoj nativnih Android aplikacija koristeći Visual Studio i programski jezik C# ili F#. Shodno tome, ova aplikacija napisana je u programskom jeziku C#. Koristeći Xamarin.Android, razvijatelju aplikacije dostupan je kompletan Android SDK (Software Development Kit) te se prema tome razvoj ne bi treba bitno razlikovati u odnosu na službene kanale namijenjene razvoju nativnih Android aplikacija.
28 CASE2019
Slika1: Zaslon za prijavu mobilne aplikacije za klijente [1]
Informacije nastale kroz interakciju sa mobilnom aplikacijom spremaju se u Firebase NoSQL bazu podataka. Spomenute podatke web aplikacija dohvaća i prikazuje rukovodstvu autoservisa. Mobilna aplikacija namijenjena klijentima sastoji se od nekoliko jednostavnih prozora i nekoliko fragmenata (djelomičnih prozora) kojima se korisnik kreće. Prilikom prvog pokretanja, korisniku je prikazan zaslon za prijavu (slika 1) gdje ima priliku registrirati se i nakon toga se prijaviti. Prilikom registracije (slika 2) korisnik mora upisati svoje osobne podatke te email adresu pomoću koje će pristupati sustavu.
Slika 2: Zaslon za registraciju u sustav mobilne aplikacije za klijente[1]
Proces registracije i prijave korisnika odvija se pomoću tehnologije Firebase Auth koju je razvila tvrtka Google.Klikom na „Registriraj se“, prvo se provjerava jesu li sva polja u fragmentu ispunjena, te zatim podudaraju li se dvije upisane lozinke. Ukoliko obje provjere prođu bez potrebe za interakcijom aplikacije, aktivira se događaj (engl. event) koji prikuplja dodane informacije, zatvara fragment i predaje ih natrag u aktivnost „loginActivity.cs“. Aktivnost „loginActivity“ prethodno je pretplaćena na događaj klika na gumb „Registracija“. Nakon preuzimanja informacija od fragmenta za registraciju, poziva se metoda „CreateUserWithEmailAndPassword()“ gdje se kao parametar šalje korisnikov e-mail i lozinka te Firebase kreira novog korisnika u svojoj bazi podataka za autentifikaciju korisnika. Metoda za kreiranje novog korisnika nalazi se u klasi „FirebaseAuth“ koju je potrebno instancirati te je instanca te klase nazvana „auth“.
1. private void Dialog_onSignUpComplete(object sender, onSignUpEventArgs e) { 2. signup_inputName = e.firstName; 3. signup_inputLastName = e.lastName; 4. signup_inputPhoneNumber = e.phone; 5. signup_inputEmail = e.email; 6. signup_inputPassword = e.password; 7. auth.CreateUserWithEmailAndPassword(signup_inputEmail, signup_inputPassword).AddOnCompleteListener(this, this); 8. progressBar.Visibility = ViewStates.Visible; 9. }
Prilikom predaje argumenata za registraciju, metodi je pridružen „slušač događaja“ (engl. event listener) „AddOnCompleteListener() koji reagira na određeni događaj. U ovom slučaju reagirat će na završen proces registracije.
1. public void OnComplete(Task task) { 2. if (task.IsSuccessful) {
CASE2019 29
3. Toast.MakeText(this, "Uspješno ste se registrirali. Možete se prijaviti.", ToastLength.Long).Show(); 4. FirebaseUser user = FirebaseAuth.GetInstance(app).CurrentUser; 5. id = user.Uid; 6. CreateUser(); 7. buttonSignIn.PerformClick(); 8. progressBar.Visibility = ViewStates.Invisible; } else { 9. Toast.MakeText(this, "Neuspješna registracija. Možda postoji problem sa vezom ili korisnik sa dodanim emailom već postoji. ", ToastLength.Long).Show(); 10. progressBar.Visibility = ViewStates.Invisible; 11. } }
Spomenuti „slušač događaja“ daje povratnu informaciju koju dobije s Firebase Auth poslužitelja, a koja može biti točno (registracija uspješna) ili netočno (registracija neuspješna). Iz gore prikazanog koda je evidentno da ako je registracija prošla uspješno („task.IsSuccessful) korisnik je usmjeren na zaslon za prijavu, a ukoliko je registracija prošla neuspješno, korisnik je upozoren porukom. Na sličan način je izvršen i proces prijave primjenom klase „FirebaseAuth“ i instance te iste klase „SignInWithEmailAndPassword()“ koja preuzima od korisnika informacije za prijavu. Kao i u slučaju registracije, aplikacija povratnu informaciju o uspješnosti prijave preuzima s poslužitelja.
Nakon prijave u sustav, korisniku se otvara glavni zaslon (slika 3) unutar kojeg korisnik može pristupiti padajućem izborniku u gornjem lijevom uglu te odabrati odjavu iz sustava ili prikaz podataka o autoservisu.
Slika 3: Glavni zaslon mobilne aplikacije namijenjene klijentima[1]
U srednjem dijelu prozora nalaze se gumbi koji vode na tri sljedeća izbornika: „Dogovori termin“ koji, sukladno nazivu, vodi na prozor za upis podataka i dogovor termina. Zatim, gumb „Moji termini“ otvara prozor u kojemu je vidljiv pregled svih podataka vezanih uz dogovorene termine ili termine čiji dogovor je u tijeku te za kraj gumb „Moj auto“ koji prikazuje popis vozila. Na popisu vozila moguće je dodati novo vozilo ili pregledati podatke o postojećem vozilu.
Prilikom kreiranja novog prijedloga sastanka, potrebno je odabrati neki od već ranije dodanih automobila ili dodati novo vozilo te upisati sve potrebne informacije (slika 4).
Slika 4: Zaslon za dodavanje vozila prilikom dogovora termina [1]
30 CASE2019
Dodavanje relevantnih informacija prilikom odabira vozila podrazumijeva: podatke o vozilu, kratak opis kvara vozila, informaciju o potrebi za vučnom službom te informaciju o potrebnim dijelovima za vozilo. Na kraju postupka kreiranja prijedloga termina, potrebno je potvrditi sve podatke koji su ranije upisani ili odabrani (slika 5) i zahtjev se šalje autoservisu kojem isti pristupa preko web aplikacije.
Slika 5: Zaslon za potvrdu prijedloga sastanka [1]
Gumb „Potvrdi sastanak“ pohranjuje sve podatke u Firebase bazu podataka, a prije svega se provjerava da li je korisnik na mreži što je uvjet za nastavak procedure. Ako je provjera uspješno prošla, kreira se novi sastanak u bazi podataka. Za to je potrebno kreirati objekt koji će sadržavati sve potrebne atribute.
1. orders orders= new orders(); 2. orders.uid = id; 3. orders.carName = carChosen; 4. orders.vrstaUsluge = vrstaUsluge; 5. orders.vrstaPosla = vrstaPosla; 6. orders.opisKvara = opisKvara.Text; 7. orders.datum = DateTime.Now.ToLocalTime().ToString(); 8. orders.vucnaSluzba = potrebnaVucnaSluzba; 9. orders.dijelovi = potrebnoNarucivanje; 10. orders.pozeljniDatum = addedDate.Text; 11. orders.vrijemeServisa = "Nepoznato"; 12. orders.cijena = "Nepoznato"; 13. orders.napomenaServisera = "Serviser još uvijek nije dodao nikakvu napomenu"; 14. orders.status = "Poslano na obradu";
Nakon kreiranog objekta i dodjeljivanja vrijednosti pojedinog atributa, taj se objekt predaje metodi pomoću koje se kreira nova tablica u Firebase bazi podataka. Potrebno je napomenuti kako je u slučaju kreiranja ove tablice kreiranje jedinstvenog ključa (id) predstavljalo izazov. Naime, jedinstveni ključ koji Firebase generira prikladan je za upotrebu u programerskom smislu, ali nije zgodan za prezentaciju korisniku unutar aplikacije (kako bi se razlikovale narudžbe jedna od druge) pa je stoga tu bilo potrebno nešto elegantnije rješenje. Pored uobičajenog jedinstvenog ključa kojeg generira sama baza podataka, korišteni su prirodni brojevi od 1 – n (n = broj sastanaka pojedinog korisnika). Obzirom da Firebase nema „Auto Increment“ mogućnost, to je izvedeno tako što su izvučeni svi sastanci pojedinog korisnika iz baze, prebrojani i tom je broju zatim dodan još jedan broj.
1. int numOfOrders = 1; 2. orderID = JsonConvert.SerializeObject(numOfOrders.ToString()); 3. List < orders > allOrders = new List < orders > (); 4. var getONumberOfOrders = await firebase.Child("order").Child(id).OnceAsync < orders > (); 5. foreach(var item in getONumberOfOrders) { 6. allOrders.Add(new orders { 7. carName = item.Object.carName; 8. numOfOrders = allOrders.Count + 1; 9. orderID = numOfOrders.ToString(); 10. orderID = JsonConvert.SerializeObject(orderID);
11. orders.id = numOfOrders.ToString(); }}
Nakon što je utvrđen redni broj sastanka, a samim time i jedinstveni ključ sastanka (odnosi se samo na određenog korisnika – može biti isti jedinstveni ključ za dva različita korisnika) slijedi kreiranje tablice u bazi podataka.
1. var addOrder = firebase.Child("order").Child(id).Child(orderID.ToString()).PostAsync < orders > (orders);
Navedeno će kreirati čvor u Firebase bazi podataka kao što je prikazano na slici 6. Nakon što je sastanak uspješno kreiran, time se završava proces kreiranja sastanka te se otvara dijalog koji korisnika obavještava o završetku istog.
CASE2019 31
Slika 6. Prikaz kreiranog čvora u bazi podataka [1]
3. WEB APLIKACIJA ZA UPRAVLJANJE UPITIMA KORISNIKA
Web aplikacija zamišljena je za upotrebu u autoservisu. Drugim riječima, zahtjevi poslani kroz mobilnu aplikaciju preuzimali bi se unutar web aplikacije te bi ih osoba zadužena za to pregledavala i odgovarala na iste. Web aplikacija zahtjeva prijavu prije korištenja. Nakon prijave, korisnik ima uvid u zaprimljene zahtjeve na koje može odgovarati dodavajući termin popravka, cijenu popravka i slično. Aplikacija je izrađena u razvojnom okruženju WebStorm pomoću standardnih web tehnologija kao što su HTML i CSS. Programski jezik JavaScript korišten je za razvoj kako klijentske strane web aplikacije (eng. Front - End), tako i na strani poslužitelja (engl. Back - End). Kako bi to bilo moguće, razvoj se odvijao na poslužiteljskoj platformi Node.js. Za postavljanje poslužitelja korišten je Express Framework koji automatski kreira poslužiteljski predložak.
Prilikom prvog otvaranja web aplikacije prikazuje se zaslon za prijavu kao što je vidljivo na slici 7.
Slika 7. Zaslon za prijavu u web aplikaciju [1]
Koristeći HTML I CSS kreiran je jednostavan zaslon za prijavu s poljima „Korisničko ime“ i „Lozinka“ te s gumbom „Login“. Web aplikacija kao i njena mobilna inačica za klijente koristi Firebase Auth tehnologiju za prijavu korisnika. Upotrebom JavaScript programskog jezika registriran je događaj za klik na gumb za prijavu („login“). Navedeno je izvršeno na način da se klikom na gumb za prijavu pokreće metoda „signIn()“ koja je definirana u istom dokumentu. Metoda preuzima podatke od korisnika te ih prosljeđuje poslužitelju koji daje povratnu informaciju o uspješnosti prijave ovisno o točnosti dobivenih parametara. U slučaju ispravnih podataka, korisnik je preusmjeren na početnu (glavnu) stranicu aplikacije (kao što je prikazano na slici 7), dok je u slučaju neispravnih podataka o istima obaviješten kroz poruku ispod „LOGIN“ gumba. Proces prijave implementiran je sljedećim kodom:
32 CASE2019
1. function signIn() {
2. var form = document.getElementById("form1"); 3. var email = form[0].value; 4. var password = form[1].value; 5. var falsePasswordMessage = document.getElementById("passwordMessage"); 6. var idToken; 7. 8. var authProvider = new firebase.auth.EmailAuthProvider
firebase.auth().signInWithEmailAndPassword(email, password) .then(function(data)
9. var notAdmin = ""; 10. idToken = data.user.uid; 11. localStorage.setItem('id', idToken); 12. sessionStorage.setItem('userType', notAdmin)
var database = firebase.database(); 13. var Ref = firebase.database().ref('users/' + data.user.uid + '/' + 'typeNode/' + '
/'); 14. 15. Ref.on('value', function(snapshot) 16. if (snapshot.val().type == "admin") { 17. window.location.href = 'main.ejs'; 18. sessionStorage.setItem('userType', snapshot.val().type == "admin") } 19. }).catch(function(error) { 20. firebase.auth().signOut(); 21. falsePasswordMessage.style.display = 'block'; 22. }) 23. }).catch(function(error) 24. console.log(error)
falsePasswordMessage.style.display = 'block'; 25. }) 26. }
Obzirom da bi korisnik, uzimajući u obzir zahtjeve, trebao biti u mogućnosti, nakon zatvaranja prozora i prilikom ponovnog pokretanja, automatski se prijaviti i otvoriti početnu stranicu, potrebna je provjera da li je korisnik prijavljen u sustav od ranije. Primjenom sljedeće funkcije izvršena je provjera i automatsko preusmjeravanje korisnika na početnu stranicu:
1. function checkIfLoggedIn() { 2. var type = sessionStorage.getItem('userType'); 3. firebase.auth().onAuthStateChanged(function(user) { 4. if (user && type == 'admin') { 5. document.body.style.display = 'block' 6. currentUserId = user.uid;} 7. else { logOut(); } }) }
Nakon prijave u sustav, korisniku je vidljiva tablica s podacima o korisnicima (prikazano na slici 7) te podacima o svim zahtjevima, odnosno prijedlozima termina, uključujući i one već dogovorene te one već završene. Tablicu je moguće filtrirati prema novim zahtjevima, dogovorenim zahtjevima, zahtjevima u obradi, zahtjevima koji čekaju odgovor te poslovima koji su već završeni.
Obzirom da su svi važni elementi početne stranice vezani uz tablicu, najvažnija metoda, preko koje su dohvaćeni svi podaci, je metoda „createTable()“ pomoću koje se kreira tablica sa zadanim naslovima te se uzimaju podaci iz baze podataka i popunjavaju redovi. U nastavku je zbog preglednosti i jednostavnosti prikazan kod metode „createTable()“.
1. var database = firebase.database(); 2. var Ref = firebase.database().ref('order/'); 3. var fragment = document.createDocumentFragment(); 4. var table = document.createElement("table"); 5. 6. Ref.on('value', function(snapshot) { //get userID from orders 7. listOfOrders = snapshot.val(); 8. var headerList = ["IDKorisnika", "ID zahtjeva", "Ime korisnika", "Email", "Auto", "Status", "Vrijeme", ""]; 9. for (var i = 0; i < headerList.length; i++) { 10. var th = document.createElement("th"); 11. th.textContent = headerList[i]; 12. table.appendChild(th); } 13. fragment.appendChild(table);
CASE2019 33
U prvom dijelu koda definirane su varijable za dohvaćanje podataka iz baze podataka („database“ i „Ref“), a zatim su kreirane varijable za kreiranje tablice („fragment“ i „table“). Za kraj, dodijeljeni su nazivi zaglavlja i raspoređeni su u kasnije kreiranu tablicu. Obzirom da su u tablici potrebni podaci o korisniku, podaci o zahtjevu te podaci o vozilu, bilo je potrebno pristupiti trima različitim tablicama u bazi podataka, a sve u jednoj petlji kako bi se tablica mogla popuniti tim istim podacima. Najprije su dohvaćeni podaci o broju određenog zahtjeva („childSnapshot.key“):
1. snapshot.forEach(function(childSnapshot) { 2. var RefTwo = firebase.database().ref('order/' + childSnapshot.key + '/'); 3. RefTwo.once('value', function(snapshotTwo) { //get number of order from orders 4. listOfOrders = snapshot.val(); 5. snapshotTwo.forEach(function(childSnapshotTwo) {
Nakon dohvaćanja podatka u broju zahtjeva, moguće je pristupiti pojedinom zahtjevu u bazi i prema tome dohvatiti podatke koji su potrebni. U ovom slučaju su to status zahtjeva i datum kreiranja zahtjeva:
1. var RefNew = firebase.database().ref('order/' + childSnapshot.key + '/' + childSnapshotTwo.key + '/'); 2. RefNew.once('value', function(snap) { 3. snap.forEach(function(snapChild) { 4. orderStatus = snapChild.val().status; 5. timeInfo = snapChild.val().datumKreiranja;
Nastavljajući u istoj petlji, pristupa se podacima o korisniku u bazi podataka, točnije preuzimaju se ime, prezime i e-mail konkretnog korisnika:
1. var RefThree = firebase.database().ref('users/' + childSnapshot.key + '/'); //get user info from users 2. RefThree.once('value', function(snapshotThree) { 3. snapshotThree.forEach(function(childSnapshotThree) { 4. userName = childSnapshotThree.val().name + " " + childSnapshotThree.val().lastName; 5. userEmail = childSnapshotThree.val().email
Nakon što su preuzeti svi potrebni podaci za konkretnog korisnika, potrebno je te podatke pohraniti u tablicu. Kao što je u kodu dolje vidljivo, podaci korisnika pohranjeni su u varijablu „trValues“ koja predstavlja vrijednost pojedinog retka tablice. Osim toga, potrebno je programirati ponašanje aplikacije nakon klika na pojedini redak, odnosno programirati aplikaciju da otvori novi prozor s podacima o odabranom zahtjevu i korisniku.
1. var trValues = [childSnapshot.key, childSnapshotTwo.key.substr(1, 1), userName, userEmail, snapChild.val().carName, snapChild.val().status, snapChild.val().datumKreiranja]; 2. for (var i = 0; i < trValues.length; i++) { 3. var td = document.createElement("td"); 4. sessionStorage.setItem('userID', trValues[0]); 5. sessionStorage.setItem('orderID', trValues[1]); 6. sessionStorage.setItem('carName', trValues[4]); 7. window.location.href = '/orderView.ejs'; 8. }
Nakon što je pomoću klase „sessionStorage“ u lokalnu memoriju postavljena informacija o korisniku (koja će se kasnije preuzeti u novoj stranici za prikaz tog istog korisnika), dovršava se kreiranje tablice. Filtriranje tablice je izvedeno pozivanjem metode „createTable()“ koja zahtijeva parametar tipa string koji govori što prikazati u tablici, a može biti oblika: „showAll“, „showNewRequested, „showDeal, „showProcessing“ te „showUserSuggestion“, a koji respektivno predstavljaju prikaz svih, novih, završenih, dogovorenih, zahtjeva u obradi te zahtjeva koji traže reakciju korisnika.
1. if (filterData == 'showAll') { 2. td.textContent = trValues[i]; 3. tr.appendChild(td) tr.appendChild(dot) table.appendChild(tr);} 4. if (filterData == 'showNewRequirements') { 5. if (trValues[5] != 'Kreirano') return; 6. td.textContent = trValues[i]; 7. tr.appendChild(td) tr.appendChild(dot) table.appendChild(tr); }
Zbog pojednostavljenja i preglednosti prikazana su samo prva dva slučaja. Prvi slučaj predstavlja situaciju kada treba prikazati sve zahtjeve odnosno kada je proslijeđen parametar „showAll“, a to se događa kad korisnik odabere gumb „Svi zahtjevi“ u aplikaciji. U tom slučaju nema nikakvog filtriranja i prikazuju se svi zahtjevi koji su pronađeni u bazi podataka. U drugom slučaju, kada postoji potreba za filtriranjem, u ovom slučaju prikazom svih novih, tek kreiranih zahtjeva, vrši se provjera da li je status trenutno provjeravanog zahtjeva jednak tekstu „Kreirano“. Ukoliko jest, taj zahtjev se prikazuje u tablici, a ukoliko nije jednak spomenutom tekstu, taj zahtjev se ignorira. Na ovaj način je riješeno filtriranje i ostalih slučajeva.
34 CASE2019
Slika 8. Glavni izbornik web aplikacije [1]
Glavni izbornik (slika 8) osim podataka o korisnicima sadrži još i obojane kružiće kraj svakog korisnika na kraju tablice, a koji predstavljaju: siva boja završene poslove, narančasta boja zahtjeve u obradi, zelena boja nove zahtjeve te žuta boja nove tek pristigle zahtjeve na koje se čeka odgovor. Podaci koji se prikazuju dohvaćeni su iz Firebase NoSQL baze podataka gdje su pohranjeni kroz mobilnu aplikaciju namijenjenu klijentima. Zahvaljujući karakteristikama Firebase baze podataka, podaci se prikazuju u realnom vremenu, odnosno nije potrebno osvježavati preglednik kako bi se vidjeli novi podaci nego se oni automatski prikazuju. Klikom na neki od pristiglih zahtjeva, otvara se izbornik u kojem se prikazuju svi podaci o korisniku, svi podaci o vozilu vezanom za određeni zahtjev te svi podaci o samom zahtjevu koje je korisnik mobilne aplikacije pohranio u bazu podataka (prikazano na slici 9).
Slika 9. Prikaz podataka o odabranom zahtjevu na web aplikaciji [1]
U izborniku za pregled informacija o odabranom zahtjevu također se nalaze i gumbi „Odjavi se“ koji odjavljuje korisnika iz sustava, gumb „Početna stranica“ koji vodi korisnika na početnu stranicu te gumbi za uređivanje zahtjeva. Prvi od gumba za uređivanje zahtjeva, gumb „Označi kao dogovoreno“, odgovara na zahtjev potvrdno odnosno implicira slaganje sa zahtjevima koje je korisnik poslao, prijedlogom termina servisa i ostalim prijedlozima te šalje obavijest na mobilni telefon korisnika kako je postignut dogovor. Drugi gumb, gumb „Označi kao završeno“, označava zahtjev završenim, odnosno implicira se da je korisnik bio u servisu, popravio vozilo te napustio servis. Posljednja stavka, „Obriši zahtjev“, omogućava brisanje zahtjeva iz baze podataka te taj isti zahtjev više nije vidljiv ni korisniku mobilne ni korisniku web aplikacije. Koristeći tehnologiju Firebase Cloud Messaging, web aplikacija temeljem jedinstvenog tokena korisnika šalje obavijest na mobilnu aplikaciju samo tog korisnika koji je kreirao zahtjev. Mobilna aplikacija zatim preuzima obavijest te ju prikazuje korisniku u centru za obavijesti. Korisnik nakon toga može kliknuti na obavijest te pregledati novosti vezane uz obavijest kroz izbornik „Moji zahtjevi“ u mobilnoj aplikaciji namijenjenoj klijentima.
Slika 10. Prikaz forme za unos odgovora na zahtjev
CASE2019 35
Slika 10 prikazuje formu za unos odgovora na zahtjev što ujedno predstavlja najvažniju komponentu stranice. Klikom na gumb „Pošalji poruku“ poziva se metoda „sendImportedData()“ koja, kao što naziv sugerira, podatke koje je korisnik dodao upisuje u bazu podataka. Podaci se ažuriraju tako što se cijela tablica podataka u bazi mijenja s podacima koji su u tablici, a na mjesto „datum“, „vrijeme“; „cijena“ i „napomena servisera“ sprema se unos koji je korisnik dodao u polje za upis teksta. Obzirom da je podatak o potrebi za vučnom službom i podatak o potrebi za dijelovima tipa Boolean, isti su prije upisa u tablici pretvoreni u jednostavan tekst „Da“, odnosno „Ne“, ovisno o tome da je li zapis imao vrijednost točno ili netočno. Tako je u slučaju ažuriranja podataka bilo potrebno pretvoriti tekstualan podatak koji nosi vrijednost „Da“ ili „Ne“ ponovno u tip podataka Boolean kako bi se pohranio u bazu podataka.
1. function sendImportedData(status) { 2. var database = firebase.database(); 3. var vucnaBool = true; 4. var dijeloviBool = true; 5. if (vucnaSluzba.textContent == "Da") vucnaBool = true; 6. if (vucnaSluzba.textContent == "Ne") vucnaBool = false; 7. if (dijelovi.textContent == "Da") dijeloviBool = true; 8. if (dijelovi.textContent == "Ne") dijeloviBool = false; 9. var order = { 10. carName: IDVozila.textContent, 11. cijena: inputCijena.value, 12. datumKreiranja: datumKreiranja.textContent, 13. datumServisa: inputDate.value, 14. dijelovi: dijeloviBool, 15. id: IDzahtjeva.textContent, 16. napomenaServisera: inputNapomena.value, 17. opisKvara: opisKvara.textContent, 18. pozeljniDatum: pozeljanDatum.textContent, 19. status: status, 20. uid: IDKorisnika.textContent, 21. vrijemeServisa: inputTime.value, 22. vrstaPosla: vrstaPosla.textContent, 23. vrstaUsluge: vrstaUsluge.textContent, 24. vucnaSluzba: vucnaBool, 25. } 26. var updates = {}; 27. updates['order/' + userID + '/' + orderID + '/' + orderKey] = order; 28. var Ref = firebase.database().ref().update(updates) 29. } 30. getTokenAndOptions();}
Nakon završetka ažuriranja podataka i na samom kraju metode, poziva se metoda „getToken“ u kojoj se preuzima token. Cilj te metode, kao i preuzimanja tokena, je slanje obavijesti na ciljani uređaj. Token identificira uređaj na kojemu je korisnik prijavljen, a njegova vrijednost se mijenja svakom novom instalacijom aplikacije.
1. function getToken() { 2. var database = firebase.database(); 3. var Ref = firebase.database().ref('/tokens' + '/' + userID + '/'); 4. Ref.on('value', function(snapshot) { 5. idToken = snapshot.val(); 6. sendNotification(idToken, orderID); 7. }) 8. }
Token se nalazi u bazi podataka pod čvorom „tokens“ te zatim u donjem čvoru „userID“, odnosno svaki korisnik aplikacije ima u čvoru „tokens“ zapisan i svoj token uređaja. Na samom kraju metode „getToken()“ poziva se još metoda „sendNotification()“ koja za cilj ima slanje obavijesti na Android uređaj, a kao parametre preuzima informaciju „idToken“ iz trenutno aktivne metode te informaciju „orderID“ koja će kasnije biti proslijeđena kroz obavijest korisniku.
1. function sendNotification(idToken, orderID) { 2. var token = idToken; 3. var OID = orderID 4. try { 5. var myWindow = window.open("http://localhost:10001" + "?number1=" + token + "&number2=" + OID, 'targetWindow', "width=250px, height=250px") myWindow.close(); 6. alert('Uspješno poslano!'); 7. } catch (e) {} 8. }
Sama metoda „sendNotification()“ zapravo ne šalje obavijest korisniku, nego preuzima potrebne parametre i prosljeđuje ih dalje. Naime, Firebase Admin SDK, koji je osnova za upravljanje Firebase obavijestima na web platformi, namijenjen je isključivo, iz sigurnosnih razloga, za upotrebu na poslužiteljskoj strani web aplikacije. Problem s navedenim je što
36 CASE2019
aplikacija na klijentskoj strani preuzima informaciju o korisniku kojemu treba poslati obavijesti, njegovom ključu, tokenu i konačno ključu konkretnog zahtjeva. Osim tih informacija, također se šalje obavijest kao reakcija na klik korisnika na gumb „Pošalji poruku“. Kako bi se premostila barijera između klijentske i poslužiteljske strane aplikacije, postavljen je novi port („10001“) na koji se (na poslužitelju) šalju podaci o kliku korisnika na gumb te informacije potrebne za slanje obavijesti. Na strani poslužitelja je registriran slušač (eng. listener) na konkretan port („10001“) koji će registrirati promjene na navedenom portu.
1. http.createServer(function(request, response) { 2. response.writeHead(200, { 3. "Content-Type": "text/plain" 4. }); 5. var params = url.parse(request.url, true).query; 6. var payload = { 7. notification: { 8. title: "Obavijest o narudžbi", 9. body: "Promijenjen je status zahtjeva broj" + '' + params.number2 + '' 10. } 11. } 12. var options = { 13. priority: "high" } 14. admin.messaging().sendToDevice('' + params.number1 + '', payload, options).then(function(response) {}).catch(function(error) { 15. console.log(error) 16. }) response.write('Poslano!') response.end(); 17. }).listen(10001);
Nakon što slušač uoči promjene odnosno da je gumb „Pošalji poruku“ kliknut, poslužitelj preuzima parametre koji su poslani prilikom kreiranja zahtjeva poslužitelju. Parametri su nazvani „number1“ i „number2“, a sadrže informacije o ključu zahtjeva („orderID“) te informaciju o tokenu uređaja. Varijabla „params“ preuzela je informacije poslane na poslužitelj kroz „url.pars().query“. Nakon preuzimanja parametara, potrebno je definirati preostala dva objekta koja su potrebna kako bi se kreirala obavijest – „payload“ i „options“. Prvi objekt naziva „payload“ sadrži informacije o samoj obavijesti odnosno njezin naslov te što će obavijest sadržavati u svom tijelu. U tijelo obavijesti dodan je tekst „Promijenjen je status narudžbe broj“ te je dodan sadržaj varijable „params.number2“ odnosno broj zahtjeva ili narudžbe na koju se odnosi obavijest. Objekt „options“ sadrži informaciju o prioritetu obavijesti (postavljena na visoki prioritet) te druge, opcionalne informacije koje u ovom slučaju nisu korištene. Zatim, koristeći instancu „admin“ i metodu te instance „messaging()“ šalje se obavijest, prosljeđujući navedenoj metodi ranije definirane parametre – „token“, „payload“ i „options“. Završetkom slanja obavijesti, korisnik web aplikacije zaprima obavijest kako je slanje obavijesti uspješno izvršeno.
Primanje obavijesti u mobilnoj aplikaciji izvedeno je kroz glavnu aktivnost aplikacije (eng. Main Activity). Pokretanjem glavne aktivnosti upisuje se token vrijednost uređaja koja identificira uređaj na kojemu je trenutno instalirana aplikacija. Poziva se izvođenje novog zadatka (eng. Task) unutar kojeg će se izvesti preuzimanje tokena.
1. await Task.Run(() => { 2. var instanceId = FirebaseInstanceId.Instance; 3. token = instanceId.GetToken(authorizedEntity, scope); 4. Android.Util.Log.Debug("TAG", "{0} {1}", instanceId.Token, token, Firebase.Messaging.FirebaseMessaging.InstanceIdScope); 5. makeDatabaseRecord(token); });
Na kraju novokreiranog zadatka poziva se metoda „makeDatabaseRecord()“ kojoj se prosljeđuje vrijednost tokena koja je upravo preuzeta.
1. private void makeDatabaseRecord(string token) { 2. FirebaseUser users = FirebaseAuth.GetInstance(loginActivity.app).CurrentUser; 3. id = users.Uid; 4. var firebase = new FirebaseClient(loginActivity.FirebaseURL); 5. var item = firebase.Child("tokens").Child(id).PutAsync < string > (token); 6. }
Metoda sprema podatak o tokenu u Firebase bazu podataka pod čvorom „tokens“. Unutar čvora „tokens“ nalazi se čvor „id“ unutar kojeg se pohranjuje informacija o jedinstvenom ključu korisnika kako bi se znalo koji token pripada kojem korisniku. Osim toga, token se mijenja prilikom svakog ponovnog instaliranja aplikacije te je stoga potrebno ažuriranje tokena. Iz tog se razloga zapis u bazi podataka ažurira prilikom svakog pokretanja aplikacije. U slučaju promjene tokena, poziva se metoda „OntokenRefresh()“ koja registrira promjene tokena. Metoda je prepisana (eng. Override) na način da provjerava da li je korisnik trenutno prijavljen u sustav. Ukoliko korisnik nije prijavljen u sustav, a dogodila se promjena tokena, briše se instanca tog korisnika, što znači da će se prilikom pokretanja glavne aktivnosti upisati novi, ažurirani token. Ukoliko se dogodila promjena tokena, a korisnik je prijavljen u sustav, u „OnTokenRefresh()“ se odmah ažurira token i upisuje nova vrijednost u bazi podataka budući da je poznat korisnik i njegov jedinstveni ključ.
1. public override void OnTokenRefresh() { 2. base.OnTokenRefresh();
CASE2019 37
3. Android.Util.Log.Debug("Refreshed Token:", FirebaseInstanceId.Instance.Token); 4. FirebaseUser users = FirebaseAuth.GetInstance(loginActivity.app).CurrentUser; 5. if (users != null) { 6. id = users.Uid; 7. var firebase = new FirebaseClient(loginActivity.FirebaseURL); 8. var item = firebase.Child("tokens").Child(id).PutAsync < string > (FirebaseInstanceId.Instance.Token); 9. } else { 10. var instanceId = FirebaseInstanceId.Instance; 11. instanceId.DeleteInstanceId(); 12. } 13. }
Time je završen proces dohvata i upisa tokena uređaja i aplikacija nastavlja s normalnim izvođenjem. Druga bitna stavka vezana uz token, ali i ključna za primanje obavijesti putem Firebase Cloud Messaging, jest klasa „MessagingService“. Potrebno je kreirati klasu proizvoljnog naziva, u ovom slučaju „myMessagingServerice“ te zatim naslijediti (engl. Inherit) svojstva i atribute iz ranije spomenute klase.
1. class MyFirebaseMessagingService: FirebaseMessagingService { 2. 3. public override void OnMessageReceived(RemoteMessage message) { 4. base.OnMessageReceived(message); 5. SendNotification(message.GetNotification().Body); 6. } 7. private void SendNotification(string body) { 8. 9. var intent = new Intent(this, typeof(MainActivity)); 10. intent.AddFlags(ActivityFlags.ClearTop); 11. var pendingIntent = PendingIntent.GetActivity(this, 0, intent, PendingIntentFlags.OneShot); 12. var defaultSoundUri = RingtoneManager.GetDefaultUri(RingtoneType.Notification); 13. var notificationBuilder = new NotificationCompat.Builder(this).SetContentTitle("Moj servis obavijest").SetContentText(body).SetSmallIcon(Resource.Drawable.ifsedan285810).SetAutoCancel(true).SetSound(defaultSoundUri).SetContentIntent(pendingIntent); 14. 15. var notificationManager = NotificationManager.FromContext(this); 16. notificationManager.Notify(0, notificationBuilder.Build()); 17. } }
Nakon nasljeđivanja klase, potrebno je prepisati pravila metode „OnMessageReceived()“ čime se definira ponašanje aplikacije prilikom primanja obavijesti. Spomenuta metoda dalje poziva metodu „SendNotification()“ u kojoj su definirani svi potrebni parametri za primanje poruke kao što je zvuk dolazne poruke i slična ponašanja. Neki od ovih parametara mogu biti prepisani ukoliko su drugačije zadani od pošiljatelja obavijesti. Primjerice, pošiljatelj obavijesti može definirati naslov i sadržaj tijela obavijesti kako želi. Prikaz pristigle obavijesti na mobilnoj aplikaciji namijenjenoj klijentima ilustriran je na slici 11.
Slika 11. Prikaz pristigle obavijesti na mobilnoj aplikaciji namijenjenoj klijentima [1]
38 CASE2019
4. ANDROID MOBILNA APLIKACIJA NAMIJENJENA RUKOVODSTVU AUTOSERVISA
Android aplikacija namijenjena vodstvu autoservisa svojevrsno je proširenje dvije prethodno navedene aplikacije. Dok se ranije spomenute aplikacije orijentiraju isključivo na rad s klijentima, mobilna aplikacija za vodstvo autoservisa namijenjena je za praćenje poslova autoservisa, odnosno za evidenciju suradnje s pojedinim partnerima. Razvojno okruženje korišteno za razvoj aplikacije je Android Studio, a programski jezik korišten za programiranje aplikacije je Java. Aplikacija kao bazu podataka koristi udaljenu MySQL bazu podataka koja se nalazi na poslužitelju. Ova aplikacija također ima zaslon za prijavu koja ne nudi mogućnost registracije već korisničko ime i lozinku dostavlja programer aplikacije. Zaslon za prijavu, osim klasičnih polja za prijavu, nudi također i mogućnost pamćenja prijave kako bi se izbjeglo kontinuirano upisivanje lozinke. Prijava se provodi kroz funkciju „authUser()“ koristeći Volley API. Instanciranjem Volley klase predajemo informacije koje je korisnik upisao i šaljemo ih na poslužitelj. Kako bismo to napravili, potrebno je napraviti klasu kroz koju se spajamo na poslužitelj i pomoću koje šaljemo parametre.
1. public class login_request extends StringRequest { 2. private static final String LOGIN_URL = "https://test.hr/notes/login.php"; 3. private Map<String, String> params; 4. public login_request(String username, String password, Response.Listener<String> listene
r){super(Request.Method.POST, LOGIN_REQUEST_URL, listener); 5. params= new HashMap<>(); 6. params.put("username", username+""); 7. params.put("password", password); } 8. @Override 9. public Map<String, String> getParams(){ 10. return params; 11. }
Nakon toga poziva se „AuthUser()“ funkcija gdje se aplikacija spaja na poslužitelj i preuzima poruku o (ne)uspješnosit autentifikacije.
1. private void authUser () { 2. Response.Listener<String> responselistener = new Response.Listener<String>(){ 3. @Override 4. public void onResponse(String response) { 5. try { 6. JSONArray jsonresponse = new JSONArray(response); 7. if(jsonresponse.length() > 0) userAuthenticated = true; 8. 9. for (int i = 0; i < jsonresponse.length(); i++) { 10. JSONObject Jasonobject = new JSONObject(); 11. Jasonobject = jsonresponse.getJSONObject(i); 12. user.setFirstname(Jasonobject.getString("firstname")); 13. user.setLastname(Jasonobject.getString("lastname")); 14. user.setUsername(Jasonobject.getString("username")); 15. user.setPassword(Jasonobject.getString("password")); 16. user.setId(Jasonobject.getInt("id")); 17. } 18. } catch (JSONException e) { 19. Log.e("shit", e.getMessage()); 20. userAuthenticated = false; 21. } 22. if(userAuthenticated) getPartnerData(); 23. if(!userAuthenticated)throwBadAuthDialog(); 24. } 25. }; 26. Response.ErrorListener errorListener = new Response.ErrorListener(){ 27. @Override 28. public void onErrorResponse(VolleyError error) { 29. progressDialog.dismiss(); 30. } 31. }; 32. login_request loginRequest = new login_request(username, password, responselistener, err
orListener); 33. RequestQueue queue = Volley.newRequestQueue(login_activity.this); 34. queue.add(loginRequest); 35. }
Za razliku od Firebase Auth tehnologije, u ovom je slučaju sve provedeno ručno – od preuzimanja parametara do usporedbe podataka s podacima u MySQL bazi podataka. Kao što je vidljivo u gore prikazanom kodu, aplikacija se spaja na poslužitelj na PHP datoteku „login.php“ koja izgleda ovako:
1. <?php 2. header('Content-type: text/html; charset=utf-8'); 3. $con = mysqli_connect("localhost", "test_wp830", "a14b14c14ABC", "test_notes");
CASE2019 39
4. mysqli_query($con, "SET NAMES 'utf8'"); 5. $username = $_POST["username"]; 6. $password = $_POST["password"]; 7.
$sql=mysqli_query($con, "SELECT id, username, password, firstname, lastname FROM users WHERE username= '$username' AND password = '$password' ");
8. $response = array(); 9. while($row=mysqli_fetch_assoc($sql)) 10. $output[]=$row; 11. print(json_encode($output)); 12. echo $output; 13. mysqli_close($con); 14. ?>
Nakon prijave, korisnik ulazi u glavni izbornik aplikacije koji prikazuje listu dodanih partnera, gumb za dodavanje novih partnera te padajući izbornik koji otvara gumb za odjavu. Dugim dodirom omogućeno je i brisanje te uređivanje partnera dok se klasičnim odabirom partnera otvara pregled informacija o partneru (slika 12) kao što su ukupno potraživanje, dugovanje, ukupni saldo te vozila koja je taj partner popravljao. Podaci o korisniku, partneru, vozilima, financijama i slično, preuzimaju se samo prilikom otvaranja glavne aktivnosti (eng. Main Activity) dok se u druge aktivnosti ti isti podaci prosljeđuju kroz tu istu glavnu aktivnosti. Takva metoda je korištena zbog ubrzavanja rada aplikacije kako se ista ne bi morala konstantno spajati na poslužitelj. Moguće je poslati jednu informaciju (primjerice naziv odabranog vozila) ili cijeli objekt (primjerice naziv, vrsta i cijena vozila). Za slanje cijelih objekata između aktivnosti ili fragmenata potrebno je u klasi implementirati sučelje (eng. Interface) „Serializable“.
1. Intent intent = new Intent(MainActivity.this, viewPartnerActivity.class); 2. intent.putExtra("user", user); 3. intent.putExtra("payment", payment); 4. intent.putExtra("partner", partner); 5. intent.putExtra("car", car); 6. intent.putExtra("firstname", partner.firstnameList.get(i)); 7. intent.putExtra("lastname", partner.lastnameList.get(i)); 8. intent.putExtra("email", partner.emailList.get(i)); 9. intent.putExtra("phone", partner.phoneList.get(i)); 10. intent.putExtra("id", partner.idList.get(i)); 11. startActivityForResult(intent,1);
Podaci se u pozvanoj aktivnosti (ili fragmentu) preuzimaju na sljedeći način:
1. partner.setFirstname(getIntent().getStringExtra("firstname")); 2. partner.setLastName(getIntent().getStringExtra("lastname")); 3. partner.setEmail(getIntent().getStringExtra("email")); 4. partner.setPhone(getIntent().getStringExtra("phone")); 5. partner.setId(getIntent().getIntExtra("id",0)); 6. user = (com.delinger.antun.notesjava.Objects.user) getIntent().getSerializableExtra("user");
Slika 12. Pregled partnera [1]
Gumb „Dodaj novo vozilo“ otvara novi fragment u kojemu je moguće dodati novo vozilo i sve pripadajuće informacije kao što je datum zaprimanja, cijena, opis kvara i slično. Podaci se u bazu podataka upisuju na sličan način kao u slučaju prijave – potrebna je klasa pomoću koje se definira lokacija poslužitelja te je potrebna PHP datoteka na poslužitelju koja će upisivati podatke u bazu podataka na tom istom poslužitelju. Podaci koje korisnik upisuje u potrebna polja prvo su spremljeni unutar objekta „Car“ u radnoj memoriji, a zatim su poslani na poslužitelj.
1. <?php 2. header('Content-type: text/html; charset=utf-8');
40 CASE2019
3. $link = mysqli_connect("localhost", "autotoni_wp830", "a14b14c14ABC", "autotoni_notes");
4. $timezone = date('Y-m-d H:i:s', time()); 5. $carname = $_POST["carname"]; 6. $requiredWork = $_POST["requiredWork"]; 7. $receiveddate = $_POST["receivedDate"]; 8. $dispatchdate = $_POST["dispatchDate"]; 9. $idString = $_POST["partnerID"]; 10. $costString = $_POST["carCost"]; 11. $partnerID = (int)$idString; 12. $cost = (int)$costString; 13. if($link === false){ 14. die("ERROR: Could not connect. " . mysqli_connect_error());} 15. $sql = "INSERT INTO cars (name, requiredWork, receiptDate, dispatchDate, partnerID, cost
) VALUES ('$carname', '$requiredWork', '$timezone', '$dispatchdate', '$partnerID', '$cost')";
16. if(mysqli_query($link, $sql)){ 17. print json_encode(array(array('rezultat' => '1'))); } else{ 18. print json_encode(array(array('rezultat' => '0'))); } 19. mysqli_close($link); 20. ?>
Kao što je vidljivo u gore prikazanom kodu, PHP skripta preuzima informacije s mobilne aplikacije te temeljem njih vrši upis u bazu podataka. Upis i čitanje podataka u ostalim dijelovima aplikacije izvršeno je na sličan način. Nakon dodavanja vozila, informacije o istom vidljive su u listi na toj istoj stranici. Odabirom vozila, moguće je isto obrisati, ali je također moguće dobiti i detaljnije informacije o vozilu koje su ranije upisane. Ukoliko je vozilo odabrano, otvara se fragment s prikazom informacija (slika 13). Kroz fragment je moguće provjeriti informacije, ali i označiti vozilo završenim, što u bazu podataka upisuje podatak da je vozilo završeno, upisuje se datum predaje (datum u trenutku dodira na gumb) te se izjednačavaju financijski podaci na dugovnoj i potražnoj strani.
Slika 13. Pregled informacija o vozilu [1]
Odabirom gumba „Uplate“ (u prozoru za pregled partnera) otvara se prozor s prikazom svih uplata (slika 14) pojedinog partnera, iznosima uplata te datumima uplata. Dodatno, moguće je dodati novu uplatu kroz koju se definira vozilo uplate, partner na kojeg se odnosi te sami iznos uplate. Nadalje, dugim dodirom moguće je pojedinu uplatu po potrebni dodatno urediti ili konačno i obrisati.
Slika 14. Pregled informacija o uplatama partnera [1]
CASE2019 41
5. ZAKLJUČAK
Svaki se poslovni subjekt u današnje vrijeme, ukoliko želi opstati na tržištu, mora prilagoditi novim tehnologijama i novim načinima pristupa poslovanju. Jedan od načina takvoj prilagodbi je pružanje usluge naručivanja putem mobilnih aplikacija. Uzimajući u obzir rastuću popularnost pametnih telefona, upravo su oni potencijalno najbitnija platforma za uspostavljanje komunikacije s klijentima. Sustav za upravljanje radom autoservisa omogućava upravo to – naručivanje novih termina, olakšavanje i ubrzavanje poslovnog procesa te, u konačnici, bolje korisničko iskustvo. Android operativni sustav najrasprostranjeniji je operativni sustav i samim time aplikacija razvijena za ovaj sustav predstavlja optimalnu platformu budući da pokriva većinu tržišnih potreba.
Sustav za upravljanje radom autoservisa ima nekoliko prednosti. Prvo, autoservisu će vrlo brzo vratiti uložena sredstva u obliku povećanog prometa zbog porasta konkurentske prednosti što će rezultirati i boljim financijskim rezultatima. Druga prednost ogleda se u ubrzanju i olakšanju poslovnih procesa – izbjegnuti su nepotrebni fizički dolasci klijenata i telefonsko pregovaranje. Vodstvo autoservisa u mogućnosti je kroz jednu obavijest dobiti sve informacije o potrebnom zahvatu na vozilu kao i sve informacije vezane uz vozilo koje treba popraviti što omogućava bržu pripremu kako dijelova, tako i kadrova sposobnih za obavljanje konkretnog zadatka. Konačno, servis može na jednom mjestu držati sve bitne informacije vezane uz klijente, a klijentima je s druge strane olakšana evidencija izvršenih poslova.
Literatura:
1 Delinger, A.: Razvoj sustava za upravljanje radom autoservisa, diplomski rad. Fakultet ekonomije i turizma „Dr. Mijo Mirković“, Sveučilište Jurja Dobrile u Puli, Pula, 2018. godine.
Podaci o autorima:
Antun Delinger, mag.oec.
e-mail: [email protected]
Antun Delinger je 2018. godine stekao akademsko zvanje magistra ekonomije na Fakultetu ekonomije i turizma „Dr. Mijo Mirković“ Sveučilišta Jurja Dobrile u Puli. Nakon završenog studija, zaposlio se kao programer Android aplikacija. Glavno područje interesa mu je razvoj mobilnih aplikacija za Android operativni sustav, a jezici u kojima aktivno radi su C# i Java. U slobodno vrijeme proučava druge platforme i uči nove tehnologije.
doc.dr.sc. Tihomir Orehovački
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. Od 1. listopada 2015. godine zaposlen je na radnom mjestu docenta na Fakultetu 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 89 znanstvenih radova objavljenih u zbornicima međunarodnih konferencija, časopisima i knjigama te 13 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 12 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 IntelligentUserInterfaces (IUI), International Conference on theQualityofInformationand Communications Technology (QUATIC) - Track on Qualityin Web Engineering, International Conference on Information Technology (ICIT) te International Conference on Software and Information Engineering (ICSIE). 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-LearningTaskForce, Institute ofElectricaland 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 65 studenata obranilo završne i diplomske radove.
Fakultet informatike Sveučilište Jurja Dobrile u Puli Rovinjska 14, 52100 Pula fipu.unipu.hr
42 CASE2019
CASE2019 43
PREGLED MOGUĆNOSTI ZAŠTITE IZVORNOG PROGRAMSKOG KODA
Hrvoje Španja, dr.sc. Marin Kaluža, Sabrina Šuman
SAŽETAK
Izvorni programski kod je autorsko dijelo pojedinca ili grupe pojedinaca tj. tvrtke. Svaki aplikativni softver učitava izvorni programksi kod iz izvršne datoteke u memoriju računala prilikom izvršavanja funkcija aplikativnog softvera. Zbog toga je izvorni programski kod dostupan napadačima koji ga raznim aktivnostima mogu neovlašteno pročitati i iskoristiti za pronalaženje slabosti aplikativnog softvera ili za neovlašteno korištenje u dijelovima svoga softvera. Opisuju se razne metode zaštite izvornog programskog koda za različite programske jezike, i objašnjavaju se njihove prednosti i nedostaci u odnosu na ostale. Uspoređuju se mogućnosti čitanja izvornog programskog koda nakon primjene opisanih metoda zaštite. Predlaže se najsigurnija metoda zaštite izvornog programskog koda za analizirane programske jezike.
ABSTRACT
The source code is an authored work of an individual or group i.e. a company. Each application software loads the program's source code from the executable file to the computer's memory when executing functions in the application (software). Because of that, the source code is available to attackers who may read and use it for various activities to find the software weaknesses or for unauthorized use of parts in their software solutions. Various methods of protecting the original program code are described for different programming languages, and their advantages and disadvantages are explained in relation to the others. The possibilities of reading the original program code without and with application of described protection methods for original program code are shown. The safest method for protecting a source code of the software on analyzed programming languages are suggested.
1. UVOD
Problem koji se istražuje u radu je zaštita kompajliranog programskog koda. Izvorni programski kod je intelektualno vlasništvo pojedinca, grupe pojedinaca ili trvrtke za koju pojedinac ili grupa pojedinaca rade. Izvorni programski kod se mora izvršavati u nepoznatom okruženju i potrebno ga je zaštititi. Izvorni programski kod se može kompajlirati u izvršnu programsku datoteku i izvršavati na klijentskom računalu ili može biti interpretiran na serveru. Vlasnik aplikacijskog softvera nije vlasnik servera na kojem se izvodi aplikacijski softver i nije vlasnik klijentskog računala na kojem se izvodi klijentska verzija aplikacijskog softvera. Ako klijent ne zaštiti dovoljno dobro svoj server ili računalo, napadač može ukrasti izvršnu datoteku aplikacijskog softvera, a potom izvršnu datoteku može dekompajlirati i izvorni programski kod može iskoristiti u izradi svog aplikacijskog softvera ili pronaći ranjivosti i iskoristiti ih za krađu podataka klijenata.
Cilj rada je određivanje sigurnijeg programskog jezika između različitih tehnologija, analizirajući programske jezike koji koriste kompajlere i prevode kod u izvršni kod, i interpreterske programske jezike koji se ne prevode u programski kod već se izvršavaju bez kompajliranja. Sigurniji programski kod je onaj programski kod koji tijekom izvršavanja aplikativnog softvera izlaže svoj izvorni programski kod napadaču u što nečitljivijem obliku.
U radu će se pokazati da se korištenjem različitih metoda kompajliranja i kriptiranja izvršnog programskog koda može smanjiti rizik otkrivanja izvornog programskog koda.
Analizirat će se programski jezici koji koriste kompajlere za prevođenje izvornog programskog koda u izvršni programski kod i interpreterski programski jezici koji se izvršavaju bez kompajliranja programskog koda. Analizirat će se različiti postupci kompajliranja programskog koda kod programskih jezika koji koriste kompajlere i različite metode kriptiranja programskog koda kod interpreterskih jezika. Analizirat će se sigurnost izvršnog programskog koda u smislu dali ga je moguće dekriptirati i ako je moguće, dali rezultat dekriptiranja odgovara izvornom programskom kodu.
2. PROGRAMSKI JEZICI
Programski jezik je je set gramatičkih pravila za davanje instrukcija računalu da izvrši specifičan zadatak. Izvorni programski kod pisan u nekom programskom jeziku se prevodi u strojni jezik pomoću postupaka kompajliranja ili interpretiranja.
2.1 Prevođenje izvornog programskog koda kompajliranjem
Izvorni programski kodovi obično se pohranjuju u, čovjeku razumljive za čitanje, datoteke s raznim nastavcima, koji asociraju povezanost datoteke s programskim jezikom i čitljive su programerima. Izvorni programski kod napisan u java programskom jeziku pohranjuje se u „ .java“ datotekama , kod napisan u c# programskom jeziku pohranjuje se u „ .cs“ (Csharp) datotekama, kod napisan u c++ programskom jeziku pohranjuje se „.c“,“.cc“,“.cpp“ ovisno o razvojnom
44 CASE2019
okruženju. Navedeni programski jezici izvorni programski kod kompajliraju u izvršne datoteke poput „.class“ kod jave , „exe“ i „dll“ kod c# i c++ programskog jezika . Kompajlirani izvorni programski kod ima svoje specifikacije i različito se kompajlira.Kompajlirani izvorni programski kod napisan u java programskom jeziku sadrži binarni zapis izvornog programskog koda (bytecode). „Bytecode“ je objektno orijentirani kompajlirani kod koji se izvršava na java virtualnoj mašini. Osnovni način kompajliranja programskog koda napisanog u java programskom jeziku je korištenjem Javinog kompajlera „javac“.
Kod kompajliranja java programskog koda, često se kompajlirane klase kompresiraju i zajedno pohranjuju u datoteku s nastavkom „.jar“ ( Java Archive ). Iako takav tip datoteke služi samo za arhiviranje izvršnih datoteka java programskog jezika, java arhiva se može kriptirati i tako zaštititi izvršne java programske datoteke, ali u tom slučaju korisnik mora napisati klasu koja zna učitati sadržaj java arhivske datoteke u memoriju.
C# izvorni programski kod kompajlira se u „srednji jezik“ (intermediate language - IL ) koji odgovara CLI specifikacijama.
CLI je kratica za „common language infrastructure“ tj. internacionali standard koji je baza za izvršno i razvojno okruženje u kojima programski jezici i biblioteke rade neprimjetno zajedno. Komercijalna verzija CLI-a je virtualni sustav za izvršavanje tj. CLR (common language runtime). IL kod se sprema na disk u izvršnu biblioteku (assembly) s nastavkom „exe“ ili „dll“.
Prilikom pokretanja izvršne datoteke napisane u c# programskom jeziku biblioteka se učitava u CLR, ako su svi sigurnosni zahtjevi zadovoljeni,CLR izvodi „upravo na vrijeme“ (Just in time – JIT) kompilaciju koja prevodi IL kod u nativne instrukcije mašini. C# izvršna datoteka se može izvršavati samo unutar Microsoftovog .NET frameworka. „.NET Framework „ je razvojna platforma za izradu aplikacija za internet,windows-e,windows mobitele itd [4].
Java i C# programski jezici su specifični zbog toga što ih se ne može sa sigurnošću smjestiti ni u kompajlerske programske jezike, ni interpreterske zbog toga što se izvorni programski kod kompajlira u izvršnu datoteku, a potom izvršna programska datoteka koristi interpreter za izvođenje naredbi.
C++ programski jezik je objektno orijentirani programski jezik razvijen iz c programskog jezika 80 godina 20-og stoljeća. C++ programski jezik se smatra jezikom srednje razine što znači da podržava razne funkcije strojnog jezika i jezika visoke razine. Za razliku od c# programskog jezika c++ programski jezik može funkcionirati izvan „.NET frameworka“, c++ programski jezik nema „garbage collector“ i programeri brinu o memoriji sami. Kompajliranje izvornog koda napisanog u c++ programskom jeziku sastoji se od 4 koraka:
C++ preprocessor kopira uključena zaglavlja u izvorni programski kod i generira makro kod. Preprocessor će se aktivirati za svaku komandu koja započinje sa #. Naredba koja započinje sa znakom „#“ je include što znači korištenje određenih funkcionalnosti bez kopiranja izvornog programskog koda te funkcije.
Kompajliranje proširenog izvornog programskog koda u skupni (assembly) jezik za operativni sustav. Skupni kod dobiven kompajliranjem se sklapa u objektni kod za platformu Datoteke objektnog programskog koda se povezuju s datotekama biblioteka i stvara se izvršna programska datoteka
za c++ programski jezik.
2.2 Prevođenje izvornog programskog koda interpretiranjem
Interpreterski programski jezici koriste interpreter koji čita izvorni programski kod napisan u programskom jeziku visoke razine i prevodi liniju po liniju izvornog programskog koda i izvodi naredbe.
Python je interpreterski programski jezik koji podržava objektno orijentirano, strukturno i aspektno orijentirano programiranje. Python programski jezik se izvršava interpretiranjem kompajliranog izvornog programskog koda. Kao i kod prethodno navedenih programskih jezika jave i c#, python se kompajliranjem prevodi u bytecode, no za razliku od programskih jezika jave i c#, python prilikom pokretanja .py datoteke, kompajlira dijelove programskog koda po potrebi i interpretira ih. Standardni interpreter za Python je napisan u c programskom jeziku i dio je osnovnog paketa na mnogim linux operativnim sustavima.
PHP programski jezik je skriptni jezik otvorenog koda generalno korišten za razvoj web aplikacija. Za razliku od interpretiranja Pythona, kompajlirane jave i c# datoteke, php se ne interpretira klasično, od gore prema dolje, liniju po liniju. PHP izvorni programski kod se prije interpretiranja kompajlira u Bytecode, a potom se Bytecode interpretira. PHP verzije veće od 4 kompajlerom kompajliraju izvorni programski kod samo jednom prilikom prvog čitanja skripte, a potom kompajlirani izvorni programski kod sprema u memoriju da bi sljedeće korištenje koda bilo brže. Ranije verzije PHP-a su kompajlirale izvorni programski kod kod svakog izvršavanja skripte.
PHP kompajler parsira PHP izvorni programski kod u odgovarajući oblik koda razumljiv pokretačkom motoru u 4 koraka:
Micanje komentara Rješava varijable,funkcije/metode i učitava podatke u simboličke tablice Konstruira apstraktno sintaksno drvo programa ( apstraktna podjela programa) Zapisuje bytecode
PHP interpreter radi pomoću Zend engine-a ( Zend 2 u slučaju PHP 5, Zend 3 u slučaju PHP 7). Zend je motor otvorenog koda koji interpretira PHP izvorni programski kod. Zend motor napisan je u c programskom jeziku i pruža php-u podršku u upravljanju memorijom, resursima i ostalim standardnim servisima za PHP jezik.
3. KORIŠTENI ALATI I METODE
Obfuskacija je proces izmjene izvornog programskog koda tako da ne bude više koristan napadaču ali da izvršni programski kod bude funkcionalan tj. da funkcionira na način kao i prije obfuskacije. Informacije što su obfuscatori, kako rade i kako ih koristiti moguće je pronaći na izvoru [6]. Na navedenom izvoru objašnjena je uloga obfuscatora za sigurnost aplikativnog softvera, argumentirani su razlozi zašto koristiti obfuscatore i kako.
CASE2019 45
„yGuard“ Obfuscator je besplatni obfuscator za java izvorni programski kod. Detalji o obfuscatoru i upute kako ga koristiti mogu se pronaći na izvoru [7]. Navedni izvor sadrži upute za instalaciju obfuscatora, primjere implementacije obfuscatora i ant biblioteke.
Nativni kompajler je kompajler koji kompajlira izvorni programski kod u strojni (binarni) kod, za tehnologiju na kojoj je pokrenut [8]. Izvorni programski kod mora se kompajlirati pomoću nativnog kompajlera za svaki pojedinačni operativni sustav kojeg korisnik koristi i za svaku hardwersku arhitekturu.
GCC nativni kompajler je besplatni nativni kompajler otvorenog koda [9]. Navedeni izvor sadrži informacije o GCC nativnom kompajleru, linkove do različitih verzija kompajlera i linkove koji sadrže detaljnu dokumentaciju, upute za instalaciju, itd.
Excelsior JET je komercijalni nativni kompajler za izvorni programski kod napisan u java programskom jeziku . Excelsior JET nudi 90 dana probnog rada [10]. Excelsior JET je nativni kompajler sa velikim brojem referenci tko koristi navedeni nativni dekompajler.
Zend Guard enkoder je komercijalni enkoder koji nudi mogućnost testiranja proizvoda 30 dana. Zend Guard enkoder posjeduje posebne metode enkriptiranja koje zahtjevaju posebne metode dekriptiranja enkriptiranog izvornog programskog koda [14]. Dokumentacija kako koristiti Zend Guard alat dostupan je u izvoru [15].
Online JavaScript obfuscator služi sa obfusciranje izvornog programskog koda napisanog pomoću JavaScripta [19].
Visual Studio je IDE za pisanje izvornog programskog koda za Android, Windows, web, claud aplikacije [25].
„SnowMan“ dekompajler je dekompajler za izvršne programske datoteke kompajlirane iz izvornog programskog koda napisanog c++ programskim jezikom [22].
IsDebuggerPresent metoda služi za programsko onemogućavanje debugiranja [25], a dio je „Windows headera“ [26].
Uncompyle6 je Pythonova nativna biblioteka za prevođenje Python bytecode-a u izvorni programski kod [31].
Python installer je pythonova nativna biblioteka koja čita napisane Python skripte te ih uz ostale potrebne module i Python interpreter stavlja u jednu datoteku ili izvršnu datoteku [28].
py2exe je Pythonova ekstenzija koja pretvara Pythonove skripte u izvršni Windows program [29].
„python-exe-unpacker-master“ je python (skripta) dekompajler otvorenog koda dostupan na GitHub-u, a posjeduje metode automatskog detektiranja načina kompajliranja Python skripti u izvršnu datoteku [30].
Cyclon je statički kompajler za Python programski jezik i Cythonov programski jezik. Cyclon kompajler prevodi python izvorni programski kod u c programski kod [33].
Pyarmor je alat koji se koristi pomoću naredbenog retka za obfuskaciju python izvornog programskog koda [32].
Pyminifier je pythonov modul za umanjivanje, obfusciranje i kompresiranje pythonovog izvornog programskog koda [34].
4. ANALIZA
Analizirat će se programski jezici koji koriste kompajlere za prevođenje izvornog programskog koda u izvršni programski kod, i interpreterski programski jezici koji se u trenutku poziva kompajliraju, te interpretiranjem izvršavaju.
4.1 Zaštita izvornog programskog koda za „kompajlerske“ programske jezike
Analizirati će se programski jezici koji zahtjevaju kompajliranje izvornog programskog koda u kod razumljiv računalu prije izvršavanja naredbi. U ovom odlomku analizirati će se zaštita Java izvornog programskog koda i c++ izvornog programskog koda.
Izvorni programski kod napisan u java programskom jeziku
Za potrebe rada kreirane su dvije klase s odgovarajućim metodama i varijablama u java programskom jeziku. Prilikom pisanja izvornog programskog koda programer može povećati sigurnost aplikativnog softvera pisanjem „glupih“ funkcija (eng. Dummy functions). Dummy funkcije su one funkcije koje ne rade ništa ili gotovo ništa tj. ne utječu na rad aplikativnog softver-a, a postoje jedino da bi se zbunio napadač. U slučaju povećavanja zaštite izvornog programskog koda pomoću „glupih funkcija“, funkcije se postavljaju prije i poslije metoda i tako zbunjuju napadača. Ovakav način zaštite izvornog programskog koda može se koristiti u bilo kojem programskom jeziku, ne povećava značajno sigurnost izvornog programskog koda ali može zbuniti i otežati posao napadaču.
Rezultat kompajliranog izvornog programskog koda pomoću javinog „javac“ kompajlera je Bytecode klasa nastavka .class.
Slika 2. Prikaz kompajliranog izvornog programskog koda javac kompajlerom Izradio autor
46 CASE2019
Iako kompajlirane, klase daju naslutiti strukturu izvornog programskog koda. U kompajliranoj klasi „HelloWorldClass“ vidljivo je da se u izvornom programskom kodu koriste varijable „helloWorld“ i helloWorld2“ tipa „String“, get i set metode za varijablu „helloWorld“. Kompajliranjem veće količine izvornog programskog koda bez ikakve zaštite rezultiralo bi velikom količinom podataka u „plain text“ obliku što omogućuju napadaču lakše ugrožavanje sigurnosti aplikacijskog softver-a.
Ovako kompajliran izvorni programski kod napisan u java programskom jeziku dekompajliran je besplatnim dekompajlerom otvorenog koda „jd-gui“-em. Rezultat dekompajliranja je originalni izvorni programski kod što znači da je takva metoda zaštite izvornog programskog koda nesigurna. Bytecode verzija izvornog programskog koda može odbiti neiskusnog napadača, ali napadač s dovoljno iskustva će lako doći do informacija koje ga zanimaju. Izvorni programski kod se prilikom kompajliranja arhivira u javinu arhivsku datoteku (jar). U radu je takva arhiva kreirana sa Eclipse IDE(Integrated Development Environment. Arhivska datoteka se može otvoriti bilo kojim programom za otvaranje arhivskih datoteka i sadrži identične kompajlirane klase koje su prikazane na slici br.1. Jd-gui nema problema sa dekompajliranjem tako kompajliranog izvornog programskog koda.
Za povećanje sigurnosti java izvornog programskog koda često se koriste java obfuskatori. Detalji o obfuskatorima i procesu Obfuskacije pojašnjeni su u poglavlju 3. Za potrebe rada korišten je „yGuard“ Obfuscator, opisan u poglavlju 3. „yGuard“ Obfuscator se koristi u kombinaciji s Javinom bibliotekom „Ant“ prilikom kompajliranja izvornog programskog koda. Prema dokumentaciji yGuard Obfuscatora postavljeno je kompajliranje izvršnog programskog koda u izvršnu datoteku pomoću ant biblioteke, s i bez Obfuscatora. Uz kreirane izvršne datoteke ostavljena je izvršna datoteka kreirana kroz eclipse IDE.
Dekompajliranje obfuscirane izvršne datoteke HelloWorld_obf.jar pomoću jd-gui-a ne prikazuje izvorni programski kod, dok smo ranije vidjeli da dekompajliranje izvršne datoteke kreirane pomoću čarobnjaka dostupnog u Eclipse-u omogućuju uvid u izvorni programski kod. Razlog zašto jd-gui nije uspio dekompajlirati izvršnu datoteku HelloWorld_obf.jar leži u činjenici da ant biblioteka koristi javac biblioteku za kompajliranje izvornog programskog koda u izvršnu datoteku dok Eclipse koristi svoj kompajler. Ako obfuscirana javina arhiva HelloWord_obf.jar raspakira, jd-gui uspješno dekompajlira izvršne datoteke u izvorni programsko kod, no zbog obfuscatora dekompajlirani izvorni programski kod u izvršnoj datoteci HelloWorld_obf.jar razlikuje se od originala u nazivima metoda, klasa, paketa itd. Iako izmijenjene klase, napadaču otkrivaju ponašanje aplikacije. Napadač može spremiti obfuscirani izvorni programski kod, kreirati projekt iz dekompajliranog izvornog programskog koda i ručno analizirati funkcije, varijable i vratiti ih u originalno stanje.
Jedan od načina zaštite izvornog programskog koda je korištenjem nativnog kompajlera, opisanog u poglavlju 3. Osim povećanja sigurnosti u smislu otežavanja dekompajliranja izvršne datoteke u izvorni programski kod, izvršna datoteka kompajlirana nativnim kompajlerom pruža brže izvođenje koda, bolje upravljanje memorijom i dosta drugih prednosti, no gubi se smisao korištenja java programskog jezika gdje se izvorni programski kod kompajlira jedanput za više platformi (eng. „Cross compilers“). Jedan od najkorišteniji besplatnih nativnih kompajlera je „GCC“, no za potrebe rada korišten je „Excelsior JET“ (U daljnjem tekstu JET) .
Nativni kompajler ne kompajlira izvorni programski kod nego izvršni kod, stoga je prilikom kompajliranja izvršne datoteke potrebno odabrati putanju do izvršne datoteke, navesti glavnu (main) klasu i Classpath. Ako izvršna datoteka zahtjeva ulazne parametre moguće je i njih dodati.
Slika 3. Prikaz formi nativnog kompajlera Excelsior JET Izradio autor
Nakon podešavanja parametara kompajlera, izvorni programski kod se kompajlira u binarni kod, tj. u izvršnu datoteku s nastavkom „.exe.“. Izvršna datoteka se može pokretati dvoklikom na datoteku ili pozivom iz naredbenog retka.
Pomoću jd-gui dekompajlera je nemoguće dokompajlirati i dobiti izvorni programski kod iz izvršne datoteke kompajlirane nativnim kompajlerom. Za dobivanje nativnog koda generiranog iz izvornog koda naše java aplikacije potrebno je koristiti nativni dekompajler. Proces kako dobiti i zaštiti izvorni programski kod iz izvršne datoteke koja sadrži binarni kod objašnjen je u nastavku.
Izvorni programski kod napisan u c++ programskom jeziku
Način kompajliranja izvornog koda napisanog u c++ programskom jeziku je objašnjen u ranijim dijelovima rada. Za potrebe rada napravljena je c++ aplikacija koja se pokreće kroz naredbeni redak. Za pisanje izvornog programskog koda korišten je Visual Studio IDE(u daljnjem tekstu VS), objašnjen u poglavlju 3.
CASE2019 47
Slika 4. C++ izvorni programski kod Izradio autor
Kreirani c++ izvorni programski kod kompajlira se u izvršnu datoteku sa ekstenziojom „.exe“ koja sadrži binarni kod tj. kod razumljiv stroju na kojem je izvorni kod kompajliran. Tako kompajliran izvorni programski kod je teže dekompajlirati od izvornih programskih kodova napisanih programskim jezicima koji koriste „srednji jezik“ (bytecode, net framework, mono...). Dekompajliranje binarnog koda u originalni izvorni programski kod nemoguće je, ali je moguće dobiti assembly programski kod.
Slika 5. Dekompajlirani c++ izvorni programski kod Izradio autor
Za dekompajliranje aplikativnog softver-a napisanog u c++ programskom jeziku korišten je dekompajler „SnowMan“, opisan u poglavlju 3. Rezultat dekompajliranog aplikativnog softvera je assembly programski kod prikazan na slici br. 4, gdje su označena dva dijela dekompajliranog programskog koda aplikativnog softvera, a to su: dio koji prikazuje korisniku tekst „Write number“ i funkciju koju poziva main metoda.
Osim dekompajlera napadač može koristiti i debugger ( računalni program koji služi za pronalaženje grešaka i testiranje izvornog programskog koda ) da bi iskoristio dijelove izvornog programskog koda napisanog u c++ programskom jeziku. Za potrebe rada korišten je debugger VS-a.
Slika 6. Prikaz debuggirane HelloWorld funkcije c++ aplikacijskog softvera Izradio autor
Na slici br. 5 prikazan je deasamblirani aplikacijski softver prilikom debuggiranja. Napadač pomoću debugger-a može vidjeti ponašanje izvornog programskog koda u realnom vremenu sa stvarnim vrijednostima što mu olakšava posao zlouporabe aplikativnog softver-a. Kod nekih programskih jezika kao što je c++, izvorni programski kod se može zaštititi od debugiranja tako da se u kod doda provjera dali se aplikativni softver ili izvorni programski kod debugira. U c++ programskom jeziku dovoljno je provjeriti vrijednost metode „IsDebuggerPresent()“. Detalji o metodi „IsDebuggerPresent“ su opisani u poglavlju 3. Programsko zabranjivanje debugiranja izvornog programskog koda neće napadača spriječiti da vidi izvorni programski kod pomoću debugera ali će mu onemogućiti kretanje kroz izvorni programski kod i proučavanje logike rada. Ovakav način zaštite izvornog programskog može otežati programeru pronalaženje greške i daljnji rad na aplikativnom rješenju.
C++ izvorni programski kod se kao i svaki drugi programski kod može obfuscirati. Obfuscator može biti automatski ili programer može sam obfuscirati izvorni programski kod. Kako obfuscator funkcionira objašnjeno je u poglavlju 4.1.
48 CASE2019
4.2 Zaštita izvornog programskog koda za „interpreterske“ programske jezike
Analizirati će se izvorni programski kodovi jezika koji koriste interpreter za prevađanje izvornog programskog koda u naredbe razumljive računalu. U ovom odlomku analizirati će se zaštita izvornog programskog koda napisanog u PHP-u i Pythonu.
Izvorni programski kod napisan u php programskom jeziku
Za potrebe rada napisan je izvorni programski kod u php programskom jeziku koji korisniku prikazuje dva teksta i tipku kojoj se tekst promjeni prilikom pritiska. Izvorni programski je spremljen u index.php datoteci, a za pokretanje php aplikacije korišten je XAMPP **web server . XAMPP web server je opisan u poglavlju 3.
Slika 7. Izvorni programski kod napisan php programskim jezikom Izradio autor
Jedan od načina zaštite izvornog koda napisanog u php programskom jeziku je pomoću obfuscatora kao što je slučaj kod drugih programskih jezika. Specifičnost kod php izvornog programskog koda je što koristi više programskih resursa uz php programski jezik, poput JavaScript††-a (u daljnjem tekstu JS), html‡‡-a, itd. JS i html su opisani u poglavlju 3. Prilikom korištenja obfuscatora moguće je da se neki dijelovi izvornog programskog koda neće obfuscirati. Za potrebe obfusciranja php izvornog programskog koda korišten je besplatni php obfuscator/encoder „Obfusc PHP 2.2.0“§§ . Navedeni alat nudi mogućnost obfusciranja izvornog programskog koda s ili bez enkodiranja. Rezultat obfusciranja php izvornog programskog je prikazan na slici br. 7.
Slika 8. Obfuscirani php izvorni programski kod Izradio autor
Na slici br. 7 vidljivo je da je obfusciran jedino php izvorni programski kod, dok je metoda napisana JS-om ostala identična originalu. JS izvorni programski kod u php skripti se može zaštiti JS obfuscatorom. JS obfuscatori su lako dostupni i jednostavni za korištenje. Za obfusciranje JS izvornog programskog koda korišten je online obfuscator opisan u poglavlju 3.
** XAMPP je besplatni web server otvorenog koda koji može raditi na svim platformama [12] .
†† JavaScript-a je skriptni jezik za web stranice [17]
‡‡ HTML je jezik za kreiranje i vizualno predstavljanje sadržaja [18].
§§ Obfusc PHP 2.2.0 je php obfuscator [16] .
CASE2019 49
Slika 9. Obfuscirani JS izvorni programski kod Izradio autor
Php interpreter nema problema s pokretanjem obfusciranog izvornog programskog koda, no obfuscirani php izvorni programski kod radi sporije od originalnog izvornog programskog koda. Obfuscirani izvorni programski kod se može deobfuscirati automatski ili ručno. Oba principa deobfusciranja izvornog programskog koda drže se sljedećih koraka:
Pronalazak algoritma koji je korišten za obfusciranje Pronalazak ključa koji je korišten za obfusciranje Deobfusciranje svakog dijela koda
Drugi način zaštite izvornog programskog koda je kompajliranje php izvornog programskog koda u .NET jezik,strojni jezik,Bytecode, java Bytecode,windows binarni jezik,c++ itd. .Kompajliranjem php izvornog programskog koda izvorni kod više nije dostupan napadaču u obliku teksta, niti je potrebno instalirati php interpreter na server.
Za kriptiranje izvornog programskog koda korišten je Zend Guard enkoder . Pomoću Zend Guard-a moguće je enkodirati, obfuscirat i licencirati izvorni programski kod. Enkodiranje izvornog programskog koda napisanog u php-u pomoću Zend Guard-a je jednostavno, prvenstveno jer Zend Guard nudi poznato grafičko okruženje Eclipse IDE-a. Na slici br. 9 vidljiv je sadržaj enkodirane index.php datoteke.
Slika 10. Enkodirani php izvorni programski kod Izradio autor
Php izvorni programski kod enkodiran pomoću Zend Guard-a ne može se interpretirati php interpreterom bez korištenja dekriptora (ZendLoader), što znači je potrebno konfigurirati xampp php da bi se aplikativni softver mogao pokrenuti u trenutnom okruženju, ili se može koristiti Zend Server za interpretiranje kriptiranog izvornog programskog koda.
Enkodirani izvorni programski kod se pokušao dekodirati s nekoliko online dekodera, no izvorni programski kod je ostao zaštićen. Zend Guard je najskuplji alat za zaštitu izvornog programskog koda korišten u ovom radu i općenito najskuplji alat za zaštitu php izvornog programskog koda. Trenutno nema dostupnih dekodera za izvorni programski kod enkodiran pomoću Zend Guard alata. Kao besplatni alat za enkodiranje php izvornog programskog koda korišten je ranije navedeni „Obfusc PHP 2.2.0“ koji nudi tipove „Basic“ i „Freelancer“ enkodiranja. Php izvorni programski kod enkodiran pomoću navedenog alata ne zahtijeva poseban interpreter za rad, već se može pokrenuti pomoću klasične instalacije php-a. Tako enkodiran izvorni programski kod se može lako dekodirati. Većina izvornog php programskog koda uspiješno je dobivena koristeći online dekodere opisane u poglavlju 3.
Slika 11. Php izvorni programski kod enkodiran basic metodom Izradio autor
Slika 12. Dekodiran php izvorni programski kod Izradio autor
Izvorni programski kod napisan u python programskom jeziku
U ranijem tekstu je objašnjeno zašto python spada u interpreterske programske jezike i kako se izvorni programski kod interpretira. Za potrebe rada napisan je aplikativni softver koji prima vrijednost korisnika i na osnovu te vrijednosti ispisuje odgovarajuću poruku. Kao i u slučaju php-a, python se može pokrenuti bez kompajliranja. Php interpreter interpretira napisani izvorni programski kod i prikazuje ga korisniku.
50 CASE2019
Osim interpretiranja tekstualne datoteke napisane python programskim jezikom, python interpreter može interpretirati Bytecode verziju izvornog programskog koda. Izvorni programski kod kompajliran u Bytecode spremljen je u datoteku s nastavkom „pyc“, naredba za kreiranje Bytecode-a je „python -m compileall HelloWorldApp.py“. Dekompajliranje Pythonove Bytecode datoteke je moguće Pythonovim nativnim modulom uncompyle6 opisanim u poglavlju 3. Naredba za dekompajliranje Bytecode datoteke je prikazana na slici br. 12.
Slika 13. Naredba za dekompajliranje izvornog programskog koda u Bytecode obliku Izradio autor
Izvorni programski kod kompajliran u Bytecode smanjuje rizik otkrivanja izvornog programskog koda, no takvu verziju izvornog programskog koda lako je dekompajlirati. Veći level zaštite izvornog programskog koda napisanog python programskim jezikom je kompajliranje python skripte u izvršnu datoteku. Izvršna datoteka sadrži strojnu verziju izvornog programskog koda i služi za pokretanje python aplikativnog softver-a bez instalacije Pythona na windows operativnom sustavu. Postoji nekoliko metoda kako kompajlirati izvorni programski kod u Python izvršnu datoteku. Za potrebe rada korišten je python installer za kreiranje izvršne datoteke iz izvornog programskog koda. Struktura izvršne datoteke nije identična izvršnim datotekama koje smo imali u radu. Izvršna datoteka aplikativnog softver-a sadrži samo jednu datoteku sa strojnim zapisom izvornog programskog koda, dok kompajliranje izvršnog programskog koda pomoću py2exe metodom tvori izvršnu datoteku sa strukturom datoteka koju smo vidjeli ranije u radu . Python installer i py2exe opisani su u poglavlju 3. Različite metode kreiranja izvršne datoteke napadaču mogu stvoriti određene probleme jer prije dekompajliranja mora saznati koja se metoda koristila prilikom kompajliranja izvornog programskog koda u izvršnu datoteku. Na internetu je moguće pronaći rješenje i za to u obliku python (skripte) dekompajlera „python-exe-unpacker-master“. Informacije o navedenom dekompajleru su u poglavlju 3.
Slika 14. Usporedba originalno Bytecode-a sa dekompajliranim Bytecodeom Izradio autor
Na slici br. 13 vidljivo je da su originali Bytecode aplikativnog softver i dekompajlirani gotovo identični što znači da napadač može dobiti izvorni programski kod dekompajliranjem Bytecode zapisa dekompajlirane izvršne datoteke. Dekompajliranje Bytecode zapisa izvornog programskog koda objašnjeno je u ranijim dijelovima poglavlja 4.2.2.
Python izvorni programski kod moguće je zaštiti pomoću „Cyclon“ kompajlera . Cyclon kompajler opisan je u poglavlju 3. Nakon prevođenja Pythona u c programski jezik moguće je kreirati binarni file. Korištenjem Cyclon-a za prevođenje Python programskog jezika u c programski jezik, ostaju komentari s izvornim programskim kodom iz Pythona. Za veću sigurnost izvornog programskog koda, prije kompajliranja izvornog programskog koda prevedenog u c programski jezik potrebno je obrisati sve komentare da bi napadaču umanjili šanse za krađu izvornog programskog koda. Izvršna datoteka kompajlirana iz c izvornog programskog koda puno je sigurnija od izvršne datoteke kompajlirane iz python izvornog programskog koda. Proces dekompaliranja c programskog jezika opisan je u poglavlju 4.1.2.
Python izvorni programski kod se može zaštititi pomoću obfuscatora. Kod se može obfuscirati automatski ili ručno. Klasični pristup obfusciranju izvornog programskog koda je opisan ranije u tekstu, u python programskom jeziku se koristi „Pyarmor“ za obfuskaciju python izvornog programskog koda. Malo drugačiji pristup obfusciranju izvornog programskog koda napisanog u python programskom jeziku je korištenjem „Pyminifier“-a . Korištenjem Pyminifier-a moguće je obfuscirati kod na vrlo komplicirani način. Jedna od zanimljivijih opcija koje se mogu koristiti prilikom obfusciranja izvornog programskog koda je „--nonlatin“ naredba koja obfuscira klase, varijable i metode izvornog programskog koda ne latinskim znakovima. Primjer obfusciranja izvornog programskog koda ne latinskim znakovima prikazan je na slici br. 39. Osim korištenja metode „nonlatin“ zanimljive su opcije „gzip“ i „lzma“ koje kompresiraju python skriptu s izvornim programskim kodom različitim algoritmima. Primjer izvornog programskog koda i naredba za kompresiranje python skripte prikazani su na slici br. 14. uz dokaz da python skripta i dalje radi kao i originalna.
CASE2019 51
Slika 15. Naredba i prikaz izvornog programskog koda obfusciranog bez latinskih znakova Izradio autor
Slika 16. Python izvorni programski kod obfusciran i kompresiran Izradio autor
Kao i kod ostalih programskih jezika obfusciranje izvornog programskog koda čini napadaču proces dekompajliranja složenijim ali ne i nemogućim.
5. DISKUSIJA REZULTATA
U radu su analizirane različite metode zaštite izvornog programskog koda različitih tehnologija. Rezultati su prikazani u tablici br. 1.
Metoda Rezultat
„Kompajlerski“ programski jezik
Java
Dummy functions Ne povećava značajno sigurnost izvornog programskog koda ali može zbuniti i otežati posao napadaču.
Kompajliranje izvornog programskog koda u Bytecode programski kod
Bytecode verzija izvornog programskog koda može odbiti neiskusnog napadača, ali napadač s dovoljno iskustva će lako doći do informacija koje ga zanimaju jer se Bytecode lako dekompajlira.
Kompajliranje Javinih klasa u Javinu arhivsku datoteku pomoću Eclipse IDE-a
Lako se dekompajlira dekompajlerom. Rezultat dekompajliranja je Javin izvorni programski kod
Kompajliranje Javinih klasa u Javinu arhivsku datoteka Javinim kompajlerom
Dekompajliranje Javine arhivske datoteke pomoću dekompajlera jd-gui-a ne prikazuje izvorni programski kod. Za dekompajliranje klasa dovoljno je raspakirati arhivsku datoteku (jar).
Obfusciranje Java izvornog programskog koda yGuard obfuscatorom
Za pravilan rad dekompajlera potrebno je raspakirati Javinu arhivsku datoteku (jar). Obfuscirani dekompajlirani izvorni programski kod razlikuje se od originalnog izvornog programskog koda u nazivima metoda, klasa, paketa itd. , što napadaču znatno otežava proces otkrivanja izvornog programskog koda
52 CASE2019
Kompajliranje izvornog programskog koda korištenjem nativnog kompajlera
Povećanja sigurnosti izvornog programskog koda tako što otežava dekompajliranja izvršne datoteke u izvorni programski kod, ne otkriva originalni programski jezik u kojem je aplikativni softver napisan, izvršna datoteka kompajlirana nativnim kompajlerom pruža brže izvođenje koda, bolje upravljanje memorijom i dosta drugih prednosti, no gubi se smisao korištenja java programskog jezika gdje se izvorni programski kod kompajlira jedanput za više platformi (eng. „Cross compilers“)
C++
Dummy functions (Glupe funkcije) Ne povećava značajno sigurnost izvornog programskog koda ali može zbuniti i otežati posao napadaču.
Kompajliranje izvornog programskog koda u izvršnu datoteku
Dekompajliranje binarnog koda u originalni izvorni programski kod je gotovo nemoguće, ali je moguće dobiti skupni(assembly) programski kod kojeg napadač može iskoristiti da rekonstruira izvorni programski kod.
Korištenje metode „IsDebuggerPresent“ u izvornom programskom kodu
Programsko zabranjivanje debugiranja izvornog programskog koda neće napadača spriječiti da vidi izvorni programski kod pomoću debugera ali će mu onemogućiti kretanje kroz izvorni programski kod i proučavanje logike rada. Ovakav način zaštite izvornog programskog može otežati i programeru pronalaženje grešaka i daljnji rad na aplikativnom rješenju.
Korištenje obfuscatora Obfuscirani dekompajlirani izvorni programski kod razlikuje se od originalnog izvornog programskog koda u nazivima metoda, klasa, paketa itd. , što napadaču znatno otežava proces otkrivanja izvornog programskog koda i razumijevanje ponašanja aplikacije.
„Interpreterski“ programski jezik
Php
Dummy functions (Glupe funkcije) Ne povećava značajno sigurnost izvornog programskog koda ali može zbuniti i otežati posao napadaču.
Obfusciranje izvornog programskog koda Potrebno je koristiti različite obfuscatore za obfusciranje različitih elemenata php-a. Često je obfuscirani izvorni programski kod nesigurniji od neobfusciranog. Napadaču znatno otežava proces otkrivanja izvornog programskog koda i razumijevanje ponašanja aplikacije.
Kompajliranje php izvornog programskog koda u strojni ili srednji jezik
Izvorni programski kod više nije dostupan napadaču u obliku teksta, niti je potrebno instalirati php interpreter na server. Od napadača je skriven izvorni programski jezik ali su izgubljene prednosti php programskog jezika. Metoda kompajliranja php izvornog programskog koda je sigurna onoliko koliko je siguran strojni ili srednji jezik u koji se php izvorni programski kod kompajlirao.
Kriptiranje izvornog programskog koda komercijalnim alatom ("Zend Guard")
Izvorni programski kod enkodiran pomoću Zend Guard-a ne može se interpretirati php interpreterom bez korištenja dekriptora (ZendLoader). Ni jedan testirani dekoder nije uspio dekodirati kriptirani programski kod u izvorni programski kod. Najsigurnija i najskuplja metoda zaštite izvornog programskog koda u php programskom jeziku. Trenutno ne postoje dekoderi koji mogu dekodirati izvornig programski kod enkodiran pomoću Zend Guard alata.
Kriptiranje izvornog programskog koda alatom otvorenog koda (Obfusc PHP 2.2.0)
Ne zahtijeva poseban interpreter za interpretiranje izvornog programskog koda. Ako napadač nije upoznat s dekoderima ili ne zna da je izvorni programski kod enkodiran ne može izvući nikakve korisne informacije iz koda. Dekoderi dostupni online daju dobre rezultate prilikom dekodiranja enkodiranog izvornog programskog koda
Python
Dummy functions (Glupe funkcije) Ne povećava značajno sigurnost izvornog programskog koda ali može zbuniti i otežati posao napadaču.
Kompajliranje izvornog programskog koda u Bytecode programski kod
Bytecode verzija izvornog programskog koda može odbiti neiskusnog napadača, ali napadač s dovoljno iskustva će lako doći do informacija koje ga zanimaju jer se Bytecode lako dekompajlira.
Kompajliranje izvornog programskog koda u izvršnu datoteku
Različite metode kreiranja izvršne datoteke napadaču mogu stvoriti određene probleme jer prije dekompajliranja mora saznati koja se metoda koristila prilikom kompajliranja izvornog programskog koda u izvršnu datoteku. Nakon dekompajliranja izvršne datoteke napadač može dekompajlirati Bytecode datoteke u izvorni programski kod.
CASE2019 53
Kompajliranje izvornog programskog koda korištenjem C kompajlera („Cyclon“) kompajlerom
Izvršna datoteka kompajlirana iz c izvornog programskog koda puno je sigurnija od izvršne datoteke kompajlirane iz python izvornog programskog koda. Proces dekompaliranja c programskog jezika opisan je u poglavlju 4.1.2. Ova metoda zaštite izvornog programskog koda zaštićuje izvorni programski kod u potpunosti jer napadač ne može znati u kojem programskom jeziku kod izvorno napisan.
Obfusciranje izvornog programskog koda(Pyarmor)
Klasični pristup obfusciranju izvornog programskog koda. Napadaču znatno otežava proces otkrivanja izvornog programskog koda i razumijevanje ponašanja aplikacije.
Obfusciranje izvornog programskog koda(Pyminifier)
Korištenjem Pyminifier-a moguće je obfuscirati kod na vrlo komplicirani način. Uz pomoć „nonlatin“ naredbe moguće je obfuscirati klase,varijable i metode izvornog programskog koda ne latinskim znakovima što napadaču koji ne poznaje ni jedno drugo pismo osim latinskog znatno otežava korištenje izvornog programskog koda.
Tablica 1 - Zaštita izvornog programskog koda
Tablica 1. Rezultati zaštite izvornog programskog koda različitim metodama zaštite.
Usporedbom različitih programskih jezika i različitih metoda za zaštitu izvornog programskog koda daje se zaključiti da su sigurniji jezici niže razine koji se kompajliraju u binarni kod razumljiv računalima. Kod razumljiv računalu nije razumljiv napadaču i napadač se mora potruditi nebi li iz izvršne datoteke dobio izvorni programski kod što je gotovo pa nemoguće.
Interpreterski programski jezici iako pohranjeni u obične datoteke sa lako dostupnim izvornim programskim kodom posjeduju veoma sigurne metode zaštite izvornog programskog koda. Kriptiranje izvornog programskog koda napisanog PHP programskim jezikom pomoću Zend Guard alata je najučinkovitija metoda zaštite izvornog programskog koda korištena u ovom radu. Obfusciranje izvornog programskog koda pomoću Pyminifier-a je druga najsigurnija metoda, a može se koristiti za zaštitu Python izvornog programskog koda. Za razliku od Obfusciranja izvornog programskog koda pomoću Pyarmor-a, Pyminifier nudi posebne opcije koje znatno otežavaju čitanje obfusciranog izvornog programskog koda.
Zaštita izvornog programskog koda korištenjem nativnog kompajlera moguća je u svim obrađenim programskim jezicima, a rezultat je izvorni programski kod koji je zaštićen od napadača koji ne znaju interpretirati assembly izvršni programski kod. Iz razloga što metoda kompajliranja izvornog programskog koda nativnim kompajlerom ukida originalne prednosti programskog jezika u kojem je napisan izvorni programski kod može se reći da je manje sigurna od metode kriptiranja izvornog programskog koda ZendGuard-om i Obfusciranja izvornog programskog koda Pyminifier-om. Klasično kompajliranje Javinog ili Pythonovog izvornog programskog koda u bytecode izvršnu datoteku je nesiguran način zaštite izvornog programskog koda. Obfusciranje izvornog programskog koda je moguće u svim programskim jezicima obrađenim u radu, a najnesigurnije je obfusciranje javinog izvornog programskog koda pomoću yGuard obfuscatora jer je izvorni programski kod lako razumljiv nakon dekompajliranja izvršne datoteke. Razne programske metode poput korištenja dummy funkcija ili prepoznavanja dali se aplikativni softver debugira su korisne i povećavaju zaštitu izvornog programskog koda, no mogu samo zbuniti napadača.
Implementiranjem nekih ili svih programskih metoda zaštite izvornog programskog koda neće zaštititi kod, ali bi mogle znatno otežati proces krađe izvornog programskog koda napadaču. Izvorni programski kod postiže najveći level zaštite ukoliko vlasnik izvornog programskog koda prilikom kreiranja izvršne datoteke koristi više različitih metoda poput obfusciranja, enkriptiranja i kompajliranja izvornog programskog koda u izvršnu programsku datoteku ili korištenjem dummy metoda i obfusciranja izvornog programskog koda.
6. ZAKLJUČAK
Svaki aplikativni softver koji se izvršava na klijentskom računalu je izložen napadačima i pokušajima napada. Krađu izvornog programskog koda ili neke funkcionalnosti nemoguće je spriječiti no moguće je zaštititi izvorni programski kod različitim metodama zaštite koje napadaču mogu znatno otežati proces krađe izvornog programskog koda. Implementacija nekih metoda zaštite izvornog programskog koda može biti jednostavna, a rezultati dobri, dok implementacija nekih metoda može biti teška, a rezultati neznačajni. Ako je aplikativni softver pisan za zatvoreno okruženja sa malim brojem prijetnji, a potrebnom za brzim izvršavanjem naredbi, programski kod se ne bi trebao štititi metodama zaštite koje će usporiti rad aplikativnog softvera. Ako je aplikativni softver pisan za okruženje gdje može biti izložen različitim napadima potrebno je izvorni programski kod zaštititi na što kvalitetniji način. Ukoliko neka od metoda zaštite povećava level zaštite izvornog programskog koda, a usporava rad aplikacije potrebno je analizirati posljedice takvog rada aplikacije i odvagnuti između sigurnosti izvornog programskog koda i zadovoljstva korisnika. Riješenje problema može ležati u odabiru drugog programskog jezika koji će svojim performansama i levelom zaštite zadovoljiti korisničku potrebu za brzim radom aplikativnog softvera i potrebu programera za zaštitom izvornog programskog koda. Osim brige oko okruženja potrebno je analizirati tko su korisnici aplikativnog softvera, te dali oni predstavljaju rizik za izvorni programski kod te na osnovu toga koristiti metode zaštite izvornog programskog koda i jezik za pisanje izvornog programskog koda.
Osim zaštite izvornog programskog koda koji se nalazi u izvršnim datotekama koje se izvršavaju na klijentski računalima potrebno je zaštiti i izvorni programski kod koji se izvršava na aplikacijskom poslužitelju. Najčešće su u pitanju web aplikacije gdje napadač do izvornog programskog koda može doći putem web preglednika. Prilikom zaštite izvornog programskog koda web aplikacije potrebno je postići što manje usporavanje rada aplikacije implementacijom različitih metoda zaštite izvornog programskog koda.
54 CASE2019
Metode za zaštitu izvornog programskog koda svakim danom su sve inovativnije, ali metode „krađe“ (dekompajliranja) izvornog programskog koda su također svakim danom sve inovativnije i često su ispred metoda koje zaštićuju izvorni programski kod. Izvorni programski kod nemoguće je zaštititi, ali moguće je zakomplicirati posao napadaču pa i do te mjere da napadač odustane od krađe izvornog programskog koda zbog preskupog procesa otkrivanja izvornog programskog koda.
Literatura;
1 Essentials, Part 1, Lesson 1: Compiling & Running a Simple Program, preuzeto sa: https://www.oracle.com/technetwork/java/compile-136656.html .[Pristupljeno: 10.02.2018].
2 Introduction to the C# Language and the .NET Framework, preuzeto sa: https://docs.microsoft.com/en-us/dotnet/csharp/getting-started/introduction-to-the-csharp-language-and-the-net-framework. [Pristupljeno: 10.02.2018].
3 https://zeljko-radicevic.from.hr/sto-je-to-programski-jezik/. [Pristupljeno: 10.02.2018].
4 .NET Framework Guide,preuzeto sa: https://docs.microsoft.com/en-us/dotnet/framework/.[Pristupljeno: 10.02.2018].
5 The C++ compilation process,preuzeto sa: http://faculty.cs.niu.edu/~mcmahon/CS241/Notes/compile.html [Pristupljeno: 12.02.2018].
6 Why Use Obfuscation,preuzeto sa: https://www.preemptive.com/obfuscation . [Pristupljeno: 12.02.2018].
7 yGuard 2.7 Ant Task Documentation, preuzeto sa: https://www.yworks.com/resources/yguard/yguard_ant_howto.html .[Pristupljeno: 13.02.2018].
8 Native commmpiler,preuzeto sa: https://www.techopedia.com/definition/8506/native-compiler .[Pristupljeno: 12.12.2018].
9 GCC, the GNU Compiler Collection, preuzeto sa: https://gcc.gnu.org/ [Pristupljeno: 12.02.2018].
10 Excelsior Jet,preuzeto sa: https://www.excelsiorjet.com/ [Pristupljeno: 13.02.2018].
11 https://stackoverflow.com/questions/12204235/does-compiling-java-to-native-code-protect-the-source-code . [Pristupljeno: 13.12.2018].
12 XAMPP,preuzeto sa: https://www.apachefriends.org/index.html [Pristupljeno: 16.12.2018].
13 https://stackoverflow.com/questions/336057/best-solution-to-protect-php-code-without-encryption [Pristupljeno: 16.12.2018].
14 Zend Guard,protect your application with PHP encoding, preuzeto sa: http://www.zend.com/en/products/zend-guard [Pristupljeno: 17.12.2018].
15 Working with Zend Guard, preuzeto sa: http://files.zend.com/help/Zend-Guard-5/working_with_zend_guard.htm [Pristupljeno: 17.12.2018].
16 Obfusc, preuzeto sa: http://www.obfusc.com/encoder_php.html [Pristupljeno: 17.12.2018].
17 JavaScript,preuzeto sa: https://developer.mozilla.org/bm/docs/Web/JavaScript .[Pristupljeno: 12.12.2018].
18 HTML, preuzeto sa: https://developer.mozilla.org/hr/docs/Web/HTML .[Pristupljeno: 12.12.2018].
19 JavaScript Obfuscator Tool, preuzeto sa: https://obfuscator.io/ .[Pristupljeno: 22.12.2018].
20 Understanding obfuscated Code,preuzeto sa: https://www.upwork.com/hiring/development/understanding-obfuscated-code-deobfuscate-php-javascript/ .[Pristupljeno: 22.12.2018].
21 PHP Decode, preuzeto sa: https://www.unphp.net/decode/c50729311b88fa83702224e6ce10ac7c/ .[Pristupljeno: 22.12.2018].
22 Snowman, preuzeto sa: https://derevenets.com/ .[Pristupljeno: 22.12.2018].
23 Debugger,preuzeto sa: https://www.techopedia.com/definition/597/debugger .[Pristupljeno: 22.12.2018].
24 Visual Studio IDE, preuzeto sa: https://visualstudio.microsoft.com/ .[Pristupljeno: 22.12.2018].
25 IsDebuggerPresent, preuzeto sa: https://msdn.microsoft.com/en-us/library/ms680345%28VS.85%29.aspx .[Pristupljeno: 22.12.2018].
26 http://www.cplusplus.com/forum/windows/112525/ .[Pristupljeno: 22.12.2018].
27 https://stackoverflow.com/questions/6481668/protecting-executable-from-reverse-engineering .[Pristupljeno: 23.12.2018].
28 Pyinstaller manual, preuzeto sa: https://pyinstaller.readthedocs.io/en/stable/ .[Pristupljeno: 23.12.2018].
29 Py2exe, preuzeto sa: http://www.py2exe.org/ .[Pristupljeno: 23.12.2018].
30 Decompile any Python binary, preuzeto sa: https://countercept.com/blog/how-to-decompile-any-python-binary/ .[Pristupljeno: 23.12.2018].
31 Uncompyle6, preuzeto sa: https://pypi.org/project/uncompyle6/.[Pristupljeno: 24.12.2018].
32 Pyarmor,preuzeto sa: https://wiki.python.org/moin/Pyarmor .[Pristupljeno: 24.12.2018].
33 Cython kompajler, preuzeto sa:https://cython.org/ .[Pristupljeno: 30.12.2018].
34 Pyminifier 2.1, preuzeto sa: https://pypi.org/project/pyminifier/ .[Pristupljeno: 30.12.2018].
CASE2019 55
Podaci o autorima:
Hrvoje Španja, bacc.inf.
e-mail: [email protected]
Hrvoje Španja je izvanredni student druge godine specijalističkog diplomskog stručnog studija informacijske tehnologije u poslovnim sustavima, smjer programsko inženjerstvo u poslovnim sustavima Veleučilišta u Rijeci. Na istome je 2015. godine obranio završni rad te stekao zvanje prvostupnika Informatike i iste se godine zaposlio kao developer u firmi M.A.I Solution gdje sudjeluje u razvoju aplikativnih softvera za potrebe maloprodaje. Glavna područja interesa su mu razvoj aplikativnih softvera u objektnim programskim jezicima poput Jave, Visual Basic-a, C#.
dr.sc. Marin Kaluža
e-mail: [email protected]
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.
Sabrina Šuman
e-mail: [email protected]
Diplomirala 2002. na Filozofskom fakultetu, smjer matematika i informatika. Zaposlena je kao viši predavač na Veleučilištu u Rijeci gdje radi od 2005. godine te je nositelj kolegija: Informacijski sustavi za potporu upravljanju i odlučivanju, Grafika tekst i multimedija, Upravljanje kvalitetom informacijskih sustava na stručnom i specijalističkom studiju. Doktorand je na poslijediplomskom studiju odjela Informatike Sveučilišta u Rijeci. Sudjelovala je i sudjeluje na nekoliko znanstvenih projekata. Autor je niza recenziranih nastavnih materijala te jednog udžbenika. Objavila je više od 20 znanstvenih i stručnih članaka. Područja interesa: metode umjetne inteligencije, procesiranje prirodnog jezika, rudarenje podataka i teksta, poslovna inteligencija.
Veleučilište u Rijeci
Trpimirova 2/V, 51 000 Rijeka
tel. 051/321-300
fax. 051/211-270
www.veleri.hr
56 CASE2019
CASE2019 57
MOGUĆNOSTI OKRUŽENJA VUE.JS I NJEGOVIH PAKETA
Ivan Matak, univ. bacc. inf., doc. dr. sc. Tihomir Orehovački
SAŽETAK
Vue.js je okruženje koje omogućuje programiranje i razvoj aplikacija kombinacijom HTML i JavaScript jezika. Osim okruženja Vue.js, za pomoć pri razvoju okruženja i aplikacija mogu se koristiti paket za dizajn komponenti Vuetify, Vuex store management i besplatna baza podataka Google Firebase. U uvodnom dijelu rada raspravlja se općenito o Vue.js okruženju i njegovim paketima. Kroz sljedeća se poglavlja opisuju mogućnosti okruženja, od jednostavnijih prema kompleksnijim, uključujući izradu stranice i povezivanje sa bazom podataka. Svaka mogućnost okruženja potkrijepljena je primjerom implementacije.
ABSTRACT
Vue.js is a framework which provides the ability for application programming and development using the combination of HTML and JavaScript programming languages. Besides using the Vue.js framework, the Vuetify component design package, Vuex store management and the Firebase database can also be used to help the process of application development. The introductory section discusses the Vue.js framework and its packages in general. The following sections are focused on the functionalities of the framework from simple to complex ones, including page creation and database connection. Each functionality of the framework is demonstrated with an implementation example.
1. UVOD
U zadnjih 10 godina web stranice i web aplikacije su postale mnogo dinamičnije i moćnije uz pomoć programskog jezika JavaScript. Riječ je o jednom od najpopularnijih programskih jezika koji pored HTML-a i CSS-a omogućuje prikaz sadržaja u web pregledniku. Velika količina programskog koda koja se inače nalazila na poslužiteljima je preseljena u web preglednike što rezultira tome da aplikacije imaju tisuće linija JavaScript koda i datoteka koje su povezane sa HTML i CSS datotekama bez prave i formalne organizacije. Upravo je to razlog zbog kojeg sve više programera koristi JavaScript razvojna okruženja za oblikovanje korisničkog sučelja te organizaciju datoteka i podataka.
Vue.js predstavlja kombinaciju komponenti iz okruženja Angular i React.js zbog čega je moguće koristiti više jezika kao što su ES5, ES6 i TypeScript. Postoji i odvojeni JavaScript, HTML i CSS kod koji pruža bolju preglednost cjelokupnih datoteka i koda. Vue.js ima najdetaljniju dokumentaciju od svih navedenih okruženja te službene pakete za usmjeravanje stranica i upravljanje stanjem, jednako kao i Angular. Međutim, iza okruženja Vue.js ne stoji velika kompanija kao što je to u slučaju okruženja Angular i React.js. Usprkos tome, za Vue.js postoji paket za materijalni dizajn komponenti koji se naziva Vuetify. U dokumentaciji za Vuetify se nalazi popis komponenti te primjeri programskog koda koji prikazuju kako se te komponente koriste. Ovaj paket je presudni faktor odluke za razvoj aplikacije u okruženju Vue.js zato što omogućuje brzu i jednostavnu izgradnju dizajna stranica pomoću već programiranih komponenti koje se mogu prilagoditi potrebama korisnika. Vuetify se isto tako redovito ažurira te se poboljšavaju i dodaju nove komponente. Razlog za odabir Vue.js okruženja je i odvojenost JavaScript koda na način da će se dijelovi koda pozivati iz .js datoteka kako bi se koristile za Vue datoteke na kojima se nalaze komponente i podaci [12].
2. IZRADA NASLOVNE STRANICE WEB APLIKACIJE
Nakon instalacije Vue.js okruženja, njegovih paketa i proširenja, prikazan je detaljan primjer procesa izrade stranice koja će sadržavati traku sa izbornikom koji se prilagođava rezoluciji uređaja te gumbe i slike koji se rotiraju ovisno o njihovoj količini. Naslovna stranica će se izrađivati u datoteci „App.vue“ koja sadrži početni kod prikazan na slici 1. Svojstvo (eng. property) <template> označava granicu i prostor u kojem se nalazi kod i komponente za aplikaciju, dok svojstvo <script> označava prostor za dodjeljivanje vrijednosti raznim varijablama ili za pozivanje funkcija koje se nalaze u JavaScript datotekama. Za kreiranje dobrog korisničkog iskustva, bitno je odabrati odgovarajuću arhitekturu aplikacije [1]. Pošto se glavno korisničko sučelje za aplikaciju izrađuje u jednostraničnom obliku, postavlja se i Vuetify komponenta <v-app> koja će se odnositi na sve ostale povezane Vue stranice. Svojstvo <style> učitava definirane stilove iz druge datoteke, a uglavnom se koristi za boje. Na slici 1 je prikazan osnovi oblik koda za praznu vue stranicu.
Najprije se postavlja HTML element <main> u kojem će se nalaziti glavni sadržaj aplikacije, dok će izvan tog elementa biti izbornik, odnosno alatna traka (eng. toolbar) koja je statični dio, a ne dinamički kao ostali sadržaj stranice. Za implementaciju alatne trake, najprije se postavlja <v-toolbar> koji je Vuetify komponenta. Unutar <v-toolbar> komponente se dodaje <v-toolbar-title> komponenta [2]. Element <v-toolbar-title> služi za postavljanje naslova aplikacije, što je u ovom slučaju „StudentEvent“. Kako bi se dodali ostali dijelovi alatne trake, jednostavno se koriste <v-btn> komponente
58 CASE2019
koje predstavljaju gumbe [3]. Međutim, prije nego što se postave gumbi, okružiti će se sa komponentom <v-toolbar-items> koja služi za postavljanje svih ostalih komponenti unutar alatne trake. Dodaje se broj komponenti gumba koji je potreban za aplikaciju dok se novi gumbi mogu dodati kasnije. Kako bi gumbi izgledali bolje, unutar komponente <v-btn> upisuje se „flat“ što zapravo miče rubne oznake koji gumbi inače imaju. Gumbi će se u ovom slučaju nalaziti odmah nakon naslova aplikacije, a kako bi ih pomaknuli, između <v-toolbar-title> i <v-toolbar-item> komponenti se postavlja komponenta <v-spacer> koja stvara prostor između gumbi i naslova. Nakon što su se poredali naslov i gumbi, dodaju se ikone za gumbe i to na način da se dodaje komponenta <v-icon> unutar <v-btn> komponente. Popis ikona, njihov naziv i izgled je dostupan u službenoj dokumentaciji [4]. Ime ikone se postavlja unutar <v-icon> komponente. Radi ljepšeg izgleda, unutar <v-icon> komponente se postavlja i riječ „left“ kako bi se ikona pomaknula ulijevo tako da nije direktno povezana sa tekstom.Nakon što se postavio osnovni izgled alatne trake, potrebno je postaviti i ikonu sa lijeve strane kako bi mogli koristiti aplikaciju na
mobilnim uređajima i kako bi se ista mogla dinamički prilagođavati različitim rezolucijama ekrana. Za početak, prije <v-toolbar> komponente, dodaje se <v-navigation-drawer> komponenta koja treba biti povezana sa nečime što ju poziva. Vue.js omogućuje povezivanje modela podataka sa prezentacijskim slojem aplikacije te ponovnu upotrebu komponenti kroz proces implementacije aplikacije [5]. U tu svrhu se unutar te komponente postavlja „v-model“ koji služi za povezivanje sa nekom drugom komponentom koja je tipa boolean kako bi se znalo kada će se ta komponenta prikazati. Za naziv „v-model“ se postavlja varijabla „sideNav“ te će se ista definirati unutar skripte pod data return i dodijeliti će joj se vrijednost koja će biti „false“. Sada je potrebna neka komponenta koja će tu varijablu pozvati te joj tako promijeniti vrijednost kako bi se <v-navigation-drawer> komponenta mogla prikazati. U tu svrhu se dodaje <v-toolbar-side-icon> komponenta iznad <v-toolbar-title> komponente kako bi prikazali ikonu sa tri crtice. Dodaje se i „@click.stop“ metoda (eng. listener) koja se okida kada korisnik klikne tu ikonu te zadržava to stanje pomoću riječi stop jer bi se u suprotnom izbornik samo pojavio na trenutak i ponovno vratio u svoje prvobitno stanje. Vrijednost metode koja prati događaj klika na ikonu se postavlja na „sideNav = !sideNav“ što znači da dodaje varijabli sideNav suprotnu bool vrijednost s obzirom na trenutnu vrijednost. Sada bi se trebala dodati lista za taj izbornik sa strane. To se provodi na način da se unutar <v-navigation-drawer> komponente postavi <v-list> komponenta koja sadrži retke te unutar nje <v-list-tile> komponenta koja predstavlja jedan redak u listi [6]. Unutar te komponente je potrebna <v-list-tile-action> komponenta koja sadržava komponentu ikone, a komponenta <v-list-tile-content> sadržava naziv tog retka. Sada kada su izrađeni izbornik za mobilne uređaje i alatna traka, potrebno je postaviti kako će se alatna traka prikazivati ovisno o rezoluciji. Na slici 2 je prikazan zasada napisani kod.
Da bi se to postiglo, dodaje se CSS klasa „hidden-sm-and-up“ kako bi alatna traka ostala skrivena kod malih i većih uređaja dok se unutar <v-toolbar-items> postavlja CSS klasa „hidden-sm-and-down“ kako bi se ikone i gumbi na alatnoj traci sakrile na manjim uređajima. Kako bi se lakše upravljalo bojama, u datoteku „main.styl“ je potrebno dodati podatke iz Vuetify dokumentacije koji daju strukturu i kod za učitavanje boja [7]. Naravno, mogu se birati sve boje koje se isto tako nalaze u dokumentaciji. Ako se unutar <v-toolbar> komponente doda class = „primary“, boja će biti ona koja je zadana u datoteci za stil pod nazivom „primary“. Kako bi slova bila odgovarajuće boje s obzirom na kontrast, može se dodati i riječ „dark“ što znači da je pozadinska boja tamna, pa će slova biti bijele boje radi bolje vidljivosti.
Slika 2. Izgled koda za datoteku App.vue
Slika 1. Osnovni oblik datoteke App.vue za praznu stranicu
CASE2019 59
2.1 Učitavanje izbornika i usmjeravanje stranica aplikacije
Za učitavanje izbornika potrebno je polje, pa će se unutar dijela za vraćanje podataka (eng. data return) napraviti polje pod nazivom menuItems. Razlog tome je da se ne mora pisati sadržaj alatne trake te da je moguće upravljati podacima na izborniku s obzirom na to da li je korisnik prijavljen ili nije. Unutar tog novog polja, postavlja se JavaScript objekt koji će sadržavati ikonu i naslov (eng. title). Na opisani se način izrađuju objekti za svaki gumb koji je poželjno imati u izborniku, kao što su gumbi za prijavu i registraciju. Nakon što se polje popunilo, potrebno ga je dinamički ispisati, a to se radi pomoću „v-for“ petlje koja se postavlja unutar <v-list-tile> komponente. Kako bi se prolazilo dinamički kroz polje, potrebno je postaviti naredbu „v-for“ na sljedeći način: v-for = “item in menuItems“ :key=“item.title“. Na ovaj način se određuje binding za unikatni ključ koji je u ovom slučaju naslov pošto je svaki naslov različit. Sada se mogu zamijeniti nazivi za gumbe koji su pisani ručno sa {{ item.title }} unutar <v-list-tile-content> te {{ item.icon }} unutar <v-icon> i to se sve povlači dinamički iz polja koje je napravljeno ranije. Navedeno se odnosi na raspoređivanje podataka u izborniku sa strane, a za alatnu traku potrebno je na sličan način postaviti „v-for“ za „v-btn“ unutar „<v-toolbar-items>“ komponente. Zatim se mijenjaju statični podaci na isti način unutar <v-btn> i <v-icon> komponenti.
Sada kada postoji uređeni dizajn oba izbornika, potrebno je te gumbe preusmjeravati na njihove odgovarajuće stranice. Mapa „router“ već postoji ako je tako odlučeno pri instalaciji tako da već postoji osnova za preusmjeravanje. U datoteci App.vue će se unutar <main> komponente dodati <router-view> komponenta kako bi se mogao povezati usmjerivač (eng. router). Sada je potrebno implementirati glavne stranice koje će se koristiti u aplikaciji. Potrebno je unutar mape „components“ napraviti podmape na način da se zna za što se koriste. Za početak, podmape će se zvati „Event“ i „User“ tako da postoje stranice koje se odnose na korisnika i na neki događaj te će se tako i raspodijeliti. Zatim je potrebno kreirati .vue datoteke za svaku stranicu te se u svaku stranicu stavlja HTML <p> odlomak kako bi se znalo koja se stranica prikazuje. Stranice se naknadno mogu dodavati po želji i potrebi.
Sljedeći korak je usmjeravanje napravljenih stranica. Da bi se razumjelo kako to funkcionira, prelazi se u „main.js“ datoteku gdje se vidi kako je usmjerivač uvezen u projekt na samom vrhu datoteke. Usmjerivač je isto tako dodan u novu Vue instancu u toj datoteci pa je povezan sa cjelokupnim projektom. Sada se u index.js datoteci dodaju nove rute, odnosno povezuju se stranice. Zadana ruta ima adresu na „/“ što je i zadana stranica projekta. Međutim, komponenta će se zvati „Home“ kako bi se znalo da je to prva stranica koja se otvara kada se aplikacija pokrene. Na vrhu te datoteke potrebno je sve te komponente unijeti na način da se na vrhu napiše „import Home from '@/components/Home'“. Znak @ se referencira na mapu „src“ pa je potrebno definirati točan put do te datoteke. Na spomenuti se način vrši učitavanje svih ostalih stranica koje su do sada dodane. Ukoliko je to primjerice stranica za prijavu koja se naziva „Signup“, njezina će ruta za učitavanje biti „import Signup from '@/components/User/Signup'“ jer se nalazi u mapi „User“. Nakon što je napravljeno učitavanje za sve stranice, dodaje se nova adresa za svaku od njih. Adresa se postavlja prema potrebama, no „name“ i „component“ moraju imati isto ime kao i uvezena stranica. Kada su dodane sve rute, postavlja se „mode: 'history'“ što miče znak „#“ iz url adrese.
Povezane stranice je potrebno navesti i u App.vue datoteci u polju menuItems. Dodaje se svojstvo za povezivanje te se svaka stranica usmjerava na adresu koja je definirana u usmjerivaču. Isto tako se postavlja da se naslov „StudentEvent“ klikom preusmjerava na početnu stanicu. Na mjestu gdje je taj naslov postavlja se komponenta <router-link> i unutar te komponente se dodaje „to='/' “ koji preusmjerava na početnu stranicu te „tag='span' “ i „style='cursor: pointer' “ kako bi se promijenio oblik miša iznad naslova. Na kraju ih je još potrebno povezati sa komponentama u App.vue datoteci. Kod „v-for“ za oba izbornika se dodaje „router :to=item.link“ kako bi se povezali sa poljem. Na taj način se ostvaruju funkcionalne i povezane stranice sa izbornikom. Izgled koda za routing stranica je prikazan na slici 3.
Slika 3. Kod za datoteku "index.js" u mapi "Router"
2.2 Uređivanje naslovne stranice
Kada su dovršene povezane stranice i osnovni izgled izbornika, potrebno je urediti i dizajnirati naslovnu stranicu. Ista je zamišljena sa dva gumba koji vode na stranice za nadolazeće događaje i za kreiranje novog događaja te sa pokretnim slikama od događaja. Za raspoređivanje sadržaja na stranicama jako su korisne grid komponente koje dijele sadržaj stranice na rešetke radi lakšeg raspoređivanja dimenzija sadržaja na stranici [8].
U datoteci Home.vue će se izgraditi izgled naslovne stranice. Zasada postoji samo <template> komponenta pa će se unutar nje dodati <v-container> koji okružuje podijeljene rešetke za stranicu. Unutar te komponente se stavlja <v-layout row wrap class=“mt-2“> što predstavlja jedan redak za podjelu sadržaja stranice zbog kojeg će sadržaj prijeći u novi red ako u prethodni ne stane te klasu za prostor između komponenti. Nakon toga se postavlja <v-flex xs12 sm6 class=“text-xs-center text sm-right“> komponenta unutar koje je moguće redati sadržaj i poravnati ga sa Vuetify klasom koja to
60 CASE2019
omogućuje. Na ovaj način će prvi gumb biti pomaknut na desni kraj svojeg prostora na većim uređajima dok će na manjim uređajima biti centriran. Za drugi gumb se postavlja riječ „left“ zato što se nalazi u drugome fleksibilnom prostoru te će na taj način biti dobro centrirani. Oznake „xs12“ i „sm6“ označavaju kako će se sadržaj ponašati s obzirom na veličinu uređaja. Na jako malim uređajima će zauzimati cijeli red, a na malo većim uređajima pola reda. Najprije se postavlja jedan gumb za pregled događaja pomoću komponente <v-btn large router to=“/events“ class=“info“> jer je cilj da gumb bude velik kako bi usmjeravao na stranicu sa popisom događaja u boji klase info za stil. Za drugi gumb koji usmjerava na stranicu događaja istim se postupkom izrađuje nova <v-flex xs12 sm6> komponenta, samo se usmjerava na drugu stranicu, u ovom slučaju „/event/new“.
Nakon dva gumba, potrebno je dodati komponentu rotirajućeg izbornika (eng. carousel) koja se isto tako nalazi u službenoj dokumentaciji [9]. Kao i dosad, postavljaju se <v-layout> i <v-flex xs12> komponente te <v-carousel> komponenta koja je kopirana iz dokumentacije. Nakon toga, potrebni su neki podaci kako bi se mogla pozvati petlja unutar rotirajućeg izbornika s ciljem prikazivanja istih. U tu se svrhu na dnu datoteke otvara <script> te se isto kao i prije dodaje data return() dio koji sadrži varijable. Ponovno je potrebno polje koje će se zvati „events“ te će se u to polje staviti imageUrl, title i id koji će biti izmišljeni, jer je cilj samo testirati kako rotirajući izbornik radi pošto još ne postoji baza za spremanje tih podataka. Nakon što je polje popunjeno podacima, potrebno je urediti rotirajući izbornik. Prvo se mijenja „items“ u „events“, a „item“ se mijenja u „event“ te se miču zagrade i varijabla „i“. Postavlja se „:key = event.id“ te „:src = event.imageUrl“. Sada kada postoje slike čiji su linkovi kopirani sa interneta, postavlja se <div class=“title“>, a unutar tog div-a „{{ event.title }}“ kako bi se prikazao i naslov događaja. Na dnu stranice se dodaje <style scoped> tako da se odnosi samo na tu stranicu, a unutar te komponente „.title“ komponenta sa sljedećim opisom:
position: absolute;
bottom : 50px;
backgrond-color: rgba(0,0,0,0.5);
color: white;
font-size: 2em;
padding: 20px;
Na taj način je uređeno pozicioniranje za naslov od događaja, njegova boja, veličina fonta i slično. Još je potrebno postaviti naslovnu poruku, a u tu se svrhu kopira jedan postojeći <v-layout> te se unutar njega postavlja odlomak <p> sa porukom koja će se prikazati. Nakon ovoga je napravljena funkcionalna početna stranica i izbornici [12]. Slika 4 prikazuje krajnji rezultat.
Slika 4. Krajnji rezultat - izgled naslovne stranice
3. UREĐIVANJE STRANICA ZA POPIS DOGAĐAJA I ZASEBNI DOGAĐAJ
Najprije će se implementirati stranica za popis događaja za koju je već izrađena datoteka. Za raspored se koriste rešetke (eng. grid) pa će se tako samo redati komponente <v-container>,<v-layout row wrap> i <v-flex xs12 sm10 md8 offset-sm1 offset-md-2>. Offset označava koliko će praznog prostora biti između rubova kartice. Događaji će se poredati u <v-card class=“info“> komponente unutar <v-flex xs12 sm4 md3> [10]. Unutar komponente kartice (eng. card) se postavlja <v-container fluid> kako bi se iskoristio sav dostupni prostor. Zatim se postavljaju <v-layout row> i <v-flex xs5> pa unutar njih <v-card-media> koji ima svoja „src“ i „height“ svojstva za uređivanje. Za „src“ se koristi poveznica slike koja se koristi i za rotirajući izbornik, a „height“ se prilagođava prema potrebama korisnika. Ispod <v-flex> za medije kartice dodaje se još jedan <v-flex> za informacije o događaju. Za tekst iz ranije navedene dokumentacije može se koristiti <v-card-title primary-title>. Unutar te komponente postoji jedan <div> koji sadrži <h5 class „white--text mb-0“> za naslov sa bijelim slovima te ispod njega još jedan <div> za opis događaja, odnosno datum. Nakon postavljenih informacija o događaju, potrebne su akcije za svaki događaj. Ispod komponente naslova kartice postavlja se <v-card-actions>, a unutar te komponente postavljaju se gumbi sa ikonicama <v-btn flat> sa tekstom te <v-icon left light> za svjetlije boje prilikom prelaska miša preko gumba.
CASE2019 61
Sada nam treba funkcionalnost gumba koji je prethodno dodan. Gumb treba voditi korisnika na taj specifični događaj. Najprije je unutar usmjerivača potrebno dodati novu rutu čija je adresa „/events/:id“, a name i component su oba „Event“. Na početku te datoteke isto je tako potrebno napraviti učitavanje (eng. import) za tu stranicu te ju kreirati ukoliko ona ne postoji. U novoj datoteci se redom kao i prije postavljaju <template>, <v-container>, <v-layout row wrap> i <v-flex x12>. Unutar flex komponente se ponovno koriste <v-card> i <v-card-title> u kojima će se postaviti <h6 class=“primary--text“> za naslov događaja. Ispod <v-card-title> komponente postavlja se <v-card-media> čiji će se sadržaj kopirati iz datoteke Events.vue te se svojstvo za visinu postavlja na 400px. Ispod te komponente slijedi <v-card-text> koji sadrži <div class=“info--text“> gdje se postavlja neki tekst za test. Nakon toga se stavlja <v-card-actions> i unutar toga <v-spacer> i <v-btn class=“primary“> za registraciju na događaj. Sljedeći je korak preusmjeriti korisnika na točnu adresu određenog događaja, zasada statičnu, a kasnije dinamičku preko baze podataka. U datoteci Event.vue u gumbu za pregled jednog događaja stavlja se „to='events/1'. Nakon toga se prelazi u Home.vue gdje već postoji statički id za testni događaj, pa se taj id kopira i postavlja pod <v-carousel-item> „@click='onLoadEvent(event.id)'“. To je funkcija pa ju je potrebno pozvati i definirati na dnu datoteke pod „methods“. Funkcija glasi ovako:
onLoadEvent (id) {
this.$router.push('/events' + id)
}
Za rotirajući izbornik se još može dodati i style=“cursor: pointer;“ zato što se sada može kliknuti i usmjeriti se na događaj preko rotirajućeg izbornika bazirano na id-u događaja koji je zasada statičan.
3.1 Vuex upravitelj stanjem
Kako bi se koristile funkcije i iste spremale u zasebne datoteke za uredniji kod, mora se koristiti Vuex upravitelj stanjem [11]. Instalacija je vrlo jednostavna te se samo koristi jedna naredba: „npm install –save vuex“. Sada je potrebno kreirati novu mapu unutar „src“ mape pod nazivom „store“ te unutar te mape datoteku „index.js“. Unutar te datoteke, postavlja se učitavanje za Vue i Vuex. Vuex se tada poziva sa „Vue.use(Vuex)“ te se nakon toga može početi koristiti. Najprije se treba pomoću Vuex-a postaviti neka konstanta koja će biti spremište (eng. store) za sve funkcije. Navedeno se radi pomoću sljedeće naredbe: „export const store = new Vuex.Store()“. Spremište će unutar sebe sadržavati stanja, mutacije, akcije i metode za pristup podacima. Stanje prikazuje trenutni status podataka, mutacije služe za promjenu tih podataka, akcije su namijenjene izvršavanju mutacija, a metode za pristup podacima omogućuju pozivanje spremišta unutar komponenti. Unutar stanja se deklarira polje pod nazivom „loadedEvents“ u kojem se postavljaju i kopiraju sve informacije o statičnim događajima iz Home.vue datoteke kako bi preko tog spremišta bio omogućen pristup tim podacima iz bilo koje datoteke. Izvan tog polja se postavlja i korisnik (user) sa svojim statičkim id-om prema vlastitom izboru te polje „registeredEvents“ koje označava prijavljene događaje korisnika. Kako bi se ti podaci mogli koristiti, potrebno je postaviti metode za pristup podacima. Metoda za pristup podacima treba imati jednaki naziv kao i mutacija, a to je „LoadedEvents“. Kod mora dohvatiti i sortirati događaje po datumu te se u tu svrhu unutar događaja dodaje svojstvo za datum ukoliko to nije učinjeno ranije.
Funkcija vraća stanje u kojem su događaji te ih uspoređuje i sortira. Zatim se radi još jedna metoda za pristup podacima koja dohvaća id pojedinog događaja. Za njega se koristi Javascript funkcija find. Slika 5 prikazuje primjer metoda za učitavanje pojedinog događaja i popisa više sortiranih događaja.
Slika 5. Metode za pristup podacima za događaje
Slijedi opis korištenja metoda za pristup podacima. Na dnu datoteke Home.vue se briše „data“ dio koda te se umjesto „data“ postavlja „computed“ u svrhu dohvaćanja i obrade podataka. Unutar funkcije „events“ potrebno je pozvati tu metodu za pristup podacima na sljedeći način: „return this.$store.getters.featuredEvents“. Ta metoda za pristup podacima se izrađuje tako da se u return postavi getters.loadedEvents.slice(0,5). Na spomenuti se način prilagodio prikaz za rotirajući izbornik da se ne prikazuju baš svi događaji. Kako bi sve to radilo, potrebno je u main.js datoteci napraviti učitavanje na vrhu datoteke „import {store} from './store'“ te dodati spremište ispod usmjerivača kako bi učitavali događaje za rotirajući izbornik.
Učitavanje događaja se radi preko rotirajućeg izbornika na naslovnoj stranici. Sada je navedeno potrebno napraviti i za stranicu sa popisom događaja, odnosno datoteku „Events.vue“. Na dnu datoteke postavlja se <script> te opet funkcija „events“ koja iz metode za pristup podacima vraća sve događaje, a ne kao prijašnji primjer gdje je broj događaja bio ograničen. U istoj datoteci pri vrhu pod prvi <v-layout> dodaje se v-for=“event in events“ :key=“event.id“ class=“nb-2“. Nakon toga se redom kao i prije mijenja naslov sa {{ event.title }}, izvor slike sa :src=“{{ event.imageUrl }}“, te datum sa {{ event.date }}. Još nedostaje mogućnost da klik na pregled događaja vodi točno na taj specifični događaj. Navedeno se realizira tako da se pod taj gumb unosi sljedeći kod: <v-btn flat :to=“ '/events/' + event.id“>. Nakon ove radnje više nije potrebno učitavati statičke događaje, već je to poželjno napraviti pomoću spremišta. Na dnu datoteke Event.vue se
62 CASE2019
postavlja <script> te se pod metodama za pristup podacima postavlja funkcija „event“ kojom se poziva funkcija iz spremišta „loadedEvent“ kojoj se unutar zagrada prosljeđuje id događaja. Navedeno se radi tako da se dodaje „props“ koji sadrže id-eve događaja te se u usmjerivaču postavi „props: true“ kako bi se isti omogućili [12]. Sada je potrebno kao i prije zamijeniti statične podatke iz datoteke „Event.vue“ sa dinamičkim.
4. POSTAVLJANJE BAZE PODATAKA I IMPLEMENTACIJA STRANICA ZA REGISTRACIJU I PRIJAVU
Firebase je baza podataka koju razvija Google. Nudi besplatne usluge kao što su spremanje podataka i autentifikacija. Za korištenje Firebase usluga potrebno je imati Google račun te Firebase sam vodi korisnika kroz proces kreiranja baze podataka. Za vrstu autentifikacije jednostavno se odabere željeni način i pritisne se gumb „enable“, a to su u ovom slučaju e-mail adresa i lozinka. Pošto je potrebno implementirati bazu, u gornjem desnom kutu se pritisne gumb „Web setup“ te će se otvoriti prozor sa svim informacijama za povezivanje sa bazom podataka. Iz tog prozora se kopiraju apiKey, authDomain, databaseURL, projectID i storageBucket. Instalacija je zapravo ista kao i za Vuex, samo što se na kraju postavlja zadnja riječ „firebase“. Slijedi inicijalizacija baze podataka. U datoteci „Main.js“ se na početku radi učitavanje na sljedeći način: „import * as firebase from 'firebase'“. Unutar new Vue radi se metoda „created“ te se u nju spremaju podaci koji su kopirani. Važno je napomenuti kako pristup i dohvaćanje podataka nije moguće samo na pregledniku Firefox zbog „IndexedDB“ standarda. Slika 6 prikazuje kod koji je preuzet sa Firebase stranice kako bi se ostvarila konekcija.
Slika 6. Podaci za inicijalizaciju baze podataka
Kada je baza podataka inicijalizirana, moguće je započeti implementaciju stranice za registraciju. Za implementaciju stranice ponovno se koriste komponente <v-container>, <v-layout row> i <v-flex xs12 sm6 offset-sm3>. Zatim se postavljaju <v-card> i <v-card-text> te unutar njih novi <v-container> koji sadrži <v-form>. Unutar forme se postavlja novi <v-layout row> i <v-flex xs12>. Prvo je potrebna nova e-mail adresa pa će se postaviti <v-text-field name=“email“ label=“E-mail adresa“ id=“email“ v-model=“email“ type=“email“ required>. Model nam služi kako bi vrijednost koju korisnik upiše bila povezana na svojstvo kasnije, a type automatski postavlja pravilo da unos treba biti u obliku e-mail adrese te je dodana ugrađena validacija sa „required“ koja označava da je to polje za unos obavezno. Za lozinku se navedeno može kopirati te dodati ispod e-mail adrese, jedino je potrebno informacije prilagoditi kontekstu lozinke. Zatim je potrebno dodati još jedan red koji bi se trebao odnositi na to da se ponovno upiše lozinka te da se uspoređuje sa prethodno unesenom lozinkom. Ispod svega se dodaje jedan <v-btn type=“submit“> kako bi se mogli poslati podaci za registraciju. Na dnu datoteke ponovno se dodaje <script> te se pod data () return dodjeljuju vrijednosti koje su postavljene pod „v-model“, a te će vrijednosti na početku biti prazni stringovi. Sada je potrebna metoda za pristup podacima u kojoj će se nalaziti funkcija za usporedbu lozinki. Funkcija comparePasswords će imati samo jednu liniju koda putem koje će vraćati „return this.password !== this.confirmPassword ? 'Lozinke nisu jednake' : ' ' “. Nakon toga se u komponenti <v-text-field> dodaje „:rules='[comparePassowrds]'“ kako bi ta funkcija radila. Zatim je potrebno postaviti metodu koja će dozvoliti predaju podataka. Zbog toga se pod „methods“ postavlja funkcija „onSignup ()“. Zatim se pod <form> dodaje „@submit.prevent=“onSignup“>. Potrebna nam je funkcija za registraciju korisnika na bazu, a ta funkcija se postavlja u „index.js“ datoteci u mapi „store“. No prije te funkcije, potrebno je u trenutnoj datoteci napraviti učitavanje za Firebase bazu podataka. Funkcija „signUserUp“ dobiva povratne podatke od korisnika koji šalje podatke. Za funkciju „signUserUp“ se koriste Firebase ugrađene metode za autentifikaciju te se toj istoj funkciji šalju podaci koje je unio korisnik klikom na gumb za registraciju. Zatim je potrebno dobiti podatke koji se spremaju u Vuex spremište, a za to treba mutacija koja se naziva „setUser“ gdje se šalju ti novi podaci korisnika. Nakon toga se u funkciji „signUserUp“ postavlja konstanta „newUser“ kojoj se dodjeljuje vrijednost iz Firebase baze gdje je id pod nazivom „uid“ te mu se postavlja prazno polje za događaje na koje će se korisnik potencijalno prijaviti. Na kraju se dodaje „.catch()“ koja služi za dohvaćanje i čitanje pogrešaka (error poruka). Nakon toga se izvršava mutacija koja je ranije napravljena ispod polja za konstantu „newUser“. Zatim se odlazi u datoteku „Signup.vue“, u funkciji „onSignup“ se poziva funkcija iz spremišta te joj se prosljeđuju potrebni podaci: „this.$store.dispatch('SignUserUp, {email: this.email, password: this.password)“.
Kako bi se dohvatio trenutno prijavljeni korisnik, potrebna je metoda za pristup podacima. Najprije se u spremištu postavlja zadani (eng. default) user na null tako da se ne dobiju statičke vrijednosti. Zatim se radi nova metoda za pristup podacima koja će se nazvati „user“, a služi vraćanju state.user iz Vuex spremišta. Prelazi se u „Signup.vue“ datoteku te se radi nova metoda za pristup podacima koja se isto naziva „user“. Ista radi kao i originalna metoda za pristup podacima što znači da vraća this.$store.getters.user. Nakon toga se postavlja „watch“ metoda koja provjerava da li se promijenilo stanje korisnika. Ukoliko je korisnik prijavljen, odnosno nije null, poziva se this.$router.push('/') i šalje se korisnika na početnu stranicu. Ovisno o tome da li je korisnik prijavljen, potrebno je da se na izborniku mijenjaju opcije. Unutar datoteke „App.vue“ se izrađuje nova metoda za pristup podacima sa funkcijom menuItems. Prijašnje menuItems polje se miče u novu funkciju istog imena koja vraća one mogućnosti izbornika koje su predodređene za prijavljene i neprijavljene korisnike. Za to je potrebna selekcija if i funkcija userIsAuthenticated koja vraća stanje korisnika preko metode za pristup podacima.
CASE2019 63
Još je potrebno urediti stranicu za prijavu koja je jako slična stranici za registraciju, pa će se kopirati cjelokupni kod iz stranice za registraciju. Briše se red za potvrdu lozinke, mijenja se tekst gumba, a metoda iz forme u skripti se naziva „onSignIn“. Polje za usporedbu lozinki nije potrebno pa se briše. Konačno, potrebno je unutar spremišta napraviti novu funkciju „signUserIn“ koja koristi ugrađenu Firebase funkciju „auth().signInWithEmailAndPassword“, dok se u zagradama navode podaci koji se prosljeđuju [12]. Funkcija prikazana na slici 7 prikazuje funkciju za registraciju korisnika na Firebase bazu podataka. Slika 7 prikazuje kod za registraciju korisnika na bazu podataka pomoću ugrađenih Firebase funkcija.
Slika 7. Funkcija za registraciju korisnika na bazu podataka
5. ZAKLJUČAK
Aplikacije imaju vrlo velik i rasprostranjen utjecaj na današnje društvo te predstavljaju jedan od najkorištenijih i najunosnijih oblika poslovanja. Kvaliteta i brzina utječu na percepciju korisnika prema aplikaciji te su presudni faktor za popularnost i upotrebljivost iste. Vue.js predstavlja jedan od novijih okruženja za razvoj koji se temelji na programskim jezicima HTML i JavaScript. Upravo je programiranje primjenom okruženja danas najpopularniji način razvoja web aplikacija. Osim Vue.js okruženja, mogu se koristiti Vuex store management, Vuetify te Firebase baza podataka kao besplatni izvor za pohranjivanje podataka koji ne ovisi o lokalnom poslužitelju. Vuetify se koristi za komponente i gradnju izgleda stranice u kombinaciji sa HTML jezikom, Vuex store management je namijenjen lokalnom spremanju podataka, a Firebase služi kao baza za dohvaćanje podataka.
Za usmjeravanje i registraciju puta za stranice, koristi se usmjerivač koji je ugrađen u Vue.js. Funkcije su napisane u JavaScript datotekama te su povezane sa Vue datotekama pomoću <script> te se na taj način prosljeđuju podaci između te dvije vrste datoteka. Takav način rada omogućava jednostavno upravljanje podacima i pisanje funkcija u skladu sa vlastitim potrebama. Stanje služi kako bi prikazalo kako će objekt za događaje izgledati odnosno koje podatke sadrži. Akcije rade promjene nad podacima, a mutacije primjenjuju te promjene. Metode za pristup podacima služe za dohvaćanje stanja korisnika i njima sličnih podataka. Iz svega navedenog proizlazi da je Vue.js okruženje zajedno sa dodatnim paketima i proširenjima moćan alat koji omogućuje učinkovit i djelotvoran razvoj i testiranje raznovrsnih web aplikacija. Vue.js okruženje, njegovi paketi i proširenja se i dalje aktivno razvijaju te isti često dobiva ažuriranja i nadogradnje koje donose nove mogućnosti ili proširuju oblike i načine korištenja postojećih mogućnosti [12].
Literatura:
1 Kaluža, M., Troskot, K., Vukelić, B: „Comparison of Front-End Frameworks for Web Applications“, Zbornik Veleučilišta u Rijeci, Vol. 6, 2018.
2 Vuetify, (n.d.), Toolbar, https://vuetifyjs.com/en/components/toolbars, (datum pristupa 27.7.2018.)
3 Vuetify, (n.d.), Button, https://vuetifyjs.com/en/components/buttons, (datum pristupa 28.7.2018.)
4 Material.io, (n.d.), Icons, https://material.io/tools/icons/?style=baseline, (datum pristupa 31.7.2018.)
5 Filipova, O.: „Learning Vue.js 2“, Packt Publishing Ltd., Birmingham, 2016.
6 Vuetify, (n.d.), List, https://vuetifyjs.com/en/components/lists, (datum pristupa 1.8.2018.)
7 Vuetify, (n.d.), Theme, https://vuetifyjs.com/en/style/theme, (datum pristupa 1.8.2018.)
8 Vuetify, (n.d.), Grid System, https://vuetifyjs.com/en/layout/grid, (datum pristupa 4.8.2018.)
9 Vuetify, (n.d.), Carousel, https://vuetifyjs.com/en/components/carousels, (datum pristupa 4.8.2018.)
10 Vuetify, (n.d.), Card, https://vuetifyjs.com/en/components/cards, (datum pristupa 4.8.2018.)
64 CASE2019
11 Vuex, (n.d.), What is Vuex?, https://vuex.vuejs.org/, (datum pristupa 8.8.2018.)
12 Matak, I.: Razvoj aplikacije u okruženju Vue.js, završni rad. Fakultet informatike, Sveučilište Jurja Dobrile u Puli, Pula, 2018.
Podaci o autorima:
Ivan Matak, univ. bacc. inf.
e-mail: [email protected]
Ivan Matak je 2018. godine stekao akademski naziv sveučilišnog prvostupnika informatike na Fakultetu informatike Sveučilišta Jurja Dobrile u Puli. Na istom trenutno pohađa prvu godinu diplomskog studija informatike. Glavna područja interesa su mu razvoj web aplikacija, web stranica, mobilnih aplikacija i uređivanje videozapisa.
doc. dr. sc. Tihomir Orehovački
e-mail: [email protected]
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. Od 1. listopada 2015. godine zaposlen je na radnom mjestu docenta na Fakultetu 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 89 znanstvenih radova objavljenih u zbornicima međunarodnih konferencija, časopisima i knjigama te 13 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 12 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, International Conference on Information Technology (ICIT) te International Conference on Software and Information Engineering (ICSIE). 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 65 studenata obranilo završne i diplomske radove.
Fakultet informatike u Puli
Sveučilište Jurja Dobrile u Puli
Zagrebačka 30, 52100 Pula
fipu.unipu.hr
CASE2019 65
IZRADA RAČUNALNE IGRE U OKRUŽENJU GAMEMAKER
Vlatko Matić, univ. bacc. inf., doc. dr. sc. Tihomir Orehovački
SAŽETAK
Od nastanka prvih računalnih igara do danas one se neprestano razvijaju i napreduju. Taj proces uvelike ubrzava sve veća količina dostupnih okruženja za njihov razvoj. Jednostavnija okruženja omogućuju novim korisnicima da razvijaju svoje projekte te pritom uče programirati i implementirati nove ideje. Kompleksnija okruženja služe kako bi napredniji korisnici ili stručnjaci mogli razvijati kvalitetnije nove projekte u što manjem vremenu. Jedno od najpopularnijih okruženja za izradu video igara je Game Maker Studio, koji se može svrstati između dvije navedene kategorije. U ovom radu opisan je proces izrade računalne igre u tom okruženju, ali i sam Game Maker te njegovi osnovni pojmovi.
ABSTRACT
From the emergence of the first computer games to date, they are constantly evolving and advancing. This process is accelerating thanks to the growing amount of available game engines for their development. Simpler engines enable beginners to develop their projects and learn how to program and implement new ideas. More complex engines are used to enable more advanced users or professionals to develop new higher quality projects in as short a time. One of the most popular game engines is Game Maker Studio, which can be classified between these two categories. This paper describes the process of making a computer game in that engine, but it also describes the Game Maker itself and its basic concepts.
1. UVOD
Računalne igre namijenjene osobnim računalima mogu biti višestruko složenije od igara za pametne telefone i tablete dok su najsličnije igrama za konzole. Danas se najpopularniji naslovi igara razvijaju za veći broj platformi. Igre za osobna računala lakše je modirati te su kao takve popularnije među igračima i programerima.
Prema procjeni portala Newzoo specijaliziranog za analitiku igara i elektroničkih sportova, računalne igre su 2016. godine zauzimale nešto manje od trećine vrijednosti ukupnog tržišta igara. Udio računalnih igara na svjetskom tržištu smanjuje se iz godine u godinu jer istim sve više prevladavaju igre za pametne telefone. Procjena za 2018. godinu je bila da će računalne igre zauzimati svega 26% tržišta. Usprkos tome, vrijednost tržišta računalnih igara je i dalje u rastu, samo što je taj rast sporiji od rasta tržišta igara za konzole i pametne telefone (Wijman, 2017).
Kompanije koje se bave izdavanjem igrara uglavnom imaju vanjske suradnike ili vlastite sestrinske kompanije specijalizirane za razvoj igara. Najveći i najpoznatiji izdavači igara su Electronic Arts, Bethesta, Ubisoft, Rockstar, Activison, Blizzard, itd.
1.1 Opis igre
Igra opisana u ovom radu naziva se „Alpha-Bravo“. Naziv simbolizira cilj igre, a to je prelazak s početne točke „A“ na krajnju točku „B“ u žargonu vojne abecede. Ista pripada žanru platformskih igara.
Pokretanjem igre otvara se početni izbornik u kojem igrač može birati različite mogućnosti: započinjanje nove igre, učitavanje već započete igre, otvaranje prozora s opcijama (odabir tipki za igru i kontrola zvuka) i izlaz iz igre.
Igrač ima ulogu vojnika na zadatku. Cilj igre je prolazak kroz pustinju u koju je igrač iskrcan na početku te se pritom obraniti od neprijatelja i izbjeći prepreke. Neprijateljski vojnici napadaju igrača kao pješaci ili u vozilu, a prepreke predstavljaju nagazne mine i razne zamke na tlu. Pored pustinje, igra se odvija i u raznim neprijateljskim utvrdama. Za izradu igre korišteno je preko 120 objekata, 130 vizualnih prikaza objekata, 170 slika, 8 zvukova, 17 soba i 6 fontova.
1.2 Usporedba okruženja za razvoj igara
Okruženja za izradu igara (eng. game engine) počele su se pojavljivati sredinom 1990-ih paralelno sa razvojem prvih 3D računalnih igara. One služe kako bi se ubrzao i pojednostavio proces razvoja igara. Prve računalne igre bilo je potrebno razvijati od samog početka. Okruženja za razvoj igara razdvajaju grafički prikaz, zvučni sustav i osnovne logičke elemente koje samo okruženje definira od pravila igre i umjetničkih elemenata kao što su primjerice zvučne ili slikovne datoteke koje unosi, kreira i kodira programer. Prema tome, okruženja za razvoj igara programeru nude temelje na kojima on gradi igru. Okruženja se prvenstveno razlikuju po složenosti. Dok složenija nude manje detaljne temelje i okvire igre zbog čega je pomoću njih moguće izraditi kompleksnije igre, jednostavnija okruženja sadrže detaljnije predloške s kojima je puno lakše raditi, ali ta okruženja nude puno manje mogućnosti za razvoj igara.
66 CASE2019
Okruženja se razlikuju i po tome što su često specijalizirana za pojedini žanr igara. Primjerice, okruženje dizajnirano za borilačku igru koja je namijenjena dvojici igrača biti će znatno drugačije od onog za veliku skupinu online igrača, pucačine iz prvog lica ili strategije. S druge strane, spomenuta okruženja i dalje mogu imati mnogo zajedničkih karakteristika kao što su sličan sustav za grafički prikaz ili sličan zvučni sustav (Gregory, 2018).
Game Maker spada među srednje zahtjevna okruženja za razvoj igara te je kao takav jednostavan za korištenje, ali i ograničen. Prvenstveno je namijenjen izradi 2D igara. Postoji nekoliko srodnih 2D okruženja kao što su Game Salad i Stencyl. Ta su dva okruženja namijenjena početnicima kojima omogućuju da nauče osnove izrade igara i logiku programiranja.
Game Salad se temelji na „povuci i spusti“ načelu te ne nudi mogućnost kodiranja. Spomenuto okruženje ima svoju fiziku koju je moguće mijenjati i pravila koja se pridružuje kreiranim objektima (Tanant, 2018). Proces izrade igre u okruženju Game Salad prikazan je na slici 1. U gornjem dijelu lijeve strane slike mogu se vidjeti kreirani objekti koji se dodaju u igru, a ispod njih se nalazi popis funkcija koje se pridružuju tim objektima. Na desnoj strani slike prikazan je trenutni izgled igre. Za razliku od Game Salad, u okruženju Game Maker programer mora samostalno definirati „fiziku“ koristeći kôd ili predloške.
Stencyl se temelji na vizualnom programskom jeziku Scratch koji je razvio tim sa Massachusetts Institute of Technology (MIT). Scratch sadrži gotove linije kôda koje se slažu poput slagalice. Iako se temelji na metodi „povuci i spusti“, Stencyl je odlično okruženje za učenje programiranja jer prikazuje programski kôd te olakšava njegovo razumijevanje (Tanant, 2018). Kodiranje u okruženju Stencyl primjenom jezika Scratch prikazano je na slici 2. Na lijevoj strani slike nalazi se lista događaja i ukoliko dođe do jednog od njih, aktivira se odgovarajući kôd koji je vidljiv na sredini slike. U gornjem dijelu desne strane slike nalazi se popis različitih vrsta funkcija. Nakon što je odabrana željena vrsta funkcije, otvara se prozor s funkcijama odabrane vrste koje programer zatim ubacuje u glavni kôd. Dok je Stencyl primarno namijenjen edukaciji početnika, Game Maker nudi mogućnosti i za iskusnije programere.
Slika 1. Game Salad
Slika 2. Stencyl
CASE2019 67
Godot je jedno od najpopularnijih okruženja otvorenog koda za izradu igara. Za razliku od prethodno opisanih okruženja, Godot nudi mogućnost izrade 2D i 3D igara. Godot se ne temelji na metodi „povuci i spusti“, već je u svrhu izrade igre potrebno razumijevanje koncepata programiranja te određena količinu predznanja u tom kontekstu.
Proces izrade dvodimenzionalne igre u okruženju Godot prikazan je na slici 3. Na sredini slike je prikazan odabir scene u koju programer postavlja objekte. Na gornjem dijelu lijeve strane slike nalazi se popis raznih scena koje se nalaze u projektu. Ispod toga nalazi se popis vanjskih datoteka korištenih u projektu. Na desnoj strani slike nalazi se lista čvorova u trenutnoj sceni, a ispod toga prozor s postavkama odabranog čvora. Čvorovi u okruženju Godot predstavljaju klasu za sve objekte u sceni. Iste je moguće slagati hijerarhijski u odnos djece i roditelja što rezultira strukturom stabla (Docs Godot, 2018).
Slika 3. Godot
Game Maker se pokazao kao najbolje okruženje za ovaj projekt zbog toga što pruža ravnotežu jednostavnosti za početnike i slobode za stvaranje novih igrica za iskusne programere. Obzirom da podržava kodiranje, Game Maker omogućava izradu složenijih igara nego što to nude Game Salad i Stencyl dok mogućnost korištenja metode „povuci i spusti“ početniku olakšava učenje izrade igara (Vinciguerra, 2018).
2. GAME MAKER
Game Maker razvijen je 1999. godine od strane tvrtke YoYo Games. Igre u okruženju Game Maker se mogu izrađivati za različite platforme uključujući Microsoft Windows, PlayStation 4, Ubuntu, MacOs, Android, iOS, XboxOne, itd. Glavni fokus okruženja Game Maker je izrada 2D igara, no može ih se izrađivati i u 3D-u. Razvoj igara u okruženju Game Maker se temelji na vizualnom programiranju (povuci i spusti) i skriptnom programiranju (GML).
2.1 Rad u okruženju Game Maker
Igre se u okruženju Game Maker kreiraju primjenom većeg broja resursa različitih vrsta. Resursi u okruženju Game Maker označavaju različite vrste datoteka koji su u isti učitani ili unutar okruženja kreirani. Primjeri resursa su zvukovi, slike, pozadinske slike, objekti, skripte, fontovi, sobe, itd. Spomenutim se resursima zatim dodjeljuju razne radnje, uloge ili drugi resursi.
Objekti
Objekti su elementi igre koji se nalaze u sobi i izvršavaju većinu radnji. Kako bi se u igri išta moglo odvijati, potrebni su objekti. Objekti mogu imati pridružen vizualni prikaz koji omogućava njihovu vizualizaciju unutar sobe za vrijeme igre.
Objekti imaju mnoge karakteristike osim samih zadataka koje izvršavaju. Može ih se postaviti da budu nevidljivi bez obzira na to imaju li vizualni prikaz ili ne. Mogu biti „čvrsti“ (eng. solid) i kao takvima može im se pridružiti funkcija da ne mogu prolaziti kroz druge čvrste objekte. Objektima se može zadati karakteristika „postojanost“ (eng. persistence) koja pamti promjene u objektu nakon promjene sobe. Ukoliko objekt nije postojan, sve radnje i vrijednosti varijabli vraćaju mu se na početnu vrijednost. Dubina objekta označava koji objekti se iscrtavaju ispred, a koji iza. Zadana vrijednost dubine je 0. Objekt s dubinom 1 iscrtava se iza onoga s dubinom 0, a objekt s dubinom -1 ispred onoga s 0. Objekti mogu nasljeđivati karakteristike drugih objekata. Objekt koji od drugog nasljeđuje karakteristike predstavlja njegovo dijete dok je objekt od kojeg se karakteristike nasljeđuju roditelj.
68 CASE2019
Objekti se ne nalaze u igri, već predstavljaju predložak za instance koje se postavlja u sobe (YoYo Games, 2018). Objekti koji vrše radnje sadrže programski kôd i događaje (eng. events). Radnje objekata organizirane su prema događajima koje objekt sadrži. Događaji su različite moguće situacije za vrijeme trajanje igre. Ukoliko do njih dođe, aktiviraju kôd koji im je pridružen. Događaji se provjeravaju za svaku instancu objekta koja se nalazi u sobi zasebno te za svaki trenutak (eng. frame) postojanja te sobe. Neki od primjera događaja su: nastajanje instance objekta u sobi, nestajanje, postojanje instance, pritisak tipke na tipkovnici, otpuštanje tipke na tipkovnici, kolizije objekata, itd. Izbornik za upravljanje karateristikama objekta „ob_player“ prikazano je na slici 4. Na lijevoj strani slike opisane su različite karakteristike objekta kao što su dubina, postojanost, naziv objekta, pridruženi vizualni prikaz, itd. Na sredini su izlistani događaji koje instance tog objekta provjeravaju za vrijeme postojanja u nekoj sobi, a desno se nalaze radnje pridružene događaju „step“.
Slika 4. Izbornik za rad s objektom „ob_player“.
Soba
Prvi korak nakon otvaranja novog projekta je kreirati barem jednu sobu (eng. room), kako bi se igra mogla pokrenuti. Sobe u okruženju Game Maker predstavljaju grafičko sučelje igre, to jest prostor u kojem se sve događa. Sobe se sastoje od dvodimenzionalnog prostora reguliranog različitim parametrima. Nove sobe kreiraju se prazne. Parametri sobe prikazani su u izborniku na lijevoj strani prozora sobe u postavkama (eng. settings). Parametri su veličina sobe (visina i širina) izražena u pikselima, naziv sobe i brzina. Brzina (eng. speed) sobe označava učestalost izvršavanja koda u jednoj sekundi. Ukoliko je brzina sobe postavljena na 30, cijeli kod koji se nalazi u sobi izvršit će se 30 puta u jednoj sekundi. Gornji lijevi kut sobe je početna točka (x=0, y=0). Vrijednost koordinate x raste u desnu stranu, a koordinate y prema dolje (YoYo Games, 2018).
Soba može imati i kôd kreiranja (eng. creation code) koji se izvršava u trenutku generiranja sobe, a prije izvršavanja kôda objekata. Osim parametara, u izborniku se nalaze i drugi alati pomoću kojih se mogu izmjenjivati objekti, pozadine, pločice (eng. tiles), fizika i pogledi (eng. views).
Instance objekata se u sobu postavljaju klikom na željenu poziciju u prostoru. Odabiru se u alatu objekti (eng. objects) u kojem se pojedinačnim objektima mogu još dodatno izmjenjivati širina i visina, boja, kut zakrivljenosti i prozirnost.
Alat pozadine (eng. backgrounds) služi za dodavanje pozadinskih slika u sobu. Pozadinskim slikama može se dodijeliti brzina (zadana vrijednost brzine je 0), promijeniti dimenzije i početna točka. Ukoliko se u sobu postavi više pozadina, potrebno je odrediti hijerarhiju pozadina, to jest koja treba ići iznad koje.
Slika 5. Izbornik za rad sa sobom „room_2_1“.
CASE2019 69
Soba iz igre koja je razvijena za potrebe ovog rada nazivom „room_2_1“, veličine 7234*968 piksela i brzine 60 prikazana je na slici 5. U prostoru sobe nalaze se objekti pješčanih blokova, kaktusi, kamenje, vojnik, itd., a pozadina je jednobojna plava slika.
Pogled (eng. view) je mehanizam koji omogućuje prikaz odabranog djela ekrana. Pogled se u dvodimenzionalnim igrama koristi kad je objekt igrača premalen da bi bio vidljiv ukoliko se prikazuje cijela razina. U većini slučajeva, pogledu je zadano da prati objekt kojim upravlja igrač. U alatu za upravljanje pogledima može se definirati više pogleda te im se mogu izmjenjivati dimenzije, rezolucija, objekt koji prate, brzina praćenja tog objekta te pozicija u kojoj praćeni objekt treba biti.
Vizualni prikaz objekta
Vizualni prikazi objekta (eng. sprite) su resursi sa slikom ili animacijom (skupom slika) koji se pridružuju objektu. Uloga im je učiniti objekt vidljivim u igri.
Nakon što je kreiran resurs vizualnog prikaza, potrebno mu je pridružiti jednu ili više slika. Ukoliko mu se pridruži više slika, svaka pojedinačna slika postaje pojedini kadar animacije. U Game Maker se mogu učitati (eng. import) slike različitih formata. Osim standardnih (kao što su primjerice .png i .jpeg, itd.), mogu se učitati i vektorske slike te skeletalne animacije. Game Maker sadrži i potprogram za uređivanje ili crtanje slika i animacija (eng. Image Editor).
Vizualnom prikazu objekta potrebno je odrediti glavnu točku, odnosno početnu koordinatu. Kada se vizulani prikaz pridruži objektu, glavna točka predstavlja koordinate na kojima se objekt nalazi. Vizualnom prikazu se pridružuje „maska“ za kolizije. Maska, bez obzira na sliku vizualnog prikaza kojem je pridružena, predstavlja skup točaka koje igra smatra tim prikazom. To znači da može doći do kolizije objekata i kad igrač to ne vidi. Maska se može prilagoditi kako bi imala oblik jednak obliku slike ili drugačiji oblik. Zadani oblik je pravokutnik širine i visine jednakih najdaljim točkama od središnje točke prikaza. Slika 6 prikazuje izbornik za rad s vizualnim prikazima.
Slika 6. Izbornik za rad s vizualnim prikazom „sp_deco3“.
Zvukovi (sounds)
Nakon kreiranja resursa zvuka (eng. sound) pridružuje mu se datoteka s računala i odabire ime. Zvukovi služe kao zvučni efekti ili kao glazbena pozadina u igri. Učitani zvukovi se u Game Makeru ne pridružuju objektima, već ih se poziva kroz funkcije. Učitanom zvuku može se mijenjati frekvencija, brzina, kvaliteta te ga se može prilagoditi za 3D prostor ili kao mono zvuk.
Pozadine (backgrounds)
Pozadine (eng. backgrounds) se, kao i vizualni prikazi objekata, temelje na slikama. Kreiranoj pozadini može se mijenjati naziv i slika. Također je moguće odabrati hoće li pozadina biti korištena kao velika slika ispred koje se generiraju objekti ili kao skup pločica (eng. tiles), malih pozadina koje se međusobno nadovezuju. Pozadina se odabire za svaku pojedinu sobu. U alatu za upravljanje pozadinama, istima se mogu dodjeljivati neke karakteristike koje ne utječu na samu datoteku pozadine.
2.2. Game Maker Language (GML)
Kako bi objekti mogli nešto izvršavati, u događaje im je potrebno dodati radnje. Radnje se mogu dodati metodom povuci i spusti ili kodiranjem. Povuci i spusti metoda označava skup radnji gdje se postojeći zadaci za objekt ubacuju u događaj u željenom poretku kako bi se kreirala radnja. Međutim, ta metoda je ograničena na mali broj mogućnosti te je zbog toga poželjnije koristiti programski kôd koji ih nudi puno više. Game Maker sadrži svoj posebno kreiran programski jezik, GML. Kako bi se pristupilo prostoru za upis GML kôda, u događaj je potrebno postaviti radnju izvršavanja koda (eng. execute code). GML je prevedeni programski jezik koji je sintaksno sličan programskim jezicima poput C, C++ i Python-a. Obzirom da je GML interpretirani jezik, linije kôda se prevode u izvršni format svaki puta kada se program izvršava. (Ford, 2010).
70 CASE2019
Varijable
Prilikom deklariranja varijabli u Game Maker-u nije potrebno deklarirati i tip varijable (integer, string, character, itd.), već istu Game Maker sam svrsta u određeni tip prema vrijednosti koja joj je pridružena. U Game Maker-u postoje kategorije varijabli, koje razlikuju varijable prema tome čemu pripadaju.
Kategorije varijabli su sljedeće:
Najčešći tip varijabli su one koje se definiraju unutar instance objekta. Te varijable su jedinstvene za svaku instancu i mogu se koristiti za svaki događaj i svaku funkciju te instance. Varijablu tipa instance može pozvati ili deklarirati i instanca nekog drugog objekta, potrebno je navesti ime objekta kojem pripada ili u kojem se deklarira prije imena varijable.
Kako bi varijabla bila lokalna, potrebno joj je prilikom deklaracije ispred imena postaviti deklaraciju var. Lokalna varijabla se može koristiti samo u događaju objekta ili skripti u kojoj je deklarirana.
Kada je varijabla globalna, ista pripada igri, a ne pojedinoj instanci. Svaka instanca može ravnopravno provjeravati ili mijenjati varijablu ovoga tipa. Kako bi varijabla bila globalna potrebno joj je prilikom deklaracije ispred imena dodati deklaraciju global.
Ugrađene ili programske varijable su automatski integrirane u objekte i sobe. Egzistiraju isključivo kao varijable iz kategorije instance ili globalne varijable. Prepoznaje ih se po tome što se njihovo ime pojavljuje u crvenoj boji (YoYo Games, 2018).
Slika 7 prikazuje načine deklariranja različitih tipova i kategorija varijabli. Varijable „prva“ i „druga“ spadaju u kategoriju varijable instanci. „Prva“ je tipa integer, a druga tipa string. „Treca“ varijabla je lokalna i tipa integer. Varijabla „cetvrta_varijabla“ primjer je globalne varijable i tipa string. Varijable „x“ i „image_yscale“ su programske varijable. Varijabla „sedma“ je varijabla tipa integer koja ne pripada objektu u kojem se izvršava kôd, već objektu „ob_objekt“ što je primjer pozivanja varijable kategorije instanca drugog objekta.
Slika 7. Primjer deklaracije sedam različitih vrsta varijabli.
Funkcije
GML sadrži mnogo zadanih funkcija koje se mogu svrstati u više kategorija. Iste služe za rad s objektima, zvukovima, instancama, varijablama, tekstom, crtanjem, itd. Ukoliko je funkcija ispravno napisana biti će žute boje.
Primjeri GML funkcija:
Instance_create (prikazana na slici 8) primjer je funkcije koja radi s instancama i prima argumente. Riječ je o funkciji za kreiranje instanci objekata koja kao argumente prima koordinate položaja nove instance i naziv željenog objekta. U primjeru na slici funkcija kreira objekt „object3“, 100 piksela desno od početne točke sobe i 250 piksela ispod objekta koji poziva funkciju (y je programska varijabla tipa instance objekta koji poziva funkciju).
Slika 8. Funkcija za stvaranje instanci: „instance_create(x,y,obj)“.
Game_end je primjer funkcije koja ne prima ni jedan argument, a služi za izlazak iz igre. Slika 9 prikazuje pozivanje funkcije „game_end“ ukoliko funkcija za provjeru tipke escape (ESC) vrati pozitivan rezultat.
Slika 9.Funkcija izlaska iz igre: „game_end“.
CASE2019 71
3. ZAKLJUČAK
Razvojna okruženja poput Game Makera uvelike olakšavaju izradu igara. Osim toga, Game Maker je prikladan za početnike koji se žele okušati u razvoju igara, a nemaju predznanje iz programiranja. Ako se početnici umjesto metode povuci i spusti odluče za GML, također neće imati nekih poteškoća i izradi igre jer GML „oprašta“ situacije poput izostavljene točke i zareza na kraju linije, ne iziskuje deklaraciju varijabli, itd. S druge strane, navedeno predstavlja nedostatak zbog toga što je prilikom izvršavanja potrebno prevoditi sve te pogreške zbog čega izvršavanje programa traje nešto dulje. Ako se početnici odluče za metodu povuci i spusti, biti će puno ograničeniji u mogućnostima razvoja igre, ali će im biti lakše za razumijeti algoritme od kojih je igra sačinjena.
Literatura:
1 Docs Godot, (2018), dostpuno na: https://docs.godotengine.org/en/3.0/classes/class_node.html?highlight=node
2 Ford J.L. Jr. (2010), Course Techology Ptr., „Getting Started With Game Maker“.
3 Gregory J. (2018), CRC Press, „Game Engine Architecture, Third Edition“.
4 Tanant F. (2018), WebsiteToolTester, „The best game engines for beginners“, dostpuno na: https://www.websitetooltester.com/en/blog/best-game-engine/
5 Vinciguerra D.C. & Howell A. (2018), CRC Press, „The Game Maker Standard“.
6 Wijman T. (2017), Newzoo, „New Gamin Boom: Newzoo Ups Its 2017 Global Gamers Market Estimate...“, dostupno na: https://newzoo.com/insights/articles/new-gaming-boom-newzoo-ups-its-2017-global-games-market-estimate-to-116-0bn-growing-to-143-5bn-in-2020/
7 YoYo Games, (2018), dostupno na: https://docs.yoyogames.com/source/dadiospice/002_reference/index.html
Podaci o autorima:
Vlatko Matić, univ. bacc. inf.
e-mail: [email protected]
Vlatko Matić je 2018. godine stekao akademski naziv sveučilišnog prvostupnika informatike na Fakultetu Informatike Sveučilišta Jurja Dobrile u Puli. Glavna područja interesa su mu izrada igara u okruženjima Game Maker Studio i Unity 3D. U slobodno vrijeme bavi se 3D modeliranjem u Blenderu i radom u Gimpu.
doc.dr.sc. Tihomir Orehovački
e-mail: [email protected]
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. Od 1. listopada 2015. godine zaposlen je na radnom mjestu docenta na Fakultetu 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 89 znanstvenih radova objavljenih u zbornicima međunarodnih konferencija, časopisima i knjigama te 13 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 12 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, International Conference on Information Technology (ICIT) te International Conference on Software and Information Engineering (ICSIE). 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 65 studenata obranilo završne i diplomske radove.
Fakultet informatike u Puli
Sveučilište Jurja Dobrile u Puli
Zagrebačka 30, 52100 Pula
fipu.unipu.hr
Data Compliance Whitepaper®
GDPR CHALLENGESGoverning General Data Protection Regulation Challenges with Enterprise Data Architecture
BY SULTAN SHIFFA
OVERVIEWToday, we live in a digitalized economy where globalization is driving businesses
across borders and data management needs more attention than ever.
The European Union’s General Data Protection Regulation (GDPR) becomes effective on
25 May 2018. In contrast to older directives and data protection acts, the GDPR will
bring new accountability obligations, increased data protection rights for EU citizens and
restrictions on data flows across borders. Organizations that process EU citizens’ personal
data must comply with the regulations, and this applies to all data owners, who say why
and how data is processed, and to data processors, who perform actions on the data.
It introduces also obligations to data breach notification, with stricter accountabilities that
personal data information is sufficiently managed and protected.
In this whitepaper, we discuss the most important facts that data management teams need
to consider to comply with the new requirements and how to tackle these challenges with
an enterprise data architecture solution, IDERA ER/Studio Enterprise Team Edition (ETE).
Diagram 1 shows the requirements and how ER/Studio ETE addresses these challenges.
Diagram 1 Organizational requirements for GDPR compliance and ER/Studio Enterprise Team Edition
CREATE AWARENESS FOR GDPR COMPLIANCE ACROSS THE ORGANIZATION
One of the first key tasks of the data management team and the Data Protection Officer (DPO) should be
to create awareness regarding the impact of GDPR on the business among executives, data controllers,
data processors and data leaders across the organization. In order to generate awareness organizations
need to have clearly defined documentation defining the policies, rules, requirements and the impact of
the non-compliance to the whole organization. This can be achieved with web-based centrally accessible
documentation of the applications, processes, business rules, data sources, business terms, stewardship,
roles, and obligations used across the organization.
With ER/Studio Enterprise Team Edition, organizations can establish a foundation for data governance using
the Team Server metadata repository and collaboration platform to share a glossary for GDPR regulations,
business terms and rules. Diagram 2 depicts how GDPR is documented and planned to be used, and the
policy each user has to follow. Users are able to track changes and get notified when changes occur to
GDPR regulations and organization-specific policies. It shows also the level of compliance necessary
for data elements.
This helps to set up the compliance by default criteria of the GDPR in establishing reusable standards,
transparency, and accountabilities to improve products, data movement chains, and processes, and
minimize risks.
Diagram 2 General Data Protection Regulation Documentation in Team Server
Diagram 3 Search and label data elements in all applications relevant to GDPR
UNDERSTAND THE CURRENT DATA LANDSCAPE
FOR BETTER GDPR COMPLIANCE
Most organizations face the complication of diverse and disconnected data residing in different applications
supporting various platforms. Additionally, data is managed by different people, technologies and processes
and stored in different storage areas and formats. In order to connect those different ecosystems of data,
organizations need a centrally accessible data location to show where their data resides and how it interacts
with upstream and downstream applications. At a technical level, organizations need to maintain and search
their enterprise databases to identify data items and trace the data relationship between the different terms,
attributes, rules, and reported or calculated results.
Each organization should start with data discovery to get prepared for GDPR. That means, begin by getting into
databases (relational, NoSQL, Big Data, BI, ETL resources) and systems and documenting exactly what kind of
data is stored in those applications, data stores and platforms. The supervisory authorities expect organizations
to know where and how sensitive personally identifiable information (PII) is stored and processed.
With ER/Studio Team Server, organizations are able to manage all disconnected applications in one catalogue
and to search for any information stored in glossaries, business terms, processes, and data elements residing in
different applications and databases across the organization. This helps all business and technical users
to locate silos of “hidden” data across the organization and to spot the relationship existing between them. To be
in line with GDPR rules, all previously defined personal information data in all applications can be easily searched
and labelled using GDPR relevant information, as shown in Diagram 3.
CHECK EXISTING PROCEDURES
REGARDING CURRENCY TOWARDS GDPR
Most of the larger organizations do have procedures and processes to demonstrate compliance due
to prior data protection laws or they have a manual documentation of the rules and policies. It is the
right time to look into those existing procedures and contracts with partners and suppliers and to
analyze their currency and applicability towards the new GDPR regulations.
ER/Studio Business Architect can be used to define and graphically represent the necessary
processes and actions to take. These processes show which data is accessed, which documents
need a review, and which parties are involved in each process.
Diagram 4 below shows an example for establishing the necessary processes, tasks and people
involved to attain that goal. This information can be maintained, kept alive and shared across the
organization. As processes are reviewed, they can be optimized to eliminate any redundancies.
Diagram 4 ER/Studio Business Architect process diagrams show procedures and action plans
REVIEW PRIVILEGES AND ACCOUNTABILITIES TO DATA AND ITS FLOW
One of the key issues in terms of data management and maintenance is ownership. We keep always asking:
Who is the owner the data? Who is able to create, read, update, and delete that data? Or can I send this data
to a third party person? For GDPR compliance, we need first to understand who is responsible for the data
objects, who has access to it and how this data is used across different departments.
ER/Studio Enterprise Team Edition consists of different components to define, maintain and understand the
ownership and the flow of digitized data. It helps data owners also to identify and protect the data relating to
identifiable individuals. Diagram 5 below shows how data stewardship can be assigned and managed in ER/
Studio Enterprise Team Edition. Diagram 6 displays a data lineage diagram that supports data flows and data
ownership documentation.
Diagram 6 ER/Studio’s data lineage supports data flows and data ownership documentation
Diagram 5 Stewards assigned to business terms and additional custom ownerships defined
DOCUMENT AND MANAGE INDIVIDUAL RIGHTS
The new GDPR law strengthens the data protection rights for EU citizens and they will have more rights
regarding their personal data information than any previous data protection directives.
According to the new law:
• Personal data must be erased if individuals do not want their data to be processed.
• They have to opt-in instead of opt-out. In order to process personal data information, organizations need
an active consent from individuals, which applies only for the purpose the consent was given.
• Data must be transparent and users have the right to know which data is stored and how it is processed
by organizations and their partners located in the European Union or elsewhere.
• Data must be portable. That means organizations have to ensure that data can easily be transferred from
one service provider to another.
That means organizations should keep records of what customers consented to and make it accessible in
case they are asked to provide proof. On the other side, organizations should know what data they have
received from other suppliers and how long to keep them. Most business applications today and their existing
data models do not currently include these additional GDPR-related PII fields. With ER/Studio Data Architect,
organizations can model, tag, capture permissions, and relate critical data elements, business data objects,
and attributes defined across the organization with customizable metadata information and rules like data
erasure, access, portability and usage, as seen in Diagram 7.
Diagram 7 Data Architects can define the rules for sensitive information within the model
This information gets published into ER/Studio Team Server where users can view relevant data objects,
as seen in Diagram 8. This allows, for example, a search for all data elements which need “data access or
erasure” across all applications and a report to be generated for analysis and auditing. As shown in Diagram
9 below, ER/Studio Team Server comes with an interactive diagram viewer, providing users with a visual and
interactive representation of data objects, rules and related parent objects. Diagram 10 displays search results
on critical and sensitive data objects tagged with GDPR rules and annotations.
Diagram 10 Data Elements can be tagged with GDPR rules and annotations
Diagram 9 Data Analysts can view and print diagrams that show how data entities are tied to GDPR rules
Diagram 8 Business analysts can search all data objects across applications related to data subject “transparency and consent”
DEFINE PROCESSES FOR SECURITY MANAGEMENT AND DATA BREACH NOTIFICATION
GDPR will introduce data loss and breach notification requirements and requires security of processing
personal information. That means organizations have to implement technical and organizational measures
to meet these requirements.
ER/Studio Business Architect can be used to define, document, search and report on the processes,
technology and people involved in case of a personal data breach and the actions organizations must take
to comply with the data processing.
As shown in Diagram 11, data architects can define and attach metadata information to the customer data
regarding data processing and GDPR compliance. The process diagram shown in Diagram 12 represents the
supervisory authorities which must be informed, along with all information and data subjects which must be
included in the notification. These data can also be shared with authorities if they might want to perform auditing
of the data protection rules and technologies implemented to secure data processing activities.
Diagram 11 Metadata for data security and GDPR- related rules for Customer
Diagram 12 ER/Studio Business Architect data breach workflow process diagram
DATA GOVERNANCE, COLLABORATION AND DATA PROTECTION IMPACT ASSESSMENT
The pillars of data quality, security and enhancement are data governance processes and organizational setups
existing within an organization. The data governance team and the data architects play an important role to meet
the regulatory compliance with GDPR. They need to develop a compliance plan to address all potential issues
necessary to improve existing systems and to create standards for future systems, including products, data
flows and processes where people are involved. This plan should involve and come from all departments as this
encompasses the whole organization. A successful data governance program is also based on collaboration.
Every business application project should involve not only the development or testing team but also the data
owners, business analysts, subject matter experts and data leaders. Not considering those resources might
require application re-design if the impact on data protection cannot be envisaged appropriately.
It is also a good practice to have a data protection impact assessment (DPIA) to understand the impact of
unintended data changes and the business risks associated with this change. According to GDPR, DPIA is a must
for organizations dealing with “large scale data processing.”
ER/Studio Enterprise Team Edition helps also to identify where data elements are used across different
applications and databases. Additionally, metadata attachments can be added to those personal data elements
to investigate and document how such risks will be mitigated. Collaboration is intrinsic and a key functionality
within the product with the ability to discuss and comment on all data elements. All the data is transparent and
accessible across the organization via a web interface. As compliance must be continual, organizations need to
have an end-to-end living documentation of their data governance compliance plan at their fingertips anytime.
Diagram 13 below shows how visual metadata information like DPIA risks can be associated with customer
personal data in ER/Studio Data Architect.
Diagram 13 This diagram depicts the checklists and risks associated with the customer data
Diagram 14 shows the related data objects associated with the specific entity, and Diagram 15
displays how the information is shared across the organization in ER/Studio Team Server.
Diagram 14 The Universal Mapping facility in ER/Studio shows related data objects across different applications
Diagram 15 The organization can run discussions and learn about data compliance and usage
SUMMARY
GDPR expects customer data privacy and industry compliance by design and default.
The first step to support data protection requirements would be to establish a robust data governance
program and create awareness about the rules and impact of not being GDPR compliant, leveraging
integrated process and data modeling tools.
Discovery is the second step to look into existing systems and processes. Whether we are working
on new systems or looking into existing legacy systems, we need to store and maintain our data fields
in line with the GDPR rules. ER/Studio Enterprise Team Edition gives organizations visibility into their
applications, databases and processing activities holding critical information for GDPR compliance.
It helps them to understand the data itself, the applications using it and how it is used across
repositories and enables compliance by design.
Finally, ER/Studio serves as a collaboration platform for sharing information related to different
applications and systems across the organization. It helps also to document and encourage
discussions on data how organizations are complying with GDPR legislation within the organization
and external regulators in case of an audit.
IDERA understands that IT doesn’t run on the network –
it runs on the data and databases that power your business.
That’s why we design our products with the database as
the nucleus of your IT universe.
Our database lifecycle management solutions allow database
and IT professionals to design, monitor and manage data systems
with complete confidence, whether in the cloud or on-premises.
We offer a diverse portfolio of free tools and educational resources
to help you do more with less while giving you the knowledge to
deliver even more than you did yesterday.
Whatever your need, IDERA has a solution.