Predgovor

Stanje na svetskom tritu i konkurentski uslovi zahtevaju brzu i kontinuiranu promenu, kao i permanentno prilagoavanje i fleksibilnost preduzea kako bi se zadovoljili svi inioci uspenosti poslovanja. Informacione tehnologije, raunari i raunarski sistemi postali su neizostavni deo svakog preduzea, bez obzira na njegov profil. Kljunu ulogu u razvoju poslovanja ima primena informacione i raunarske tehnologije, koje konstantno nude nove mogunosti.

Sama sloenost i raznovrsnost preduzea podstakla je i razvijanje razliitih vrsta pristupa, metoda i alata koji bi odgovorili ovim izazovima. Sama sutina ovih razvijanja ogledala se u podizanju nivoa apstrakcije i koncentrisanje na sutinu problema kojim se preduzee bavi, koristei pri tom ve postojee alate ili implementaciju novih.

U poslednjem periodu velika dostignuca i popularnost nastaju na polju modelovanja i definisanja jezika specifinih za domen. Jezici specifini za domen su programski jezici kreirani za reavanje problema u odreenom domenu. esta je praksa da se prilikom modelovanja koristi ve neki od postojeih meta-modela ali takav nain pristupa najee ne omoguava najbolji nain za opis elemenata konkretnog domen-specifinog sistema. Takoe, takvom vrstom realizacije domen-specifinih jezika programeri su ogranieni alatima koje mogu koristiti pri samoj izradi jezika. Zbog toga dolazi do potrebe za definisanjem sopstvenih jezika, kao i alata prilagoenih domenu problema koji je predmet realizacije.

Zadatak izdrade ovog rada je sledei:

Dizajnirati i implementirati tekstualni jezik za opis toka poslova Dizajnirati i implementirati vizualizator za opis toka poslova Napraviti interpreter koji e vriti instanciranje opisa, njegovo izvravanje i pratiti njegovo stanje

Rad sadri pet poglavlja:

Prvo poglavlje daje pregled i razvoj oblasti na kojoj se zasniva ovaj rad, zatim teoretski opis pojmova koricenih u ovom radu. Drugo poglavlje se bavim opisom i izborom osnovnih alata korienih pri implementaciji ovog rada. Tree poglavlje se bavi implementacijom jezika, njegovom vizualizacijom kao i editorom u okviru koga se modeluju tokovi poslova. Takoe u okviru ovog poglavlja prikazana je i implementacija interpretera. etvrto poglavlje predstavlja studiju sluaja, koja predstavlja konkretan primer funkcionisanja implementiranog zadatka. Peto poglavlje se bavi sumiranjem odnosno zakljucima o radu, kao i o daljim pravcima razvoja.

Koristim ovu priliku da se zahvalim mom mentoru prof. dr. Igoru Dejanoviu na pomoi, razumevanju i strpljenju tokom izrade ovog rada.

Zekovi Avram

4. Studija sluaja

Studija sluaja predstavlja implementaciju i interpretaciju modela poslovnog procesa kreiranog na osnovu primera ija e postavka biti izneta u nastavku rada. Studija sluaja je podeljena na etiri dela, u prvom delu u okviru postavke sluaja, opisan je poslovni proces, u drugom delu su identifikovani zadaci i uloge u okviru poslovnog procesa, trei deo prikazuje implementaciju modela poslovnog procesa dok etvrti prikazuje interpretaciju.

Osnovni cilj studije sluaja je, da se kroz primer poslovnog procesa, aplikacije opisane u ovom radu priblie korisnicima na nain, da korisnici kvalitetnije i jednostavnije razumeju naine funkcionisanja i implementacije opisanih aplikacija. 4.1. Postavka sluaja

U nastavku rada bie opisan poslovni proces prikupljanja i obrade dokumentacije potrebne za realizaciju programa i projekata u oblasti obrazovanja, kulture i sporta koji se finansiraju putem javnih konkursa u okviru Fonda za razvoj ruralnih sredina (u daljem tekstu Fond).

Fond gorenavedenu aktivnost realizuje putem objavljivanja javnih konkursa za finansiranje programa i projekata. Javni pozivi za podnoenje prijava se objavljuju u Slubenom glasniku, u sredstvima javnog informisanja i na internet stranici Fonda. Nakon objavljenog javnog konkursa, koji su otvoreni tokom cele godine, zainteresovana lica prijavu sa prateom dokumentacijom, koja je propisana i kao takva neophodna za uestvovanje na javnom konkursu za dodelu sredstava, dostavljaju na pisarnicu Fondacije.

Referent za administrativne poslove, nakon prijema na pisarnici, pristigloj prijavi dodeljuje broj, evidentira je u dostavnoj knjizi i otvara omot spisa. Pored navedenog, referent prijavu paralelno uvodi u elektronsku bazu, tako to joj dodeljuje broj, otvara elektronski omot spisa i skenira prateu dokumentaciju koju vezuje za prijavu i postavlja je na server. Zatim u zavisnosti kojoj oblasti prijava pripada (obrazovanje ili kultura ili sport) elektronskim putem obavetava naelnika nadlenog Sektora u pripadajuoj oblasti (obrazovanje ili kultura ili sport) o pristigloj prijavi i dostavlja mu omot spisa prijave. Prema internom pravilniku Fonda, od momenta evidencije prijave do momenta prosleivanja prijave na dalju obradu naelniku nadlenog Sektora, ne sme da proe vie od 30 minuta.

Nakon prijema prijave, naelnik nadlenog Sektora u pripadajuoj oblasti (obrazovanje ili kultura ili sport) prihvata obavetenje i dobija elektronski uvid u kompletnu skeniranu prateu dokumentaciju. Naelnik zatim pregleda dokumentaciju, i u zavisnosti od toga da li je prijava ispravna, da li zadovoljava formu i da li sadri svu potrebnu, konkursom propisanu dokumentaciju, istu prosleuje na dalju obradu lanovima komisije (samostalnim strunim saradnicima) i omoguava im elektronski uvid u kompletnu skeniranu prateu dokumentaciju, ili u sluaju ako je priva neispravna istu prosleuje referentu Arhive - arhivatoru na dalju obradu. Prema internom pravilniku Fonda, naelnik nadlenog Sektora za gorenavedenu aktivnost ima propisan rok od najdue jednog dana.

U sluaju da je prijava neispravna i da je prosleena referentu Arhive - arhivatoru, tada arhivator nakon uvida u dokumentaciju pristupa arhiviranju prijave prema propisanim pravilima kancelarijskog poslovanja, nakon ega se poslovni proces zavrava. Prema internom pravilniku Fonda, arhivator za gorenavedenu aktivnost ima propisan rok od najdue tri dana.

U sluaju da je prijava ispravna i da je prosleena komisiji na dalju obradu, tada komisija nakon uvida u skeniranu dokumentaciju vri strunu ocenu prijave i popunjava elektronski obrazac za ocenjivanje. Po zavrenoj strunoj oceni, komisija alje obavetenje direktoru o strunoj oceni i omoguava mu elektronski uvid u popunjen obrazac za ocenjivanje i kompletnu skeniranu prateu dokumentaciju prijave. Prema internom pravilniku Fonda, komisija za gorenavedenu aktivnost ima propisan rok od najdue pet dana.

Kada direktor primi obavetenje i izvri elektronski uvid u dokumentaciju, donosi odluku da li e da podri finansiranje projekta predmetne prijave ili ne. U sluaju da podri finansiranje obavetava naelnika Sektora za odnose sa javnou, dok u sluaju ako ne podri finansiranje o tome obavetava referenta Arhive - arhivatora. Prema internom pravilniku Fonda, direktor za gorenavedenu aktivnost ima propisan rok od najdue sedam dana.

U sluaju da direktor podri finansiranje, tada naelnik Sektora za odnose sa javnou po dobijenom obavetenju od strane direktora, postavlja obavetenje za javnost na internet stranici Fonda, nakon ega se poslovni proces zavrava. Prema internom pravilniku Fonda, naelnik za gorenavedenu aktivnost ima propisan rok od najdue jednog dana.

U sluaju da direktor ne podri finansiranje, tada referent Arhive - arhivator po dobijenom obavetenju, pristupa arhiviranju prijave prema propisanim pravilima kancelarijskog poslovanja, nakon ega se poslovni proces zavrava. Prema internom pravilniku Fonda, arhivator za gorenavedenu aktivnost ima propisan rok od najdue tri dana.

4.2. Identifikacija potrebnih parametara

Na osnovu postavke sluaja u okviru koje je detaljno opisan predmetni poslovni proces neophodno je identifikovati sledee najbitnije parametre: zadatke (tasks), uloge (roles) i rokove (deadlines).

Poslovni proces identifikuje sledee zadatke (tasks): Pisarnica, Sektor za sport, Sektor za kulturu, Sektor za obrazovanje, Komisija, Direktor, Sektor za odnose sa javnou i Arhivu.

Poslovni proces identifikuje sledee uloge (roles): Referent za administrativne poslove, Naelnik Sektora za sport, Naelnik Sektora za obrazovanje, Naelnik Sektora za kulturu, Komisija (koju ine lanovi samostalni struni saradnici), Direktor, Naelnik sektora za odnose sa javnou, Arhivator.Poslovni proces identifikuje sledee rokove (deadlines): 30 minuta, jedan dan, tri dana, pet dana, sedam dana.

4.3. Implementacija poslovnog procesa

Nakon identifikacije neophodnih parametara, pre svih zadataka (tasks), prikazan je model iz postavke sluaja sa svim detaljima, na Listingu XX. koji sledi:

workflow Konkurs(

description: "Konkurs za dodelu sredstava";

task Pisarnica(role: Referent;type: manual;deadline: 0D:0H:30M;description: "Obrada primljene dokumentacije i prosledivanje nadleznom sektoru";next: SektorZaSport, SektorZaKulturu, SektorZaObrazovanje;)

task SektorZaSport(role: NacelnikSport;type: manual;deadline: 1D:0H:0M;description: "Dodatna obrada i prosledjivanje komisiji/arhivi";next: Komisija, Arhiva;)task SektorZaKulturu(role: NacelnikKultura;type: manual;deadline: 1D:0H:0M;description: "Dodatna obrada i prosledjivanje komisiji/arhivi";next: Komisija, Arhiva;)

task SektorZaObrazovanje(role: NacelnikObrazovanje;type: manual;deadline: 1D:0H:0M;description: "Dodatna obrada i prosledjivanje komisiji";next: Komisija, Arhiva;)

task Komisija(role: ClanKomisije;type: manual;deadline: 5D:0H:0M;description: "Pregled prijava, strucna ocena i prosledjivanje direktoru";next: Direktor;)

task Direktor(role: Direktor;type: manual;deadline: 7D:0H:0M;description: "Donosenje odluke o finasiranju projekta i prosledjivanje SektoruZaOdnoseSaJavnoscu/Arhivi";next: SektorZaOdnoseSaJavnoscu, Arhiva;)

task SektorZaOdnoseSaJavnou(role: NacelnikOdnosiSaJavnosu;type: manual;deadline: 1D:0H:0M;description: "Postavljanje obavestenja o odluci na zvanicni sajt";next: Arhiva;)

task Arhiva(role: Arhivator;type: automatic;deadline: 3D:0H:0M;description: "Arhiviranje odbijenih prijava";))Listing XX. Model konkursa za dodelu sredstava

Izgled dijagrama odnosno viualizacija modela u aplikaciji Workflow Editor prikazana je na Slici x koja sledi.

Slika x. Grafiki prikaz modela Konkursa

Nakon implementacije modela konkursa klikom na dugme Upload aljemo interpreteru kreirani model, iju interpretacija e biti obraena u nastavku rada.

4.4. Interpretacija

Nakon uspene implementacije modela, prelazimo na njegovo pokretanje odnosno interpretaciju. Pre poetka, potrebno je uneti korisnike i njihove privilegije unutar poslovnog procesa u bazu podataka, to se vri preko Django admin dela, o emu je ve bilo rei ranije u prethodnim poglavljima. Nakon unoenja korisnika i njihovih privilegija, moemo krenuti sa pokretanjem procesa.

Nakon to referent za administrativne poslove, na pisarnici primi dokumentaciju od strane podnosioca prijave, on pokree proces logovanjem na web aplikaciju. Zatim obrauje primljenu dokumentaciju i na osnovu podataka iz iste donosi zakljuak kom je Sektoru namenjena. Onda alje dokumentaciju nadlenom Sektoru i zavrava zadatak. (Slika X)

Slika x.

Zavravanje zadatka od strane Referenta za administrativne poslove i odabirom sledeeg zadatka u ovom sluaju Sektora za sport, automatski je pokrenut zadatak za Sektor za sport odnosno za korisnike koji toj grupi pripadaju.

Poto je dokumentacija primljena, Sektor za sport je obrauje i odreuje da li je dokumentacija ispravna ili ne. U odnosu na to da li je dokumentacija ispravna ili ne, vri se odabir sledeeg zadatka, odnosno alje se na dalju obradu komisiji ili Arhivi.

U ovom sluaju zbog skraenja toka poslovnog procesa, pretpostaviemo da je dokumentacija neispravna i za sledei zadatak emo izabrati arhiviranje. Nakon prosleivanja obraene dokumentacije i slanja iste Arhivi Sektor za sport zavrava zadatak. (Slika X)

Slika x.

Logovanjem na sistem, odnosno aplikaciju, arhivatoru e nakon zavretka posla od strane Sektora za sport biti aktiviran zadatak da izvri arhiviranje prosleenje dokumentacije. Poto je ovo poslednji korak u ovom sluaju, korisnik nema mognost da izabere sledei zadatak. Nakon zavretka zadatka, odnosno arhiviranja proces je zavren. (Slika X)

Slika x.

5. Zakljuak

Kao to smo mogli videti iz prethodnog izlaganja, Domen-specifini jezici su iroko primenljivi i nemaju specijalizovane funkcije za odreeni domen, stoga su se nali ispred jezika pete generacije i CASE alata koji nisu uspeli da odgovore trenutnim zahtevima. Zbog svoje popularnosti i iroke upotrebe ovaj rad je i baziran na njima. Takoe zbog jednostavnosti implementacije i lakoe uenje izabrano je da ti DSL-ovi budu tekstualni za razliku od grafikih ija implementacija i razvijanje nije jednostavno i lako.

Ovaj rad takoe daje odgovor na koji nain se moe dizajnirati, implementirati i interpretirati poslovni proces. Tanije, rad opisuje razvoj softverskog inenjerstva i programskih jezika, zatim opisuje osnovne pojmove neophodne za dizajniranje i implementaciju poslovnih procesa kao i konkretne primere alata koji su korieni za izradu. Nakon toga u nekoliko koraka opisuje sam nain dizajna i implementacije tekstualnog jezika za opis toka poslovnog procesa korienjem Arpeggio parsera, kao i implementaciju interpretera poslovnog procesa pomou Django framework-a.

Takoe vano je napomenuti neke od prednosti razvijanja tekstualnog jezika pomou Arpeggio parsera. To bi u prvom pogledu bila njegova lakoa uenja, jednostavnost pri reavanju problema, dobre preformanse i konkurentnost u odnosu na ve postojee i Python parser-e, kao i mali sistemski zahtevi. Rad je zavren konkrentim primerom implementacije tekstualog jezika za opis toka poslova i njegovom intepretacijom.

Dalji pravci razvoja bi bili:

Proirenje postojeeg jezika za opis toka poslova ili eventualno prilagoavanje nekom uem krugu poslova Kod automatskog definisanja nain obraivanja poslova omoguiti definisanje ta je to to se poziva. Poziv npr. neke procedure ili skripte unapred definisane koja e taj posao odraditi umesto korisnika. Omoguiti validaciju koraka, koje bi predstavljalo pravilo koje mora biti ispunjeno da bi moglo prei na sledei zadatak odnosno posao. Npr. ako korisnik kae da je zavrio svojposao ovo pravilo moe da proveri da li je stvarno posao i gotov. Upravljanje poslom u specijalom sluaju kada korisnik nije u mogunosti da ga uradi. Ovo podrazumeva isakanje iz normalno toka poslovnog procesa I vraanje u normalu. Unapreenje vizualizacije toka poslova uvoenjem organizacije aktivnosti i podelu poslova u razliite vizuelne kategorije koje bi ilustrovale drugaiju funkcionalnost ili odgovornost. Zatim uvoenje novih vrsta relacija kao npr. asocijacija pomou koje bi mogli izvriti asociranje sa odreenim podacima ili tekstom u cilju prikaza i ulaza i izlaza poslova. Takoe uvoenje i odreenih artifakta koji bi reprezentatovai tekst ili podatke koji se asociraju, itd. Interpreter bi trebalo prilagoditi navedenim pravcima razvoja. Ukoliko se odlui za prilagoavanje jezika odreenog grupi poslova, prilagoditi interpreter uesnicima u toku poslova zavisno od vrste zadatka i ukoliko uslovi posla dozvoljavaju, izvrvanje posla direktno iz aplikacije odnosno interpretera.