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
svoj
posao 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.