Upload
others
View
6
Download
0
Embed Size (px)
Citation preview
Smetanova ulica 17
2000 Maribor, Slovenija
Goran Graf
MEDOBRATOVALNOST REŠITEV ZA
MODELIRANJE POSLOVNIH PROCESOV V
BPMN
Magistrsko delo
Maribor, februar 2015
I
MEDOBRATOVALNOST REŠITEV ZA
MODELIRANJE POSLOVNIH PROCESOV V
BPMN
Magistrsko delo
Študent: Goran Graf
Študijski program: Magistrski, 2. bol. stopnja
Informatika in tehnologije komuniciranja
Mentor: doc. dr. Gregor Polančič, univ.dipl.inž. rač. in inf.
II
III
ZAHVALA
Dr. Gregorju Polančiču za mentorstvo in
pomoč. Hvala, da ste bili v času študija
vedno korektni in na voljo za vsa
vprašanja.
Posebna zahvala staršem, ki sta mi
omogočila študij in verjela vame.
Zahvaljujem se bratu Urošu in punci Špeli
za spodbudo, podporo in dobro energijo v
času študija.
IV
MEDOBRATOVALNOST REŠITEV ZA
MODELIRANJE POSLOVNIH PROCESOV V
BPMN
Ključne besede: medobratovalnost, poslovni proces, bpmn, notacija
UDK: 004.414.23(043.2)
Povzetek
Magistrsko delo predstavlja rezultat opravljene analize na področju standarda BPMN 2.0
in rešitev, ki omogočajo modeliranje v omenjeni notaciji. Smer raziskave je področje
medobratovalnosti. Opravili smo pregled literature, relevantnih standardov in področij
zapisa BPMN. Poleg samega standarda BPMN 2.0, smo preučili še datotečne formate
BPMN, XML, XPDL in VSD. Nad izbranimi orodji (Signavio, Yaoqiang BPMN Editor in
Activiti (BPM Platform)) smo opravili analitični pregled podprtosti elementov notacije.
Prav tako smo izvedli posebno obliko eksperimenta in na praktičnem primeru preverili
zbrane ugotovitve. Zapisali smo ugotovitve o uspešnosti prenosa informacij. Ugotovitve so
pokazale, da nobeno orodje ni v celoti nudilo podpore standardu, kljub navajanju v
specifikacijah orodja. Izpostavljamo Signavio, ki se je odrezal najboljše. Prav tako smo
podali smernice za nadaljnjo delo oziroma predloge za širitev raziskave na ostala
področja.
V
INTEROPERABILITY OF BPMN BASED
BUSINESS PROCESS MODELING SOLUTIONS
Key words: interoperability, business process, bpmn, notation
UDK: 004.414.23(043.2)
Abstract
The master's thesis presents the result of the analysis that we conduced in the field of
BPMN 2.0 standard and tools that allow modeling within this standard. The Direction of
research is the area of interoperability. As part of the master's work, we reviewed
literature, relevant standards and file formats that are associated with BPMN. We used the
analytical method to perform an overview of the tools. We were interested in how well the
tools support the set of elements, that notation BPMN 2.0 covers. We also performed a
special form of experiment and prepared a practical example to verify the collected
findings. The findings on the effectiveness of information transfer were then documented.
We also give some guidelines for further work and proposals to expand the research to
other areas.
VI
VSEBINA
1 UVOD ........................................................................................................................... 1
1.1 OPREDELITEV PROBLEMA IN NAMEN DELA ..................................................................................................... 2
1.2 PREDSTAVITEV CILJEV MAGISTRSKEGA DELA ................................................................................................... 3
1.3 PREDPOSTAVKE IN OMEJITVE ...................................................................................................................... 3
1.4 PREDSTAVITEV RAZISKOVALNIH VPRAŠANJ MAGISTRSKEGA DELA ........................................................................ 4
1.5 PREDSTAVITEV OSNOVNE METODE DELA........................................................................................................ 6
2 PREGLED PODROČIJ MAGISTRSKEGA DELA ................................................ 7
2.1 MODELIRANJE PROCESOV .......................................................................................................................... 7
2.2 MEDOBRATOVALNOST MODELOV PROCESOV ............................................................................................... 10
2.3 BPMN ................................................................................................................................................ 10
2.3.1 Predstavitev in razvoj ............................................................................................................... 11
2.3.2 BPMN 2.0 elementi .................................................................................................................. 13
2.3.3 BPMN 2.0 meta model in shema ............................................................................................. 14
2.3.3.1 XSD osnove .................................................................................................................................... 15
2.3.4 Temelji BPMN sheme ............................................................................................................... 18
2.3.4.1 XSD datoteke ................................................................................................................................. 18
2.3.4.2 Semantični in grafični model ......................................................................................................... 19
2.3.4.3 ID in referenca na ID...................................................................................................................... 20
2.3.4.4 Uvoz, ciljni imenski prostor in oddaljene reference na ID ............................................................. 20
2.3.5 Razredi skladnosti BPMN 2.0 ................................................................................................... 22
2.3.5.1 Opisni pod-razred .......................................................................................................................... 23
2.3.5.2 Analitični pod-razred ..................................................................................................................... 25
2.3.5.3 Skupno izvedljivi pod-razred ......................................................................................................... 26
2.3.6 Grafični model BPMNDI ........................................................................................................... 29
2.3.6.1 Osnovne informacije ..................................................................................................................... 30
2.3.6.2 Nivoji procesa in strani .................................................................................................................. 31
2.3.6.3 BPMNDiagram ............................................................................................................................... 32
2.3.6.4 BPMNPlane ................................................................................................................................... 33
2.3.6.5 BPMNShape .................................................................................................................................. 33
2.3.6.6 BPMNEdge .................................................................................................................................... 34
2.4 DATOTEČNI FORMATI NA PODROČJU MEDOBRATOVALNOSTI MODELOV PROCESOV .............................................. 35
VII
2.4.1 XML .......................................................................................................................................... 36
2.4.2 BPMN ....................................................................................................................................... 37
2.4.3 XPDL ......................................................................................................................................... 38
2.4.4 VSD .......................................................................................................................................... 42
3 PREGLED OBSTOJEČIH RAZISKAV IZ PODROČJA
MEDOBRATOVALNOSTI MODELOV PROCESOV ................................................ 44
4 NAČRTOVANJE IN IZVEDBA EKSPERIMENTA ............................................ 49
4.1 PREDSTAVITEV IZBRANIH ORODIJ ............................................................................................................... 49
4.1.1 Signavio ................................................................................................................................... 50
4.1.2 Yaoqiang BPMN Editor ............................................................................................................ 52
4.1.3 Activiti (BPM Platform) ............................................................................................................ 53
4.2 ANALITIČNI PREGLED IZBRANIH ORODIJ IN NJIHOVA PODPRTOST ELEMENTOV ...................................................... 55
4.3 PREDSTAVITEV IZHODIŠČNIH MODELOV ....................................................................................................... 70
4.3.1 Model 1 .................................................................................................................................... 71
4.3.2 Model 2 .................................................................................................................................... 73
4.3.3 Model 3 .................................................................................................................................... 74
4.4 DEFINIRANJE POSTOPKA IZVEDBE ............................................................................................................... 75
4.5 OCENJEVALNI KRITERIJI ............................................................................................................................ 77
4.6 IZVEDBA EKSPERIMENTA OZIROMA PRIDOBIVANJE REZULTATOV ....................................................................... 79
4.6.1 M1 - Izhodišče Signavio in analiza vsebine datoteke ............................................................... 79
4.6.2 M1 - Uvoz v YBE in ugotovitve ................................................................................................. 86
4.6.3 M1 - Uvoz v Activiti in ugotovitve ............................................................................................ 92
4.6.4 M2 - Izhodišče YBE in analiza vsebine datoteke .................................................................... 100
4.6.5 M2 - Uvoz v Signavio in ugotovitve ........................................................................................ 102
4.6.6 M2 - Uvoz v Activiti in ugotovitve .......................................................................................... 106
4.6.7 M3 - Izhodišče Activiti in analiza vsebine datoteke ............................................................... 109
4.6.8 M3 - Uvoz v Signavio in ugotovitve ........................................................................................ 112
4.6.9 M3 - Uvoz v YBE in ugotovitve ............................................................................................... 116
5 ZAKLJUČEK .......................................................................................................... 121
5.1 ANALIZA PREDPOSTAVK IN OMEJITEV ........................................................................................................ 121
5.2 DOSEGANJE CILJEV IN PRIDOBITEV ODGOVOROV NA RAZISKOVALNA VPRAŠANJA ................................................ 122
5.3 PREDLOGI ZA NADALJNJO DELO ............................................................................................................... 126
5.4 SKLEP ................................................................................................................................................ 127
6 LITERATURA ........................................................................................................ 130
VIII
7 PRILOGE ................................................................................................................. 134
TABELE
TABELA 2.1: ELEMENTI IN ATRIBUTI OPISNEGA POD-RAZREDA ....................................................................................... 24
TABELA 2.2: ELEMENTI IN ATRIBUTI ANALITIČNEGA POD-RAZREDA ................................................................................. 25
TABELA 2.3: ELEMENTI IN ATRIBUTI SKUPNO IZVEDLJIVEGA POD-RAZREDA ....................................................................... 27
TABELA 2.4: ELEMENTI IN ATRIBUTI PODPORNIH RAZREDOV SKUPNO IZVEDLJIVEGA POD-RAZREDA ........................................ 28
TABELA 2.5: MICROSOFT VISIO - PREGLED FORMATOV ................................................................................................ 42
TABELA 4.1: REZULTATI ANALITIČNEGA PREGLEDA IZBRANIH ORODIJ ............................................................................... 56
TABELA 5.1: ANALIZA CILJEV MAGISTRSKEGA DELA .................................................................................................... 123
TABELA 5.2: ANALIZA RAZISKOVALNIH VPRAŠANJ MAGISTRSKEGA DELA ......................................................................... 124
TABELA 7.1: SEZNAM OSNOVNIH ELEMENTOV NAMENJENIH MODELIRANJU ................................................................... 134
TABELA 7.2: RAZŠIRJENI SEZNAM ELEMENTOV NAMENJENIH MODELIRANJU ................................................................... 138
SLIKE
SLIKA 2.1: BPMN SKOZI ČAS .................................................................................................................................. 12
SLIKA 2.2: PRIMER XPDL - DIAGRAM ....................................................................................................................... 39
SLIKA 4.1: GRAFIČNI VMESNIK ORODJA: SIGNAVIO ...................................................................................................... 51
SLIKA 4.2: GRAFIČNI VMESNIK ORODJA: YAOQIANG BPMN EDITOR ............................................................................... 53
SLIKA 4.3: GRAFIČNI VMESNIK - ACTIVITI MODELER .................................................................................................... 54
SLIKA 4.4: MODEL M1 ......................................................................................................................................... 72
SLIKA 4.5: MODEL M2 ......................................................................................................................................... 73
SLIKA 4.6: MODEL M3 ......................................................................................................................................... 74
SLIKA 4.7: PRIKAZ RELACIJ UPORABLJENIH MODELOV V IZBRANIH ORODIJ ......................................................................... 77
SLIKA 4.8: MODEL M1 V ORODJU YBE (M1 V YBE) ................................................................................................... 87
SLIKA 4.9: MODEL M1 V ORODJU ACTIVITI (M1 V ACTIVITI) ........................................................................................ 93
SLIKA 4.10: MODEL M2 V ORODJU SIGNAVIO (M2 V SIGNAVIO) ................................................................................ 103
SLIKA 4.11: MODEL M2 V ORODJU ACTIVITI (M2 V ACTIVITI) .................................................................................... 107
SLIKA 4.12: MODEL M3 V ORODJU SIGNAVIO (M3 V SIGNAVIO) ................................................................................ 113
SLIKA 4.13: MODEL M3 V ORODJU YBE (M3 V YBE) ............................................................................................... 118
IX
GRAFI
GRAF 4.1: PODPORA IZBRANIH ORODIJ ELEMENTOM DOLOČENE SKUPINE ........................................................................ 68
GRAF 4.2: PODPORA (ŠTEVILO ELEMENTOV) IZBRANIH ORODIJ GLEDE NA SKUPNO ŠTEVILO ELEMENTOV................................. 69
GRAF 4.3: PODPORA (DELEŽ GLEDE NA CELOTO) IZBRANIH ORODIJ GLEDE NA SKUPNO ŠTEVILO ELEMENTOV ........................... 70
GRAF 4.4: OCENJEVALNI KRITERIJI ZA M1 V YBE ........................................................................................................ 90
GRAF 4.5: OCENJEVALNI KRITERIJI ZA M1 V ACTIVITI .................................................................................................. 96
GRAF 4.6: USPEŠNOST PRENOSA M1 V YBE IN ACTIVITI ............................................................................................ 100
GRAF 4.7: OCENJEVALNI KRITERIJI ZA M2 V SIGNAVIO ............................................................................................... 105
GRAF 4.8: OCENJEVALNI KRITERIJI ZA M2 V ACTIVITI ................................................................................................ 108
GRAF 4.9: USPEŠNOST PRENOSA M2 V SIGNAVIO IN ACTIVITI ..................................................................................... 109
GRAF 4.10: OCENJEVALNI KRITERIJI ZA M3 V SIGNAVIO ............................................................................................ 115
GRAF 4.11: OCENJEVALNI KRITERIJI ZA M3 V YBE .................................................................................................... 119
GRAF 4.12: USPEŠNOST PRENOSA M3 V SIGNAVIO IN YBE ........................................................................................ 120
X
UPORABLJENE KRATICE
BPMN - Business process modelling notation
BPMI - Business process management initiative
XML - Exstensible markup language
BPML - Business process modelling language
BPEL - Business process execution language
OMG - Object management group
UML - Unified modelling language
XMI - XML metadata interchange
XSD - XML schema
WXS - W3C XML schema
BPMNDI - BPMN diagram interchange
URI - Uniform resource identifier
URL - Uniform resource locator
WSDL - Web service definition language
CP/M - Control program for microcomputers
DOS - Disk operating system
HTML - Hyper text markup language
GIF - Graphics interchange format
FAT - File allocation table
W3C - World wide web consortium
RSS - Rich site summary (tudi really simple syndication)
XI
SOAP - Simple object access protocol
XHTML - Extensible Hypertext markup language
XPDL - XML process definition language
WfMC - Workflow management coalition
BPM - Business process management
JRE - Java runtime environment
JDK - Java development kit
MIWG - Model interchange working group
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 1
1 UVOD
V sodobni informacijski družbi informacija predstavlja dobrino. Slednja je lahko ključnega
pomena za podjetja. Pri sprejemanju poslovnih odločitev v organizaciji imajo uporabniki in
zaposleni zahteve, da so informacije sintaktično in semantično pravilne. Primer:
oblikujemo lahko slovnično pravilen stavek, ki pa nima pomena. V tem primeru velja
sintaktična pravilnost, ne pa tudi semantična. Na področju notacije, ki je predstavljena v
nadaljevanju, bi lahko podali primer v katerem se element uspešno prenese v drugo orodje
(sintaktična pravilnost), vendar slednji ni pravilno lociran (semantična nepravilnost). Zato
je pomembno, da se strmi k sposobnosti izmenjave informacij in dostopnosti informacij, ne
da bi pri tem naleteli na tehnološke ovire. Na slednje smo se omejili v sklopu magistrskega
dela. Če pregledamo različne vire, ki govorijo o prilagajanju rešitev na področju
informatike, kaj hitro naletimo na pojme: "sodelovanje" (ang. cooperation, collaboration),
"združljivost" (ang. compatibility), "prenosljivost" (ang. portability), "medobratovalnost"
(ang. interoperability) itd. Vsi omenjeni pojmi imajo nekako skupen cilj oziroma skupno
točko. Ta se nanaša na povezovanje različnih komponent, objektov ali celo aplikacij.
Omenjali bomo predvsem pojma združljivost in medobratovalnost. Z združljivostjo
ciljamo predvsem na združljivost različnih datotečnih formatov. Dva datotečna formata sta
povsem kompatibilna, kadar lahko izvedemo prenos podatkov iz enega formata v drugega.
Seveda pri tem ne sme priti do izgub informacij, oziroma se le te ne smejo spremeniti [1],
[2]. Na omenjenem področju zasledimo tudi izraza "forward compatibility" in "backward
compatibility". Slednja navajata lastnost, katera opisuje združljivost, na primer aplikacije s
starejšimi oziroma novejšimi različicami [3], [4]. Nas pa predvsem zanima področje
medobratovalnosti. Pojem se nanaša predvsem na zmožnost dveh ali več sistemov (ali
komponent), da si izmenjajo informacije in jih pri nadaljnjem delu tudi uporabijo [5].
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 2
1.1 Opredelitev problema in namen dela
Pojem medobratovalnosti se dandanes vse pogosteje pojavlja. Povezljivost orodij med
seboj nas zanima predvsem na področju poslovnih procesov (ang. business process).
Natančneje procesi oziroma modeli, ki temeljijo na BPMN (ang. business process
modelling notation). BPMN predstavlja standard, nad katerim je mogoče izvesti XML
serializacijo (ang. extensible markup language serialization), katera omogoča ustvarjanje
procesa in preoblikovanje le tega v obliko, ki je primerna nadaljnji obdelavi v različnih
orodjih. Na podlagi te trditve bi lahko v orodju "A" ustvarili diagram, ga izvozili in kasneje
uvozili v orodje "B", ki podpira standard BPMN. V praksi se običajno to ne izkaže za
resnično. Pri omenjenem postopku po navadi naletimo na težave. Z raziskavo želimo
potrditi ali zavreči prejšnjo trditev in spoznati kaj otežuje postopek izvoza in uvoza modela
procesa, ter kje prihaja do odstopanj. Prav tako pa preučiti zgradbe različnih formatov, jih
primerjati in podati ugotovitve.
V nadaljevanju bomo večkrat omenili izraz model. S poimenovanjem ciljamo na diagrame,
poslovne procese in modele procesov, ki jih bomo uporabili tudi v sklopu izvedbe
eksperimenta. Slednji so ustvarjeni zgolj za preverjanje uspešnosti prenosa. Ali so oziroma
bodo primerni tudi za izvajanje, nas v tej fazi ne zanima.
Namen raziskave je
spoznati standarde, ki obstajajo na področju modeliranja poslovnih procesov,
pregled in analiza posameznih datotečnih formatov.
Ugotoviti kaj vpliva na neuspešen uvoz informacij in zakaj včasih pride do napačno
prikazanega diagrama ob uvozu. Kje pride do najpogostejših napak in odstopanj – ali na
strani orodja, ki poskrbi za izvoz podatkov ali na strani orodja, ki izvede uvoz. Glede na to,
da je BPMN 2.0 postal standardiziran, pri tem postopku ne bi smelo biti težav, pa vendar
temu ni tako. Ker se tukaj pojavi problem, ga želimo rešiti oziroma se podrobneje seznaniti
z njim in ugotoviti zakaj pride do takšnega stanja in kateri faktorji vplivajo na prehod v to
stanje.
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 3
1.2 Predstavitev ciljev magistrskega dela
Cilj je ugotoviti kateri od izbranih faktorjev vplivajo na medobratovalnost diagrama
načrtovanega na podlagi standarda BPMN. Poskusili bomo ugotoviti kaj vpliva na
uspešnost prenosa informacij. Na podlagi dobljenih rezultatov bomo bili tudi sposobni
opredeliti, kje je tista najprimernejša meja, ko lahko trdimo, da je diagram še bil uspešno
prenesen v orodje.
1. Preučitev teorije, ki je relevantna za področje medobratovalnosti.
2. Preučitev dobrih praks medobratovalnosti (iz sorodnega področja).
3. Identifikacija formatov za zapis modelov BPMN.
4. Identifikacija preslikav med formati za zapis modelov BPMN.
5. Identifikacija faktorjev, ki vplivajo na medobratovalnost poslovnega procesa
načrtovanega na podlagi standarda BPMN.
6. Opredelitev modela za merjenje stanja medobratovalnosti modelov BPMN.
1.3 Predpostavke in omejitve
Pri samem delu bomo morali sprejeti omejitve na področju:
Standarda oziroma notacije - osredotočeni smo v različico BPMN 2.0.
Orodij - identifikacijo in preučitev vseh orodij, ki so namenjena modeliranju
poslovnih procesov, bi bilo iz časovnega vidika praktično nemogoče izvesti. Zaradi
te omejitve bomo najprej opravili pregled najbolj razširjenih in uporabljenih orodij.
V tej fazi bomo tako pridobili oziroma izbrali orodja, ki so uporabna in hkrati nam
dosegljiva.
Modelov (diagramov) - orodja omogočajo ustvarjanje različnih modelov
(diagramov). Slednji se razlikujejo glede na pomen, nabor elementov,
kompleksnost itd. Ker je nemogoče preveriti vse možnosti, se bomo omejili na
minimalno število modelov (diagramov), ki nam bodo omogočili izvedbo
eksperimenta oziroma podajanje ugotovitev.
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 4
Uspešnost prenosa informacij - v magistrskem delu bomo prikazali lestvico
(ocenjevalni kriteriji), preko katere bomo lahko ocenjevali uspešnost prenosa
informacij. Pri tem bomo morali upoštevati različne postavke (npr. število
elementov, število povezav, lega elementa itd.).
Predpostavke:
Kompleksnost poslovnega procesa negativno vpliva na uspešnost uvoza poslovnega
procesa.
Struktura/zgradba datoteke (ki nastane ob izvozu poslovnega procesa) nima vpliva
na uspešnost prenosa informacij.
1.4 Predstavitev raziskovalnih vprašanj magistrskega dela
RV1: Kateri standardi za medobratovalnost modelov obstajajo?
Odgovor na raziskovalno vprašanje bomo pridobili na podlagi analize literature s
področja medobratovalnosti poslovnih modelov. Omejitve, ki jih bomo morali
sprejeti, so predvsem te, da se osredotočimo na tiste standarde in datotečne formate,
ki so najbolj razširjeni oziroma so najpogosteje v uporabi.
RV2: Kakšno podprtost nudijo orodja pri izvozu in uvozu modela
(diagrama)?
Zaradi obstoja številnih orodij, se bo potrebno omejiti na samo določene. Nabor
slednjih bomo dobili na podlagi selekcije orodij, namenjenih modeliranju
poslovnega procesa, ki jih najpogosteje zasledimo oziroma so najpogosteje
uporabljene. Nad izbranimi orodji bomo izvedli analizo opisnih podatkov
posameznega orodja. Izvedeli bomo kakšne datotečne formate posamezno orodje
podpira za uvoz in izvoz modela. Na podlagi pridobljenih podatkov, bomo tudi
lahko videli kateri formati se pojavljajo najpogosteje.
RV3: Kateri dejavniki vplivajo na uspešen uvoz datoteke formata BPMN, v
orodja, ki podpirajo omenjeni standard?
Da bomo lahko odgovorili na navedeno raziskovalno vprašanje, bomo morali
izvesti posebno obliko eksperimenta. Na podlagi strukture datotečnih formatov, ki
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 5
bodo nastali ob posameznem izvozu modela, bomo lahko videli kje pride do
odstopanj, kateri podatki se najpogosteje nahajajo v strukturi formata in kateri se
najpogosteje izpustijo. Videli bomo kako vplivajo shranjene informacije na
uspešnost uvoza modela nazaj v orodje. Pri izvajanju eksperimenta se bomo omejili
na izbrana orodja. Slednja bodo enaka, ki jih bomo uporabili pri RV2.
RV4: Ali in kako lahko izmerimo stopnjo medobratovalnosti?
S pregledom literature iz raziskovalnega področja bomo prišli do odgovora ali že
obstajajo lestvice za merjenje medobratovalnosti. V kolikor obstajajo jih bomo
analizirali, ter jih primerjali in ugotovili ali jih je moč uporabiti z našimi izbranimi
orodji in testnimi modeli. V nasprotnem primeru bomo poskušali na podlagi
preučitve literature posameznega orodja, rangirati povezljivost orodja z drugimi
orodji z ustvarjanjem lastne merilne lestvice oziroma ocenjevalnih kriterijev.
RV5: Ali različna kompleksnost diagrama, modeliranega na standardu
BPMN, vpliva na uspešnost uvoza le tega v različna orodja, ki podpirajo
standard BPMN?
Pri izvedbi eksperimenta bomo uporabili različne poslovne procese. Uporabili
bomo nabor poslovnih procesov, ki se bodo razlikovali glede na vrsto elementov,
število elementov, dolžino samega poslovnega procesa itd. S tem bomo dobili
razpon od najenostavnejšega poslovnega procesa do tistega, ki je že bolj
kompleksen in obsežen. Ker je nemogoče ustvariti oziroma testirati vse možne
poslovne procese, se bomo omejili na manjši nabor le teh. Nabor slednjih bo v
takšni meri, da bomo lahko izvedli in upoštevali prej navedene trditve.
RV6: Kateri elementi, modeli se najbolje, najslabše povezujejo?
Izveden eksperiment nam bo podal odgovor na zastavljeno vprašanje. Na podlagi
opazovanja pridobljenih rezultatov, bomo lahko zabeležili kateri elementi so se
najbolje prenesli iz enega orodja v drugega. Pri tem bomo upoštevali prenos
opisnih podatkov, pozicije elementa itd.
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 6
1.5 Predstavitev osnovne metode dela
Raziskovanje bomo opravljali nad določenimi rešitvami, ki so namenjena modeliranju
poslovnih procesov. Na podlagi tega bo naša metoda raziskovanja posebna oblika
eksperimenta.
Pripravili si bomo različne diagrame oziroma modele, ki jih bomo potem poskušali uvoziti
in izvoziti v različna orodja. Spremljali bomo natančnost prenesenih podatkov v
posamezna orodja.
Pred tem pa bomo opravili pregled literature na področju BPMN in medobratovalnosti.
Prav tako bomo do določenih ugotovitev prišli, na podlagi analitičnega pregleda
posameznega orodja, na področju podpore elementov.
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 7
2 PREGLED PODROČIJ MAGISTRSKEGA DELA
V poglavju, ki sledi, smo opravili pregled glavnih področij s katerimi smo se srečali v času
opravljanja in sestavljanja magistrskega dela. Povzeti oziroma opisani so najpomembnejši
segmenti področij, kot je opis področja in najpogostejših pojmov, ki jih srečamo v
omenjenem področju, pregled in razvoj, ter nekatere druge lastnosti in povezave na katere
se sklicujemo in raziskujemo v magistrskem delu.
Vsebina v poglavju zajema splošne informacije in predstavitve, ki so namenjene predvsem
tistim, ki jim področja zajeta v magistrskem delu niso tako domača. Slednjim želimo
področje približati tako, da ga bodo lahko razumeli in dobili predstavo, hkrati pa želimo
doseči morebitno povečanje zanimanja za omenjena področja. Poglavje pa ne opredeljuje
samo osnovnih in površinskih informacij. Zajeta je tudi vsebina, ki je še konkretneje
pomembna za našo delo.
2.1 Modeliranje procesov
Pogostokrat zasledimo pojme modeliranje in simulacija. Velika podjetja temu namenijo še
večjo pozornost, saj običajno upravljajo z velikimi finančnimi vložki in stroški. Pomembno
je, da imajo nadzor nad procesi, ki tečejo pod njihovim okriljem. Proces je skupek opravil
(delovnih nalog, aktivnosti) z določenim vrstnim redom izvajanja, ki pretvarjajo vhode v
izhode (materiale, informacije) [6].
Ločimo [7]:
Upravljavske procese - nadzirajo in upravljajo izvajanje procesa.
Operativne procese - so glavni oziroma osrednji procesi, saj predstavljajo posel s
katerim se podjetje ukvarja (na primer: prodaja, nabava, proizvodnja itd).
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 8
Podporni proces - omenjeni sklop procesov podpira operativne procese pri
njihovem izvajanju. V tem sklopu najdem procese s področja računovodstva,
kadrovske službe, tehnične podpore, IT-ja itd.
Poslovni proces opredeljujemo kot skupek logično povezanih izvajalskih in nadzornih
postopkov in aktivnosti, katerih izid je načrtovani izdelek ali storitev. Modeliranje
procesov je tako beleženje poslovnih aktivnosti in poslovnih informacij, v takšnem
vrstnem redu, kot si pri izvajanju tudi sledijo. Diagram, ki pri tem nastane, predstavlja
orodje s katerim lahko predvidimo končno stanje, ko se proces zaključi. Namen je doseči
izboljšano stanje na izhodu. Da pa se lahko to doseže, je pri načrtovanju potrebno
pozornost usmeriti na izboljšave tistih akcij, ki lahko pripomorejo k boljši izvedbi storitve
in boljši uporabniški izkušnji. Na drugi strani pa je potrebno zmanjševati tiste akcije, ki so
časovno preobsežne ali pa pri izvedbi zahtevajo visoke stroške. V našem primeru
modeliramo predvsem zato, da dobimo sliko kako so procesi sestavljeni.
Prednosti, ki jih prinaša modeliranje (poslovnih) procesov so [8]:
1. Boljše razumevanje odgovornosti udeležencev (dobimo predstavo katera oseba je
zadolžena za določena opravila - dejansko vidimo kaj kdo počne).
2. Boljše razumevanje razporeditve virov (zakaj so bili viri posredovani k določenem
opravilu - ali se viri uporabljajo oziroma kdo jih uporablja).
3. Razumevanje odnosov in pregled nad interakcijo (kdo s kom komunicira).
4. Pregled kako informacije potujejo (kje se informacija proži - izvorno mesto in
njena pot do ciljnega mesta; kako poteka izmenjava dokumentov).
5. Identifikacija ti. "ozkih grl" (kje pride do zastojev, zamud).
6. Pregled nad celotnim procesom lahko prinese ugotovitev in potrebo po prenovi
procesa ter njegovi optimizaciji.
7. Izboljšavo informacijskega sistema (povečanje avtomatizacije procesa).
Proces predstavimo in modeliramo na različne načine. Notacije (tudi jeziki za modeliranje)
za ustvarjanje le tega pa so razvrščene v naslednje skupine:
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 9
Grafične/tekstovne notacije, kjer imamo "sliko" procesa ali prosti opis (uporabimo
lahko tudi kombinacijo obeh).
Formalne/neformalne notacije, kjer ima modeliran proces matematično ozadje ali
pa je zasnovan na podlagi stroge notacije, med tem ko imamo na drugi strani
ohlapno modeliran proces.
Izvršljive/neizvršljive notacije, ki so predvsem primerne za informatizacijo
oziroma dokumentiranje.
Izvršljive notacije so takšne, ki nam bodo omogočale izvedbo modeliranega procesa.
Govorimo o simulaciji (ang. simulation). Zakaj se ljudje in strokovnjaki ukvarjajo z
modeliranjem in simuliranjem procesov so različni. Najpogosteje ker želimo dobiti pogled
na celotno sliko (postopek), uvesti izboljšave in opazovati spremembe, preučevati modele
itd. Velikokrat pa so omenjeni postopki bistveno cenejši, kot če bi delo opravljali
neposredno [9]. Nas zanima predvsem grafično modeliranje in grafična predstavitev
procesov. Izvajanju le teh ne bomo namenili (prevelike) pozornosti.
Omenimo še dva izraza, ki jih pogosto zasledimo pri modeliranju procesov. Pri
modeliranju v splošnem poznamo dva različna tipa modelov poslovnih procesov [10]:
"AS-IS" ali osnovni model in
"TO-BE" model.
Bistvena razlika med omenjenima modeloma je ta, da prvi ("AS-IS") model služi za prikaz
obstoječega stanja. Nastali model bo imel proces (oziroma skupek procesov), ki bo
vseboval akcije, ki se trenutno izvajajo. Medtem, ko se pri modeliranju modela tipa "TO-
BE" načrtuje novo stanje procesa. Oba tipa modelov poslovnih procesov sta izrednega
pomena. Uporabljata se pri analiziranju, testiranju, implementiranju in kreiranju izboljšav
procesov. Cilj modeliranja je prikazati celoten proces in vključiti vse akcije in udeležence
procesa. Celotna slika je ključnega pomena, saj podjetje dobi vpogled kje so potrebne
spremembe. Spremembe, to so izboljšave, pa prinašajo zadovoljno stranko (tudi kupec,
naročnik) in reducirane stroške podjetja. Slednje pa vpliva na povečanje dobička, prednost
pred konkurenco, poznavanje tržišča, zadovoljstvo na strani zaposlenih itd.
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 10
2.2 Medobratovalnost modelov procesov
Medobratovalnost (ang. interoperability) opredeljujemo kot sposobnost dveh ali več
sistemov oziroma komponent, da med seboj izmenjujejo in uporabljajo podatke,
informacije in znanja [11]. Gre za zmožnost medsebojnega obratovanja različne opreme
oziroma različnih sistemov. Sodobne rešitve za podjetja in fizične osebe postajajo vse bolj
kompleksne in večje. To pa je privedlo do vse večje potrebe po povezljivosti omenjenih
rešitev [12]. V mislih imamo predvsem povezovanje različnih podatkovnih virov in
poslovnih procesov. Slednji se pogostokrat nahajajo v različnih institucijah. Z
medobratovalnostjo poskušamo pokriti področje združljivosti sistemov. Da pa bi lahko to
storili, moramo najprej razviti, definirati in uporabiti centralno medobratovalnost platform
in skupnih gradnikov.
V našem primeru bomo o medobratovalnosti govorili takrat, kadar bomo želeli ustvarjen
proces iz enega orodja prenesti v drugo. Izbrani orodji, med katerima bomo izvedli prenos
modela procesa, morata seveda imeti podporo za enak datotečni format. Le tako lahko
izvedemo prenos, brez da bilo pri tem potrebno izvesti preoblikovanje datoteke z namenom
spreminjanja datotečnega formata. Pri tem postopku bi namreč lahko (še dodatno) kakšno
informacijo izgubili ali pa jo preoblikovali.
BPMN predstavlja standardizirano notacijo [13]. To pomeni, da pri izvozu/uvozu modela
procesa v različna orodja nebi smelo priti do težav, saj je skupni jezik orodij definiran. V
nadaljevanju pri izvedbi eksperimenta lahko preberete ugotovitve in rezultate.
2.3 BPMN
V nadaljevanju je predstavljeno področje, ki predstavlja osrednjo domeno v kateri
raziskujemo in operiramo. Ker je področje obsežno in je možno predstaviti številne dele in
podrobnosti, bomo v tem poglavju predstavili informacije za katere menimo, da so nam
bile v veliko pomoč. Vsebina je oblikovana tako, da je namenjena širšemu krogu bralcev.
Področje smo želeli približati tistim, ki jim BPMN ni tako poznan, kot tudi ostalim, ki o
tem področju že nekaj vedo. V nadaljevanju boste tako izvedeli nekaj osnovnih informacij,
kaj sploh BPMN predstavlja, kako se je razvil. Pa vse do informacij katere grafične
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 11
elemente BPMN zajema, kako so ti serializirani oziroma predstavljeni v datoteki. Slednje
so še posebej pomembne, saj predstavljajo podatke, ki so zanimivi za naš eksperiment
predstavljen kasneje. Informacije so dobro opredeljene in napisane že v samih
specifikacijah BPMN 2.0 [14]. V veliko pomoč za oblikovanje vsebine v nadaljevanju,
nam je bila tudi knjiga Bruca Silverja - BPMN Method and Style [15].
Predstavljeno vsebino smo poskušali strniti na čim manjši obseg, zato določena področja
niso predstavljena in opisana v podrobnosti.
2.3.1 Predstavitev in razvoj
BPMN je kratica, ki (izvorno) predstavlja pojem Business Process Modeling Notation -
notacija, ki omogoča modeliranje poslovnih procesov.
Če poskušamo preprosto definirati, BPMN je grafični zapis, ki prikazuje korake v
poslovnem procesu. Velikokrat je govora, da gre za metodologijo, ogrodje ali proces, kar
ni pravilno. Z zapisom prikažemo delovni tok poslovnega procesa od začetka izvajanja, do
konca izvajanja. Notacija je bila specifično zasnovana za pregled koordinacije posameznih
sekvenc v procesu in izmenjavi sporočil med različnimi udeleženci procesa, ki jim je nabor
aktivnosti skupen.
BPMN vsebuje številne izraze in poimenovanja, ki so definirana v angleškem jeziku.
Določene bomo skozi razlago poskušali nadomesti s slovenskimi izrazi. Ker pa vemo, da
se vseh izrazov ne da primerno prevesti, bomo slednje pustili navedene v originalnem
jeziku - torej angleščini. V tem primeru bomo poskušali natančneje razložiti pomen
oziroma namen.
Začetki razvoja notacije segajo več kot desetletje nazaj. Leta 2000 so se različni
strokovnjaki v takrat vodilnih podjetjih, ko so SAP, Oracle in IDS Scheer, odločili
ustanoviti neodvisno, neprofitno organizacijo BPMI (ang. business process modelling
initiative). Leta 2001 je omenjena ekipa, ki je bila ustvarjena za področje notacije,
vključevala strokovnjake že iz 35-ih podjetij. Organizacija se je zavzemala za možnost
razvoja in vodenja poslovnih procesov, ki bi segali preko meja posamezne organizacije. V
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 12
ta namen se je pričelo razvijanje standardov za področje modeliranja procesov, njihovo
vgradnjo, izvajanje, vzdrževanje in optimizacijo. Ti standardi temeljijo na XML in
sorodnih tehnologijah. Prvič se pojavi kratica BPML (ang. business process modelling
language). Predlagali so grafični jezik za načrtovanje poslovnih procesov, ki bo vključeval
izvršilno semantiko. Kasneje so slednjega zamenjali saj ga večja podjetja, kot je na primer
Microsoft, niso vključila v svoje rešitve in produkte. Zahteve za uvedbo so bile prevelike,
ob enem pa je bila sama implementacija zelo zahtevna. Jezik BPML zamenjata dva nova
jezika - BPEL (ali BPEL4WS) in BPMN. BPEL (ang. business process execution
language) predstavlja standardni izvršilni jezik, s katerim definiramo akcije poslovnega
procesa z spletnimi storitvami. Omogoča integracijo spletnih storitev v poslovne procese.
BPMN pa je kot smo že omenili namenjen grafični notaciji. Potem, ko je BPMI objavil
prvo različico jezika BPMN 1.0 v maju 2004, je že prihodnje leto sledil razpad samostojne
organizacije. V letu 2005 se BPMI pridruži in postane del mednarodnega, ne profitnega
računalniško-industrijskega konzorcija, ki skrbi za standarde, OMG (ang. object
management group). V nadaljnjih nekaj letih je sledilo še nekaj različic in posodobitev
standarda BPMN. Zadnja prelomna verzija standarda, ki je bila objavljena ima oznako
BPMN 2.0 in je izšla marca 2011. Pri slednji so dali poudarek izmenjavi modelov. Sledilo
je obdobje, ki ni bilo odmevno in ni postreglo z novimi verzijami. Trenutno je na voljo
zadnja različica z oznako BPMN 2.0.2. Opisan pregled pa prikazuje tudi Slika 2.1[16].
Slika 2.1: BPMN skozi čas
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 13
2.3.2 BPMN 2.0 elementi
BPMN vsebuje nabor elementov (v nadaljevanju tudi gradniki), ki predstavljajo grafično
notacijo standarda. Glavni akterji razvoja in definiranja standarda, tudi skozi specifikacije,
izpostavljajo določene dejavnike in smernice katerih so se poskušali držati pri razvoju. Pri
razvoju notacije so strmeli k ustvarjanju preprostega in razumljivega mehanizma, s katerim
bi lahko ustvarjali modele poslovnih procesov. Ustvarili so nabor s katerim lahko
obvladujemo razpon - preproste procese na eni strani, kot tudi tiste, ki vsebujejo
kompleksne dele, na drugi. Za izpolnitev zahtev, ki jih ta razpon prinaša, so grafične
elemente razdelili v specifične kategorije [17]. Oblikovali so manjši nabor kategorij, ki
bodo bralcu diagrama BPMN olajšali razumevanje. Ker omenjene kategorije predstavljajo
osnovne tipe elementov, si jih bo bralec hitro zapomnil. Definiranje ključnih oziroma
osnovnih kategorij, omogoča tudi lažje uvajanje sprememb. Na ta način se lažje dopolni
nabor elementov v posamezni kategoriji, če bi potreba po kompleksnosti modelov le to
zahtevala. V nadaljevanju je navedenih pet osnovnih kategorij (ang. basic categories), ki
jih specifikacije BPMN 2.0 navajajo [14]:
1. Objekti pretoka (ang. flow objects).
2. Podatki (ang. data).
3. Povezovalni objekti (ang. connecting objects).
4. Steze (ang. swimlanes).
5. Predmeti (ang. artifacts).
Objekti pretoka predstavljajo kategorijo oziroma skupino v kateri so glavni grafični
elementi. Slednji definirajo obnašanje poslovnega procesa. Elementi, ki se nahajajo v
omenjeni kategoriji so: dogodki (ang. events), aktivnosti (ang. activities) (v slednjo spadajo
opravila (ang. tasks) in pod-procesi (ang. sub-processes)) in prehodi (ang. gateways).
Podatki so predstavljeni s štirimi elementi: podatkovni objekti (ang. data objects), vhodni
podatki (ang. data inputs), izhodni podatki (ang. data outputs) in podatkovne shrambe (ang.
data stores).
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 14
Povezovalni objekti ali povezave vsebujejo elemente, ki skrbijo za povezanost objektov
pretoka. Na voljo so naslednji elementi: tok zaporedja ali sekvenčni tok (ang. sequence
flow), tok sporočila (ang. message flow), tok asociacije (ang. associations) in podatkovne
asociacije (ang. data associations).
Steze se uporabljajo za grupiranje oziroma združevanje aktivnosti uporabnika, vlog ali
sistemov. Vključujejo elementa: bazen (ang. pool) in steza (ang. lane).
Predmeti so podporni elementi, ki dodajo informacije diagramu. Specifikacije
opredeljujejo dva predmeta, vendar jih lahko orodja in načrtovalci modelov dodajo
poljubno število. V prihodnosti bi lahko dodali še dodatne elemente, ki so pogosto
uporabljeni. Trenutno pa sta v kategorijo vključena: skupina (ang. groups) in beležka
oziroma opomba (ang. annotations).
Ustvarjeni sta bili dve tabeli, s katerimi smo predstavili in razložili osnovne elemente, kot
tudi nekatere dodatne, ki jih najpogosteje zasledimo v modelih oziroma diagramih [14].
Namenjeni sta predvsem tistim bralcem, ki jim notacija ni povsem poznana. Zaradi
obsežnosti in ne neposrednega nanašanja na našo raziskavo, smo slednje prestavili v
prilogo A.
2.3.3 BPMN 2.0 meta model in shema
V poglavju 2.3.1 Predstavitev in razvoj smo dejali, da kratici BPMN najpogosteje
pripišemo pomen Business Process Modeling Notation. Smiselno, saj je to tudi
predstavljala v verziji BPMN 1.2. Z razvojem in nadaljnjim definiranjem pa je prišlo do
spremembe akronima. OMG je v različici BPMN 2.0 pomen spremenil v Business Process
Model and Notation. Večina dela, ki so ga izvedli za pripravo specifikacij BPMN 2.0, pa ni
prinesla sprememb na področju notacije. Notacija, simboli in oblike elementov so v veliki
meri ostali nespremenjeni glede na različico BPMN 1.2. Posvetili so se predvsem
definiranju meta modela za BPMN. Slednji predstavlja formalne specifikacije semantičnih
elementov, ki obsegajo BPMN model, ter relacije med njimi. Veljaven BPMN model mora
ustrezati specifikacijam meta modela [13].
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 15
Elementi meta modela so definirani kot razredi objektov (ang. object classes), ki imajo
definirane atribute (ang. attributes). Slednji so lahko obvezni (ang. required) ali opcijski
(ang. optional). Nekateri od razredov lahko predstavljajo pod-razred drugega razreda. V
tem primeru pod-razred vsebuje podedovane atribute nad-razreda, doda pa lahko tudi svoje
lastne. Element modela je tako lahko podtip več kot enega razreda, pri tem pa bo dedoval
atribute vseh. Nekateri razredi kot sta "Root Element" ali "Base Element" so abstraktni in
se ne uporabljajo neposredno v BPMN modelih. Njihov namen je zgolj zagotoviti skupno
točko, v kateri so definirani atributi, ki so porazdeljeni v pod-razredih.
V dokumentu specifikacij BPMN 2.0 je meta model predstavljen z razrednim diagramom
UML (ang. UML class diagram). Razredi so organizirani v množice, ki jih imenujemo
paketi (ang. packages). Paketi vsebujejo plasti (ang. layers), ki jih je mogoče razširiti. Meta
model je na voljo v dveh alternativnih XML formatih. Prvi format prihaja s strani OMG in
je poimenovan XMI. Kratica predstavlja okrajšavo za XML Metadata Interchange, kar
pomeni, da gre za format v XML obliki, ki je namenjen izmenjavi meta podatkov. Drugo
alternativo ponuja W3C s formatom XSD. Slednji predstavlja okrajšavo za XML Schema
Definition. Format omogoča definiranje sheme v formatu XML. Obe različici sta precej
enaki pri predstavitvi BPMN modela, vendar je več pomanjkljivosti zaslediti pri formatu
XSD, saj ne prikaže določenih povezav oziroma relacij (npr. večkratno dedovanje). XSD
predstavlja jezik, ki je najbližje "normalnemu" XML-ju. Na podlagi tega je bolj razširjen in
večkrat uporabljen na različnih področjih (splet, storitveno usmerjene arhitekture,
aplikacije itd.). Zaradi tega ga boste tudi v številnih BPMN orodjih zasledili, kot format za
izmenjavo modelov.
2.3.3.1 XSD osnove
Omenili smo že, da je XSD kratica, ki pomeni definiranje sheme XML (ang. XML Schema
Definition). Predstavitev jezika bi bila preobsežna, zato bomo zajeli le del. Izpostavili
bomo osnove in del, ki se dotika našega področja - tj. XSD in BPMN. Na ta način bodo
predstavo in nekatere informacije dobili tudi tisti, ki jim jezik ni poznan.
Začetki segajo že v leto 2001, ko W3C predstavi omenjen jezik. Predstavlja prvi ločen
jezik namenjen shemam za jezik XML, ki je bil definiran na podlagi priporočil in smernic.
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 16
Mnogim je poznan tudi pod oznako WXS (ang. W3C XML Schema). Sama po sebi XML
shema predstavlja XML dokument. Slednji je namenjen definiranju elementov, atributov,
strukture.. - pravil, ki jih XML dokument mora izpolnjevati, da je obravnavan kot pravilen
(ang. valid) glede na shemo. XSD tako definira imena elementov, podatkovne tipe, njihove
atribute in podrejene elemente (ang. child elements) [18]. V kolikor BPMN 2.0 model ni
skladen s shemo, ne velja za pravilnega. Mnogi XML urejevalniki že ponujajo preverjanje
ustreznosti procesa modela glede na BPMN shemo. To storijo s pomočjo procesorja shem
(ang. schema processor).
Koda 2.1: Vsebina datoteke BPMN20.xsd
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema elementFormDefault="qualified" attributeFormDefault="unqualified"
xmlns="http://www.omg.org/spec/BPMN/20100524/MODEL"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:bpmndi="http://www.omg.org/spec/BPMN/20100524/DI"
targetNamespace="http://www.omg.org/spec/BPMN/20100524/MODEL">
<xsd:import namespace="http://www.omg.org/spec/BPMN/20100524/DI"
schemaLocation="BPMNDI.xsd"/>
<xsd:include schemaLocation="Semantic.xsd"/>
<xsd:element name="definitions" type="tDefinitions"/>
<xsd:complexType name="tDefinitions">
<xsd:sequence>
<xsd:element ref="import" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="extension" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="rootElement" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="bpmndi:BPMNDiagram" minOccurs="0"
maxOccurs="unbounded"/>
<xsd:element ref="relationship" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="id" type="xsd:ID" use="optional"/>
<xsd:attribute name="name" type="xsd:string"/>
<xsd:attribute name="targetNamespace" type="xsd:anyURI" use="required"/>
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 17
<xsd:attribute name="expressionLanguage" type="xsd:anyURI" use="optional"
default="http://www.w3.org/1999/XPath"/>
<xsd:attribute name="typeLanguage" type="xsd:anyURI" use="optional"
default="http://www.w3.org/2001/XMLSchema"/>
<xsd:attribute name="exporter" type="xsd:string"/>
<xsd:attribute name="exporterVersion" type="xsd:string"/>
<xsd:anyAttribute namespace="##other" processContents="lax"/>
</xsd:complexType>
<xsd:element name="import" type="tImport"/>
<xsd:complexType name="tImport">
<xsd:attribute name="namespace" type="xsd:anyURI" use="required"/>
<xsd:attribute name="location" type="xsd:string" use="required"/>
<xsd:attribute name="importType" type="xsd:anyURI" use="required"/>
</xsd:complexType>
</xsd:schema>
Če pogledamo vsebino XSD datoteke [19] (Koda 2.1) lahko opazimo, da so značke
zgrajene iz dveh delov. Prvi del poimenujmo predpona (ang. prefix), drugega lokalno ime
(ang. local name) ali lokalni del (ang. local part). Omenjena dela ločuje znak dvopičje.
Predpona je okrajšava za imenski prostor (ang. namespace), ki je običajno opredeljen z
URL-jem. Vsi imenski prostori, ki se uporabljajo v shemi, so običajno navedeni z uporabo
xmlns atributa, ki se nahaja znotraj korenskega xsd:schema elementa (ang. root element).
Primer: Predpona xsd predstavlja imenski prostor http://w3.org/2001/XMLSchema, kar je v
bistvu imenski prostor XSD jezika. Poimenovanje predpone je lahko različno. Pomembna
je URL deklaracija imenskega prostora, s katerim se bo predpona ujemala. Atribut
targetNamespace, ki se prav tako nahaja v korenskem xsd:schema elementu, služi
identifikaciji imenskega prostora konkretne sheme, katere vsebino beremo. Primer:
imenski prostor http://www.omg.org/spec/BPMN20100524/MODEL označuje imenski
prostor BPMN 2.0. Vsi BPMN 2.0 modeli se morajo sklicevati na omenjen prostor.
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 18
Elemente lahko definiramo v različnih shemah, ki jih po potrebi povezujemo med seboj.
Na primer elementa category in collaboration sta definirana v drugi XSD datoteki. Ker pa
je le ta vključena v shemo BPMN20.xsd, ustvarimo dostopnost in povezavo. Povezavo
ustvarimo tako, da shemo/e vključimo (ang. include) ali uvozimo (ang. import) v shemo.
Shema BPMN20.xsd vključuje Semantic.xsd in uvaža BPMNDI.xsd. Razlika med
vključevanjem in uvažanjem shem je ta, da vključitvena XSD datoteka uporablja enak
ciljni imenski prostor (ang. targetNamespace) kot BPMN20.xsd. Pri uvozu pa je ta lahko
drugačen. V našem primeru je http://www.omg.org/spec/BPMN20100524/DI. Če
uporabljamo tekstovni prikaz vsebine datoteke, takšnih elementov ne bomo videli. Orodja,
ki omogočajo grafični prikaz, pa običajno poskrbijo za prikaz vključenih in uvoženih
elementov.
Element xsd:sequence vsebuje seznam podrejenih elementov, ki definirajo zaporedje
elementov v dotičnem dokumentu. Atribut minOccurs definira ali je element zahtevan ali
ne. Z atributom maxOccurs pa definiramo ali se element lahko ponovi. V kolikor vsebina v
XML dokumentu, ne bo pravilno upoštevala tovrstnih določil (npr. manjkal element, ki je
definiran kot zahtevan), bo prišlo do kršitev pravil sheme.
Atributi elementa se lahko pojavijo v poljubnem vrstnem redu. Slednji so lahko zahtevani
(obvezni) ali opcijski, ne smejo pa se ponavljati. V kolikor ima atribut definirano privzeto
(ang. default) vrednost, bi odsotnost takšnega atributa pomenila enako, kot če bi ga
uporabili s privzeto vrednostjo. Vsak element in atribut v shemi ima podatkovni tip (ang.
datatype). XSD jezik definira številne osnovne tipe. V shemi pa je možno definirati tudi
dodatne tipe (ang. additional types), ki so lahko preprosti (ang. simple) ali kompleksni
(ang. complex). V vsebini lahko vidimo element definitions. Slednji ima kompleksni
podatkovni tip tDefinitions, ki je definiran v sami shemi.
2.3.4 Temelji BPMN sheme
Poglavje zajema informacije, ki bi jih lahko opredelili kot temelje BPMN sheme.
2.3.4.1 XSD datoteke
BPMN 2.0 shema je razdeljena na pet XSD datotek:
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 19
BPMN20.xsd,
Sematic.xsd,
BPMNDI.xsd,
DI.xsd in
DC.xsd.
Priporočeno je, da jih izvajalci shranijo lokalno, v enako mapo. Datoteka BPMN20.xsd
predstavlja najvišji nivo, ki vključuje Sematic.xsd in uvaža BPMNDI.xsd. Slednja uvaža še
datoteki DI.xsd in DC.xsd. BPMN20.xsd predstavlja paket infrastrukture (ang.
infrastructure) v jedru meta modela BPMN. Vsebuje samo dva elementa, definicije (ang.
definitions) in uvoz (ang. import). Posamezni element definitions je vedno na vrhu bilo
katere instance BPMN XML dokumenta. Element import omogoča posameznemu BPMN
modelu, da je lahko sestavljen na podlagi številnih BPMN XML dokumentov. Na takšen
način lahko ustvarimo globalna opravila oziroma procese, ki jih je mogoče večkrat
uporabiti in vključiti v različne modele. Za semantične in grafične podatke, je BPMN 2.0
standard definiral XML sheme Sematic.xsd in BPMNDI.xsd. BPMNDI.xsd uporablja tipe,
ki so definirani v DI.xsd. Slednja predstavlja shemo za skupne definicije diagramov (ang.
XML schema file for Diagram Common (DC)). DI in DC sta del standarda za definiranje
diagrama (ang. Diagram Definition standard (DD)), ki se je razvil iz strani OMG skupine.
Namenjen je definiranju opisov različnih tipov objektov oziroma elementov (na primer:
oblika, oznaka itd.) [20].
2.3.4.2 Semantični in grafični model
Področje v nadaljevanju je še posebej zanimivo za naše delo. BPMN XSD grafični model
(ang. graphical model) predstavlja informacije (podatke), ki se nanašajo na grafično
podobo elementov. Gre za informacije o obliki, poziciji, velikosti, povezovalnih točkah itd.
Omenjeni model je povsem ločen od semantičnega modela (ang. semantic model).
Informacije obeh modelov so zajete s posameznim elementom definitions. Grafični model,
poimenovan BPMNDI, ne vsebuje nobenih semantičnih podatkov. Informacije so podane
zgolj o obliki, velikosti in lokaciji. Na podlagi teh informacij iz BPMNDI ne izvemo ali
oblika predstavlja dogodek ali opravilo. Slednje bi lahko ugotovili v kolikor bi poiskali
bpmnElement atribut, ki je povezava do id vrednosti elementa v semantičnem modelu.
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 20
Tako pridemo do ugotovitve, da so navedene informacije v BPMNDI datoteki, brez
informacij v semantičnem modelu, nesmiselne in neuporabne.
2.3.4.3 ID in referenca na ID
Večina elementov v BPMN 2.0 XSD vsebuje atribut id, tipa xsd:ID. Jezik XSD tip definira
zgolj za uporabo pri atributih. Za tip ID veljajo določena pravila. Vrednost le teh se lahko
prične samo z znakom ali podčrtajem. Prav tako je nabor znakov, ki predstavljajo vrednost,
omejen zgolj na črke, števke, podčrtaje, vezaje in pike. Najbolj pomembno pa je, da je
predstavljeno z unikatno vrednostjo (glede na XML instanco in ne glede na ime atributa).
Če povemo drugače. V BPMN modelu lahko obstaja samo en element, katerega id
vrednost je npr. "_12345".
Pomembnost unikatne vrednosti je velika, saj obstajajo povezave med elementi modela.
Slednje se določajo z uporabo kazalcev (ang. pointers) na id vrednosti. Primer: vrednost
atributa sourceRef zaporednega toka, se ujema za id vrednostjo tokovnega vozlišča, ki je
na koncu toka zaporedja. Elementi in atributi, ki vsebujejo "Ref" v imenu, so običajno tipa
IDREF - predstavljajo kazalec na atribut tipa ID. XML dokument ne bo uspešno prestal
preverjanja ustreznosti vsebine, glede na shemo, če bo katerikoli od IDREF elementov ali
atributov kazal na vrednost id, ki v dokumentu manjka. Prav tako bo preverjanje
neuspešno, če v dokumentu obstajata dve (ali več) enaki id vrednosti.
2.3.4.4 Uvoz, ciljni imenski prostor in oddaljene reference na ID
Omenili smo že, da lahko instanca BPMN dokumenta uvozi tudi ostale dokumente
instance BPMN. Čeprav ne gre za povsem enako zadevo, kot pri uvažanju XSD datoteke v
XSD datoteko lahko rečemo, da deluje na podoben način. Eden izmed dokumentov
predstavlja najvišji nivo oziroma koren BPMN modela, vendar vsi dokumenti skupaj
predstavljajo en sam BPMN model. Funkcionalnost uvoza je ključna za BPMN
modularnost in ponovno uporabo.
Na primer pod-proces, ki ga je možno večkrat uporabiti (ang. reusable subprocess) je v
svojem dokumentu definiran kot proces na najvišjem nivoju (ang. top-level process).
Poimenujmo ga Obracun. Proces Obracun lahko predstavlja pod-proces, ki ga je možno
večkrat uporabiti. Prožimo ga lahko preko klica aktivnosti (ang. call activity), ki se nahaja
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 21
v drugem dokumentu. V tem primeru moramo Obracun uvoziti v dokument, v katerem se
sklicujemo nanj. Če procese definiramo in oblikujemo na takšen način, jih lahko
uporabimo v različnih procesih in na ta način tudi prihranimo na času, ki ga namenimo
modeliranju.
Ko v BPMN dokument uvozimo drugega, bodo nekateri "Ref" elementi ali atributi kazali
na id, ki se nahaja v drugi datoteki. V primeru, da pri načrtovanju nismo upoštevali, da
bomo v prihodnosti mogoče datoteki povezali, lahko pride do podvajanja vrednosti id. V
tem primeru ni prišlo do kršitve pravil sheme, saj smo znotraj posameznega dokumenta
ustvarjali unikatne vrednosti. Sedaj, ko imamo dokumenta povezana, pa lahko pride do
zmede pri kazalcih na id-je. Specifikacije BPMN v tem primeru navajajo zanimivo rešitev.
Da bi se znebili morebitnemu problemu v katerem bi kazalci kazali na podvojene id-je,
BPMN XSD definira številne "Ref" elemente in atribute kot tipe "QName" in ne IDREF. V
XSD QName (ang. qualified name) po navadi predstavlja oznako predpone za ime (ang.
name) imenskega prostora. Koda 2.2 prikazuje primer najpogostejše definicije oziroma
rabe.
Koda 2.2: QName - najpogostejša raba
<?xml version='1.0'?>
<doc xmlns:x="http://example.com/ns/foo">
<x:p/>
</doc>
Druga vrstica prikazuje definiranje predpone "x", ki se sklicuje v obliki URI povezave na
naslov "http://example.xom/ns/foo". Definirano predpono lahko sedaj v nadaljevanju
uporabljamo kot okrajšavo za omenjen imenski prostor. QName značke "x:p" je veljaven,
saj uporablja "x" kot referenco na imenski prostor in "p", kot lokalni del. Prav tako je
veljavna oznaka "doc". Slednja je sestavljena zgolj iz lokalnega dela.
BPMN v tem primeru ne uporabi definicije s katero bi se skliceval na ime. Uporabi ga za
sklicevanje na id vrednosti. Imenski prostor v tem primeru predstavlja targetNamespace, ki
je definiran v elementu definitions. V BPMN 2.0 XSD, targetNamespace predstavlja
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 22
zahtevan atribut korenskega elementa definitions. V XML je targetNamespace definiran za
shemo, v tem primeru pa govorimo o instanci dokumenta - natančneje modela BPMN. Cilj
uporabe predpone targetNamespace je podpora referencam id, da kažejo na elemente v
uvoženih dokumentih. Omenimo še dejstvo, da procesor shem ne more preverjati
ustreznosti in točnosti kazalcev ob uporabi QName. Nasprotno je če uporabimo IDREF.
Podajmo primer. Atribut sourceRef toka sporočila je po vsej verjetnosti referenca na
dokumenti, ki smo ga uvozili. V XSD je definiran kot QName. Določimo, da je izvor toka
sporočila opravilo, ki se nahaja v modelu Obracun, ki ga uvažamo. Opravilo ima id z
vrednostjo "Task001" in targetNamespace modela Obracun je določen s predpono
obracun. V tem primeru vrednost sourceRef ne bo zgolj "Task001" ampak
"obracun:Task001". S tem preprečimo možnost napačnega sklicevanja.
2.3.5 Razredi skladnosti BPMN 2.0
Specifikacije BPMN 2.0 navajajo informacije, ki opredeljujejo skladnost z notacijo. Orodje
lahko trdi skladnost z BPMN 2.0, če in samo če omenjena programska oprema upošteva
točke skladnosti, ki so navedene v dokumentu specifikacije notacije. V kolikor jih ne
upošteva v celoti, lahko zgolj trdimo, da orodje temelji na specifikaciji, ni pa skladna z njo.
Specifikacije navajajo štiri tipe skladnosti:
Skladnost modeliranja procesov (ang. process modeling conformance).
Skladnost izvedbe procesov (ang. process execution conformance).
Skladnost z BPEL izvedbo procesov (ang. BPEL process execution).
Skladnost modeliranja koreografije (ang. choreography modeling conformance).
Primer: orodje lahko navaja skladnost modeliranja procesov po specifikacijah BPMN 2.0,
ni potrebno, da pa je tudi skladno z modeliranjem koreografije. Seveda pa lahko orodja
izpolnjujejo več tipov skladnosti. V kolikor popolnoma izpolnjujejo vse tipe skladnosti, ki
smo jih navedli prej, govorimo o popolni BPMN skladnosti (ang. BPMN complete
conformance). Ker nas zanima prvi tip, bomo v našem delu predvsem izpostavili skladnost
pri modeliranju procesov. V specifikacijah BPMN 2.0 boste informacije o tem področju
zasledili v poglavju 2.1.
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 23
Orodje, ki trdi skladnost modeliranja procesov mora podpreti sledeče BPMN pakete:
Ključni BPMN elementi (ang. BPMN core elements), vključno z tistimi, ki so
definirani v paketih infrastruktura (ang. infrastructure), temelji (ang. foundation),
skupno (ang. common) in storitve (ang. service).
Diagrame procesa (ang. process diagrams), ki vključujejo elemente definirane v
paketih procesi (ang. process), aktivnosti (ang. activities), podatki (ang. data) in
človeška interakcija (ang. human interaction).
Diagrami sodelovanja (ang. collaboration diagrams), ki vključujejo bazene (ang.
pools) in tok sporočila (ang. message flow).
Pogovorni diagrami (ang. conversation diagrams), ki vključujejo bazene (ang.
pools), pogovore (ang. conversations) in povezave pogovorov (ang. conversation
links).
Alternativa popolni BPMN skladnosti, specifikacije opredeljujejo tri pod-razrede
skladnosti:
Opisni (ang. descriptive).
Analitični (ang. analytic).
Skupno izvedljivi (ang. common executable).
Navedeni pod-razredi so bili opredeljeni v zaključni fazi definiranja specifikacij BPMN
2.0. Ker specifikacije navajajo številna pravila in pogoje, ki so precej zahtevni za
implementacijo, je veliko strokovnjakov menilo da razvijalci orodja s popolno BPMN
skladnostjo ne bodo nikoli sestavili in predstavili. Obstaja namreč kar nekaj elementov, ki
se izjemno redko uporabljajo, kar pomeni da se jih razvijalci orodij ne bi trudili vključiti.
2.3.5.1 Opisni pod-razred
Opisni pod-razred se ukvarja z elementi, ki so na najvišjem nivoju modeliranja. Skupaj z
analitičnim sta posebej naravnana za uporabo pri neizvedljivih modelih (ang. non-
executable models). Vključujeta zgolj informacije, ki so vidne na samem diagramu. Tabela
2.1 prikazuje seznam elementov in atributov, ki so navedeni po XML imenih in jih lahko
dejansko zasledimo v XSD datoteki.
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 24
Tabela 2.1: Elementi in atributi opisnega pod-razreda
Elementi Atributi
participant (pool) id, name, processRef
laneSet id, lane with name, childLaneSet,
flowElementRef
sequenceFlow id, name, sourceRef, targetRef
messageFlow id, name, sourceRef, targetRef
exclusiveGateway id, name
parallelGateway id, name
task (none) id, name
userTask id, name
serviceTask id, name
subProcess id, name, flowElement
callActivity id, name, calledElement
dataObject id, name
textAnnotation id, text
association id, name, sourceRef, targetRef,
associationDirection
dataAssociation id, name, sourceRef, targetRef
dataStoreReference id, name, dataStoreRef
startEvent (none) id, name
endEvent (none) id, name
messageStartEvent id, name, messageEventDefinition
messageEndEvent id, name, messageEventDefinition
timerStartEvent id, name, timerEventDefinition
terminateEndEvent id, name, terminateEventDefinition
documentation text
Group id, categoryValueRef
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 25
Desni stolpec v tabeli je še posebej pomemben, saj definira podrobnosti posameznega
elementa. Da lahko orodje trdi podporo opisnemu pod-razredu, mora vključevati vse
elemente ter vse atribute elementa, ki jih navaja tabela. Vidimo lahko, da atributi predvsem
vsebujejo informacije o identifikaciji elementa (name, id) in grafični predstavitvi na primer
ikone - messageEventDefinition.
2.3.5.2 Analitični pod-razred
Podobno kot opisni pod-razred, analitični upravlja z informacijami, ki so pomembne za
grafično vizualno predstavitev. Podrobnosti o elementih ne podajo informacij, s katerimi bi
definirali simbol ali obliko v času izvajanja procesa. Analitični pod-razred vsebuje vse iz
opisnega pod-razreda, ter navedeno v Tabela 2.2.
Tabela 2.2: Elementi in atributi analitičnega pod-razreda
Elementi Atributi
sequenceFlow conditionExpression, default
sendTask id, name
receiveTask id, name
Looping activity standardLoopCharacteristics
Multi-instance activity multiinstanceLoopCharacteristics
exclusiveGateway Default
inclusiveGateway id, name, default
eventBasedGateway id, name, eventGatewayType
Link event pair id, name, linkEventDefinition/@name
Signal start/end event id, name, signalEventDefinition
Signal throw/catch intermediate event id, name, signalEventDefinition
Signal boundary event id, name, signalEventDefinition,
attachedToRef, cancelActivity
Message throw/catch intermediate
event id, name, messageEventDefinition
Message boundary event id, name, messageEventDefinition,
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 26
Elementi Atributi
attachedToRef, cancelActivity
Timer catching event id, name, timerEventDefinition
Timer boundary event id, name, timerEventDefinition,
attachedToRef, cancelActivity
Error boundary event id, name, errorEventDefinition,
attachedToRef
Error end event id, name, errorEventDefinition
Escalation throw intermediate event id, name, escalationEventDefinition
Escalation end event id, name, escalationEventDefinition
Escaltaion boundary event
id, name, escalationEventDefinition,
attachedToRef, cancelActivity (false
only)
Conditional start event id, name, conditionalEventDefinition
Conditional catch intermediate event id, name, conditionalEventDefinition
Conditional boundary event id, name, conditionalEventDefinition,
attachedToRef, cancelActivity
message id, name
Message flow messageRef
2.3.5.3 Skupno izvedljivi pod-razred
Tretji pod-razred, ki ga specifikacije BPMN 2.0 definirajo v sklopu skladnosti modeliranja
procesov, je poimenovan skupno izvedljivi. Nabor elementov in atributov se prepleta med
opisnim in analitičnim pod-razredom. Vendar omenjeni pod-razred vsebuje še dodatne
atribute, ki se nanašajo predvsem na izvedljivi del. Skupno izvedljivi pod-razred je
namenjen orodjem, ki omogočajo izvedbo modeliranih modelov. Specifikacije navajajo
določena pravila, katera morajo takšna orodja upoštevati:
Jezik s katerim definiramo tip podatkov (ang. data type definition) mora biti XML
shema.
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 27
Jezik s katerim definiramo vmesnik storitev (ang. service interface definition) mora
biti WSDL.
Jezik s katerim dostopamo do podatkov (ang. data access) mora biti XPath.
Tabela 2.3 prikazuje elemente, ki spadajo v skupno izvedljivi pod-razred. Specifikacije pa
opredeljujejo tudi seznam oziroma nabor elementov, ki spadajo v skupino podpornih
razredov. Tabela 2.4 zajema omenjene elemente in atribute podpornih razredov.
Tabela 2.3: Elementi in atributi skupno izvedljivega pod-razreda
Elementi Atributi
sequenceFlow (unconditional) id, (name), sourceRef, targetRef
sequenceFlow (conditional) id, name, sourceRef, targetRef,
conditionExpression
sequenceFlow (default) id, name, sourceRef, targetRef, default
subProcess id, name, flowElement, loopCharacteristics,
boundaryEventRefs
exclusiveGateway id, name, gatewayDirection, default
parallelGateway id, name, gatewayDirection
startEvent (none) id, name
endEvent (none) id, name
eventBasedGateway id, name, gatewayDirection, eventGatewayType
userTask
id, name, renderings, implementation,
resources, ioSpecification,
dataInputAssociations, dataOutputAssociations,
loopCharacteristics, boundaryEventRefs
serviceTask
id, name, renderings, implementation,
resources, ioSpecification,
dataInputAssociations, dataOutputAssociations,
loopCharacteristics, boundaryEventRefs
callActivity id, name, calledElement, ioSpecification,
dataInputAssociations, dataOutputAssociations,
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 28
Elementi Atributi
loopCharacteristics, boundaryEventRefs
dataObject id, name, isCollection, itemSubjectRef
textAnnotation id, text
dataAssociation id, name, sourceRef, targetRef, assignment
messageStartEvent id, name, messageEventDefinition, dataOutput,
dataOutputAssociations
messageEndEvent id, name, messageEventDefinition, dataInput,
dataInputAssociations
terminateEndEvent (Terminating trigger is combination with one of
the other end events)
Catching message
intermediate event
id, name, messageEventDefinition, dataOutput,
dataOutputAssociations
Throwing message
intermediate event
id, name, messageEventDefinition, dataInput,
dataInputAssociations
Catching timer intermediate
event id, name, timerEventDefinition
Boundary error intermediate
event
id, name, attachedToRef, errorEventDefinition,
dataOutput, dataOutputAssoiciations
Tabela 2.4: Elementi in atributi podpornih razredov skupno izvedljivega pod-razreda
Elementi Atributi
StandardLoopCharacteristics id, loopCondition
MultiInstanceLoopCharacteristics id, isSequential, loopDataInput,
inputDataItem
Rendering /
Resource id, name
ResourceRole id, resourceRef,
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 29
Elementi Atributi
resourceAssignmentExpression
InputOutputSpecification id, dataInputs, dataOutputs
DataInput id, name, isCollection, itemSubjectRef
DataOutput id, name, isCollection, itemSubjectRef
ItemDefinition id, strucure or import
Operation id, name, inMessageRef, outMessageRef,
errorRefs
Message id, name, structureRef
Error id, structureRef
Assignment id, from, to
MessageEventDefinition id, messageRef, operationRef
TerminateEventDefinition id
TimerEventDefinition id, timeDate
2.3.6 Grafični model BPMNDI
BPMN 2.0 prinaša XML shemo, ki je namenjena grafičnemu modelu. Poimenovali so jo
BPMN Diagram interchange ali okrajšano BPMNDI. Že iz imena lahko sklepamo, da je
namenjena izmenjavi oz. prenosu diagrama. Dokument opisuje pozicijo in velikost
elementov (v nadaljevanju poimenovani tudi kot gradniki) in priključkov (povezav) (ang.
connectors), kot tudi povezano strukturo strani diagramov modela. OMG je ustrezno
BPMNDI shemo predlagal šele v zaključni fazi. V beta različici specifikacij, je OMG želel
enojni meta model, ki bi podpiral poljubni tip diagrama (UML in BPMN). Definirani
univerzalni meta model se ni izkazal za uspešnega. XML izmenjava BPMN diagramov,
med orodji za modeliranje, je bila ne praktična. BPMNDI se je izkazal za bolj primernega,
hkrati pa je omogočal oblikovanje strukture strani modela. BPMN grafični model ne more
delovati samostojno. Mora biti skladen in v povezavi z informacijami v semantičnem
modelu. Primer: BPMNDI razlikuje task od timer boundary event ali sequence flow od
data association samo na podlagi informacije zapisane v atributu bpmnElement, ki ga
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 30
oblika oziroma element vsebuje. Slednja pa predstavlja povezavo do ustreznega
semantičnega modela. Informacije niso podvojene med BPMNDI in semantičnem modelu,
temveč se razdelijo med njima. Tako bomo tekst oznake (ang. label) našli v semantičnem
modelu, medtem ko bo BPMNDI vseboval informacije o oznaki - na primer: pozicija,
informacije o pisavi itd.
Verjetnost, da bo BPMN orodje popolnoma enako sestavilo in oblikovalo grafično
predstavitev diagrama, ki je nastala na podlagi serializacije iz drugega orodja, je zelo
majhna. Odgovor zakaj je temu tako, dobimo v lastnih grafičnih knjižnicah orodja. Večina
orodij namreč uporablja lastne grafične knjižnice, ki vsebujejo svoje informacije o
velikosti, razmerjih, pozicijah oznak posameznega elementa. Ob uvozu takšno orodje ne
more poljubno oblikovati videz elementov tako, da bodo ti enaki originalnemu diagramu,
vendar BPMNDI poda informacije, da se temu lahko približajo. Prav tako BPMNDI poda
strukturo strani originalnega modela - na primer: ali je nivo podrejenega procesa narisan
znotraj elementa razširljivi pod-proces (ang. expanded subprocess) ali v ločenem
diagramu.
2.3.6.1 Osnovne informacije
BPMNDI ne uporablja BPMN 2.0 imenskega prostora. Uporablja svoj prostor, natančneje
tri imenske prostore. Glavni imenski prostor predstavlja
http://www.omg.org/spec/BPMN/20100524/DI, ki je običajno predstavljen s predpono
bpmndi. Uporablja se za večino BPMNDI elementov, vključno z elementom
BPMNDiagram, ki ga zasledimo na najvišjem nivoju. Element dc:Bounds s katerim
opišemo pozicijo in velikost gradnikov, se nahaja v drugem imenskem prostoru -
http://www.omg.org/spec/DD/20100524/DC (predpona dc). V tretjem na primer najdemo
element di:waypoint, ki opisuje točke na povezavi do gradnika. Slednji uporablja imenski
prostor http://www.omg.org/spec/DD/20100524/DI, ki je običajno predstavljen s predpono
di. Grafični model obsega več strani oziroma diagramov, ki so serializirani v BPMNDI z
elementom BPMNDiagram. Slednji ima podrejeni element BPMNPlane. Kakšen je namen
uporabe obeh, ni povsem jasen, saj specifikacije navajajo, da vsak element BPMNDiagram
mora imeti natanko en podrejeni element BPMNPlane. Diagram v BPMNDI nima omejitve
velikosti strani. Stran je lahko razširjena tako rekoč v neskončno. Izhodišče koordinatnega
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 31
sistema se nahaja v zgornjem levem kotu. Stran lahko neskončno raztegnemo v x in y
smer, pri čemer negativne vrednosti koordinat niso dovoljene. Pozicija (ang. location)
gradnika je definirana s koordinatami x, y. Omenjena koordinata bo predstavljala zgornjo
levo točko oziroma vrh zgornjega levega kota, če gledamo pravokotnik, ki objema gradnik.
Velikost (ang. size) gradnika je opredeljena z višino in širino prej omenjenega
pravokotnika. Različna orodja različno interpretirajo koordinatni sistem. Na primer:
koordinatni sistem v orodju Visio ima svoje izhodišče postavljeno v spodnji levi kot strani.
Za določitev pozicije gradnika pa izhaja iz sredine pravokotnika, ki obdaja gradnik. Stran
vsebuje seznam dvodimenzionalnih oblik (BPMNShape) in priključkov (BPMNEdge).
Vsakemu od omenjenih elementov je podana informacija o poziciji in velikosti. Elementi
so predstavljeni z atributom bpmnElement, ki predstavlja oddaljeni (QName) kazalec na id
semantičnega elementa. Omenjeni atribut je efektivno potreben za vse elemente, čeprav po
XSD ni zahtevan.
2.3.6.2 Nivoji procesa in strani
BPMN model lahko vključuje številne procese. Ti so predstavljeni na višjem nivoju.
Delujejo lahko samostojno ali pa so klicani s strani elementa callActivity. V tem primeru
govorimo o procesih, ki jih je možno večkrat uporabiti (ang. reusable subprocess). Vsak
proces je hierarhična struktura, ki vsebuje številne nivoje procesa. Vsak od nivojev je v
XML strukturi obdan z elementom, ki predstavlja tip pod-procesa, poimenovanim
subprocess-type. Slednji je lahko subProcess, adHocSubProcess, transaction ali
callActivity. Nivo procesa, ki vsebuje element subprocess-type predstavlja nadrejeni proces
temu, ki ga vključuje. Proces in pod-proces sta v razmerju nadrejeni - podrejeni. Pogosto
zasledimo tudi poimenovanje, da sta v razmerju starš - otrok (ang. parent - child).
Tok elementov, ki se nahaja v podrejenem nivoju, je lahko grafično predstavljen na isti
strani kot nivo starša tj. nadrejeni nivo. Pri tem se uporabi element razširjeni elementi pod-
procesa (ang. expanded subprocess shape). Lahko pa je predstavljen v ločeni povezani
strani (ang. separate linked page), pri čemer uporabimo element, ki predstavlja zložene
elemente pod-procesa (ang. collapsed subprocess shape). Slednjega uporabimo na
nadrejenem nivoju, na podrejenem pa ni potrebno uporabiti gradnika za pod-proces. Bruce
Silver [15] v svoji knjigi oba pristopa poimenuje kot inline modeling style in hierarchical
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 32
modeling style, kar bi lahko razumeli kot neposredni ali hierarhični stil modeliranja. Kot
smo že dejali za grafično predstavitev poskrbi BPMNDI. Razložimo kako je omenjeno
oblikovano v BPMNDI. Ključnega pomena je atribut BPMNPlane elementa bpmnElement,
ki predstavlja semantični element na katerega se sklicujejo strani v grafičnem modelu. Gre
za zahtevan QName kazalec na process, collaboration ali tip pod-procesa (subProcess,
callActivity, transaction ali adHocSubProcess). Ti kazalci za vsak BPMNPlane podajo
informacije o strukturi strani grafičnega modela. BPMNPlane, ki kaže na element tip pod-
procesa, je po definiciji pod-nivojska stran (ang. child-level page). Bilo katera druga stran
je nad-nivojska stran (ang. top-level page).
Interna skladnost narekuje pod-nivojski strani vsebovanje samo tekočih elementov, ki
pripadajo subprocess-type elementu. Ne vsebuje pa na primer elemente ločenega
nadrejenega procesa, ki je na strani obdan z elementom bazen. V kolikor bi, ne bi obstajala
nobena povezava v semantičnem modelu med slednjim in stranjo, ki se nahaja v BPMNDI.
Na drugi stani pa nad-nivojska stran lahko vključuje elemente, ki pripadajo več kot samo
enemu procesu, dokler elementi, ki pripadajo določenem procesu niso na strani obdani z
elementom bazen. Če nad-nivojska stran vsebuje tekoče elemente več kot enega procesa,
bo atribut bpmnElement elementa BPMNPlane kazal na collaboration (tj. sodelovanje). Če
vsebuje elemente enega procesa, bo bpmnElement kazal ali na proces ali na sodelovanje.
2.3.6.3 BPMNDiagram
Element na najvišjem nivoju v BPMNDI je BPMNDiagram, ki predstavlja stran. Model
lahko vsebuje poljubno število omenjenih elementov. BPMN model, ki vsebuje samo
semantične podatke, je po definiciji brez BPMNDiagram elementov. Vsak element
BPMNDiagram ima podrejeni element BPMNPlane, ki je po specifikacijah zahtevan.
Slednji služi kot nekakšen zabojnik, ki hrani informacije o oblikah in priključkih, ki se
nahajajo na strani. Nekateri si element BPMNPlane predstavljajo kot posamezno plast
(ang. layer), kakršne zasledimo v orodjih Visio ali Autocad. To ni povsem pravilno, saj
BPMNDiagram mora vsebovati natančno en element BPMNPlane.
BPMNDiagram in BPMNPlane predstavljata stran kot celoto. Oba elementa imata atribut
id. Element BPMNDiagram ima tudi atribut name.
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 33
Atribut name, ki ga vsebuje element BPMNDiagram naj predstavlja ime strani v
orodju BPMN.
Atribut resolution, ki ga vsebuje BPMNDiagram predstavlja razmerje, ki je podano
v enoti točk na inč (ang. pixels per inch). Omenjen atribut je potreben za
preoblikovanje BPMNDI pozicije in velikosti elementov, glede na dolžino strani.
Omenimo še dejstvo, da v BPMNDI ne moremo definirati alternativne enote - na
primer: točk na centimeter (ang. pixels per cm).
Razlika: documentation v semantičnem modelu predstavlja element. V
BPMNDiagram slednji predstavlja atribut.
Zraven zahtevanega pod-rejenega elementa BPMNPlane, ima element BPMNDiagram še
pod-rejeni element BPMNLabelStyle, ki pa je opcijski. Slednji definira obliko pisave, ki se
uporablja v oznakah na strani.
2.3.6.4 BPMNPlane
BPMNPlane vsebuje urejen seznam podrejenih elementov BPMNShape in BPMNEdge.
Slednji predstavljajo oblike in priključke elementov, ki se nahajajo na strani. Zaporedje
elementov znotraj BPMNPlane določa Z-order1, od konca proti začetku.
Atribut bpmnElement elementa BPMNPlane definira stran kot nad-nivojsko ali pod-
nivojsko. Kot smo že omenili prej, v kolikor kaže na subprocess-type element je pod-
nivojska stran, drugače je nad-nivojska.
2.3.6.5 BPMNShape
Element predstavlja grafično predstavitev posameznega semantičnega BPMN elementa, ki
ne predstavlja priključka/povezave (ang. connector).
Atribut bpmnElement je kazalec QName na semantični BPMN element. Predstavlja
edini indikator tipa oblike. Specifikacije navajajo, da je atribut obvezen oziroma
zahtevan, vendar XSD tega ne vsiljuje.
Atribut isHorizontal je opcijski. Vsebuje logične vrednosti (ang. boolean) in je
namenjen zgolj gradnikom bazen in steza. Atribut nima določene privzete
vrednosti. Gradnik bazen je tisti pri katerem bpmnElement kaže na participant (tj
udeleženec) v semantičnem modelu.
1 Z-order - Vrstni red prekrivanja dvodimenzionalnih predmetov. Ko se dva gradnika prekrivata, njuni "Z-
vrednosti" določata, kateri se pojavi na vrhu drugega [43].
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 34
Opcijski atribut isExpanded prav tako vsebuje logične vrednosti. Namenjen je zgolj
subprocess-type elementom (subProcess, callActivity, transaction ali
adHocSubProcess). Atribut nima definirane privzete vrednosti. V kolikor je
vrednost atributa false, bo atribut bpmnElement elementa BPMNShape kazal na
subprocess-type element, ki je predstavljen kot zložen element pod-procesa (ang.
collapsed subprocess shape). V primeru vrednosti true, bo kazal na subprocess-
type element, ki je predstavljen kot razširjeni element pod-procesa (ang. expanded
subprocess shape).
Opcijski atribut isMarkerVisible vsebuje logične vrednosti in je namenjen samo
elementom exclusiveGateway. Atribut nima privzete vrednosti. Če je vrednost true,
se v sredini gradnika prikaže simbol "X".
dc:Bounds predstavlja zahtevan podrejeni element, ki definira koordinate za
lokacijo in velikost, pravokotnika, ki obdaja grafični prikaz elementa. Če želimo
pridobiti informacijo v inčih, moramo vrednosti koordinat dc:Bounds deliti z
vrednostjo atributa resolution, ki se nahaja v elementu BPMNDiagram. Koordinati
x in y sta zahtevani in sta tipa xsd:double. Položaj le teh je v zgornjem levem kotu
pravokotnika, ki obdaja obliko gradnika. Koordinati za velikost width in height sta
prav tako zahtevani in sta tipa xsd:double.
Podrejeni element BPMNLabel je opcijski. Definira pozicijo in stil pisave oznak, ki
se nahajajo v diagramu. Tekst oznake je definiran v ustreznem semantičnem
elementu. Atribut labelStyle je QName kazalec na BPMNLabelStyle, ki je podrejeni
element, elementa BPMNDiagram. Podrejeni element dc:Bounds definirala
lokacijo in velikost oznake.
V grafičnem modelu element BPMNShape ne more vsebovati elementa BPMNShape, tudi
če sta modelirana eden znotraj drugega. Primer: opravilo je modelirano in vstavljeno
znotraj elementa bazen. V tem primeru sta omenjena elementa sorodnika (ang. siblings).
Oba sta podrejena istemu BPMNPlane elementu.
2.3.6.6 BPMNEdge
Element je grafična predstavitev posameznih BPMN priključkov (ang. connector).
Atribut bpmnElement je QName kazalec na connector v semantični predstavitvi.
Predstavlja edini indikator tipa oblike. Specifikacije navajajo, da je atribut
zahtevan, čeprav XSD tega ne vsiljuje.
QName atributa sourceElement in targetElement sta opcijska. Predstavljata kazalce
na BPMNDI elemente. Specifikacije navajajo, da se uporabita kadar gradnika na
katera kažeta nista enaka tistim, na katere bpmnElement reference kažejo preko
sourceRef in targetRef.
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 35
Opcijski atribut messageVisibleKind lahko vsebuje vrednosti: initiating ali non-
initiating. Velja samo za toke sporočila (ang. message flow), ki se sklicujejo na
sporočilo. Uporabljal bi se naj samo kadar je na toku sporočila prikazan simbol za
sporočilo. Vrednost initiating naj bi ponazarjala bela kuverta (ang. white envelope),
medtem ko je vrednosti non-initiating namenjena temna (ang. shaded envelope).
di:waypoint predstavlja podrejeni element, ki je zahtevan. Predstavlja urejeni
seznam koordinat x in y, vse od začetka do konca povezave. Vsaj dva elementa
di:waypoint sta zahtevana za vsak BPMNEdge. Smerne točke (ang. waypoints), ki
so med prvo in zadnjo, bi lahko poimenovali krivuljne točke (ang. bendpoints).
Vsak di:waypoint element ima podrejena x in y elementa. Slednja sta zahtevana
oziroma obvezna in sta tipa xsd:double.
Podrejeni element BPMNLabel je opcijski in je enak tistemu, ki smo ga opisali v
BPMNShape.
2.4 Datotečni formati na področju medobratovalnosti modelov procesov
Datoteka (ang. file) je skupina zaporednih podatkov v operacijskem sistemu, ki predstavlja
zaključeno celoto [21].
Sledijo poglavja v katerih so zajeti datotečni formati, ki so relevantni za našo domeno.
Slednje smo pridobili na podlagi analize orodij za načrtovanje poslovnih procesov. V
orodjih smo preverili v katere formate lahko izvozimo (ang. export) ustvarjen model
oziroma obratno, kateri format ali kateri tip datoteke je sprejemljiv za uvoz (ang. import).
Dejali bi lahko, da smo opazili dve skupini:
1. V prvo skupino bi lahko uvrstili formate, ki so bili ustvarjeni za širši krog uporabe.
Zgradba slednjih je dokaj preprosta, saj se ob ustvarjanju oblike oziroma strukture
datotek strmi k razumevanju le te. Formati običajno delujejo medobratovalno. To
pomeni, da jih lahko uporabimo v različnih orodjih oziroma pri različnih namenih.
Primer takšnega formata je XML zapis.
2. V drugo skupino uvršamo manj razširjene formate. Običajno gre za formate, ki so
last orodja. To pomeni, da končnica ustvarjene datoteke predstavlja orodje. Na
podlagi le te, lahko takoj ugotovimo v katerem orodju je datoteka nastala.
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 36
Vključili smo tiste formate, ki so se največkrat pojavijo. V nadaljevanju so omenjeni
formati predstavljeni.
2.4.1 XML
V ospredje moramo postaviti jezik XML. Slednjega je moč zaslediti na različnih področjih.
Velikokrat zasledimo datoteke s končnico xml, vendar XML ni samo to. Jezik predstavlja
format, ki ga uporabljajo številna orodja pri oblikovanju lastnih datotek. Zaradi
preprostosti in dobre strukturiranosti podatkov, veliko datotečnih zapisov temelji na XML.
Slednje bi lahko potrdili tudi mi. V sklopu magistrskega dela smo raziskali, kateri zapisi in
datotečni formati se pojavijo najpogosteje. Opazili smo, da večina le teh temelji na formatu
XML. V nadaljevanju je predstavljen strnjen opis jezika in nekaterih lastnosti.
Kratica XML (ang. extensible markup language) označuje razširljiv označevalni jezik, ki
predstavlja nabor pravil za kodiranje dokumentov. Ti dokumenti so napisani tako, da je
vsebina razumljiva strojni obliki. Jezik je definiran v specifikaciji XML 1.0, ki ga
nadzoruje W3C, in ostalih sorodnih specifikacijah, ki so odprtega standarda [22].
Cilj oblike XML je predstaviti oziroma podariti preprostost, splošnosti in uporabnost.
Dandanes ga pogosto zasledimo na področju spleta. Gre za tekstovni podatkovni format z
močno podporo za različne jezike na svetu. Čeprav se zgradba XML osredotoča na
dokumente, se veliko uporablja za prikaz poljubnih podatkovnih struktur (na primer: v
spletnih storitvah).
Od leta 2009 naprej, je bilo razvitih veliko jezikov, ki so za izhodišče imeli jezik XML.
Tako so nastali RSS (ang. really simple syndication), Atom, SOAP (ang. simple object
access protocol) in XHTML (ang. extensible hypertext markup language). Omenjen format
danes srečamo tudi v večini pisarniških orodij, kot so Microsoft Office, OpenOffice.org in
Apple iWork [23].
Po definiciji je dokument XML niz znakov. Dovoljen je skoraj vsak "legalni" unikod (tj.
standard z a kodiranje znakov) - omejitve pri tem so majhne. Dokument se lahko prične z
deklaracijo, ki določa informacije o samem dokumentu. Deklaracija je dejansko navodilo
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 37
za procesiranje, ki določi dokument kot XML. Praviloma bi naj vsak dokument XML začel
z navedbo deklaracije. Koda 2.3 prikazuje primer deklaracije.
Koda 2.3: Primer deklaracije XML
<?xml version="1.0" encoding="UTF-8" standalone="no" ?>
Sledijo znaki, ki sestavljajo dokument, ki se delijo na značke in vsebino. Značke in vsebino
lahko ločimo zaradi preprostih sintaktičnih pravil. Vsi znaki ali besede, ki označujejo
značke se pričnejo z znakom "<" in končajo z znakom ">" ali pa se pričnejo z znakom "&"
in končajo z znakom ";". Vsi preostali nizi znakov, ki ne predstavljajo značk, so vsebina.
Značka je označevalni konstrukt. Poznamo tri vrste značk:
Začetne značke (na primer: <predmeti>), ki označujejo začetek elementa.
Vsebujejo lahko poljubno število atributov.
Končne značke (na primer: </predmeti>), pri katerih pred ime elementa dodamo
poševnico in označuje zaključek elementa.
Značke, ki predstavljajo prazni element (na primer <konec-vrstice/>. Teh značk ni
potrebno zaključiti s končno značko.
Konstrukt značke je lahko sestavljen iz imena in lastnosti (tj. atributi - ang. atributtes), če
govorimo o začetni znački ali prazni znački elementa.
Koda 2.4: Primer značke z atributom
<korak st="5">Pritisnite tipko stop.</korak>
Koda 2.4 podaja primer značke korak, ki vsebuje atribut "st", ki ima vrednost 5. Znački
sledi vsebina elementa le-ta pa se zaključi s pričetkom zaključne značke ("</korak>").
2.4.2 BPMN
Z definiranjem specifikacij BPMN 2.0 je prišlo do nekaterih sprememb in novosti. Pri
oblikovanju in definiranju novih pravil in smernic, je bilo veliko poudarka na izmenjavi
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 38
modelov. OMG je oblikoval datoteko s končnico bpmn. Vsebina slednje je oblikovana v
formatu, ki je (najbolj) primeren za izmenjavo. Zapis je oblikovan na podlagi jezika XML.
Pravila za oblikovanje dokumenta pa opisujejo BPMN sheme. BPMN 2.0 XML bi naj
podpirala vsa orodja, ki podpirajo BPMN standard 2.0. Koda 2.5 prikazuje primer zapisa,
ki se nahaja v datoteki BPMN [14].
Koda 2.5: Primer zapisa v datoteki *.bpmn
<?xml version="1.0" encoding="UTF-8"?>
<bpmn:definitions xmlns:bpmn="http://www.omg.org/spec/BPMN/20100524/DI”
targetNamespace="sample1.diagram1"
xmlns:bpmndi="http://www.omg.org/spec/BPMNDI/1.0.0"
xmlns:d1="sample1.diagram1" xmlns:s1="sample1.semantic1"
xmlns:main="sample1.main">
<bpmndi:BPMNDiagram scale="1.0" unit="Pixel">
<bpmndi:BPMNPlane element="main:collaboration1">
<!-- content here -->
</bpmndi:BPMNPlane>
</bpmndi:BPMNDiagram>
</bpmn:definitions>
2.4.3 XPDL
XPDL (ang. XML Process Definition Language) bi lahko opisali kot jezik s katerim
definiramo proces [24][25]. Predstavlja standardizirano obliko formata, ki je nastal pod
okriljem WfMC (ang. Workflow Management Coalition). Namen je bil ustvariti format, ki
bo služil za izmenjavo definicij poslovnega procesa, med različnimi produkti, ki
omogočajo delo z delovnimi tokovi. XPDL definira XML shemo za definiranje
deklarativnih delov delovnega toka oziroma poslovnega procesa. Ustvarjen je za
izmenjavo tako grafičnih, kot semantičnih definicij delovnega toka poslovnega procesa.
Trenutno ga opisujejo kot najbolj primernega za izmenjavo BPMN diagramov. To dejstvo
nekako ne preseneča, saj so ob ustvarjanju formata za izhodišče vzeli prav BPMN notacijo.
XPDL tako vsebuje elemente, ki hranijo podatke o grafiki (to so gradniki, ki se nahajajo v
procesu) - na primer X in Y pozicija grafike, kot tudi izvršilni vidik, ki se uporabi kadar
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 39
želimo proces izvesti. S tem se XPDL razlikuje od BPEL (ang. Business Process Execution
Language). Slednji je namreč osredotočen samo na izvajalni del procesa in ne vsebuje
informacij o definiciji grafičnih elementov diagrama oziroma procesa.
Lahko bi dejali, da nam XPDL predstavlja XML serializacijo (ang. XML serialization)
BPMN procesa.
Do sedaj opisano si poglejmo na praktičnem primeru [26]. Za lažje razumevanje sledi
osnovnejši primer. Najprej je proces predstavljen v obliki diagrama oziroma slike, nato pa
v obliki XPDL dokumenta.
Slika 2.2: Primer XPDL - diagram
Slika 2.2 prikazuje zelo preprost primer diagrama. Vsa orodja, ki nudijo podporo jeziku
XPDL, bi morala ustrezno ustvariti vsebino dokumenta. Diagram vsebuje tri elemente,
lahko jih poimenujemo tudi vozlišča, ki so:
začetni element,
aktivnost in
končni element.
V XPDL so vsa vozlišča predstavljena z značko <Marching Band Activities>. Vsaka
aktivnost vsebuje atributa ime (ang. name) in unikatno vrednost id. Če v tem koraku
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 40
izpustimo natančnejše definiranje elementov, dobimo približno takšno obliko vsebine
XPDL dokumenta, ki jo prikazuje Koda 2.6:
Koda 2.6: XPDL - definiranje aktivnosti
<Activities>
<Activity Id="153189" Name="Start Event"> ... </Activity>
<Activity Id="153190" Name="Activity"> ... </Activity>
<Activity Id="153191" Name="End Event"> ... </Activity>
</Activities>
Puščice oziroma povezave med elementi določimo z uporabo značke <Transition>. Znački,
ki smo ju predstavili zgoraj, predstavljata poglavitni del XPDL datoteke. V grobem lahko
tako sestavimo proces. XPDL pa ne nudi podpore za samo te podatke. Shrani lahko veliko
metapodatkov, ki natančneje opredeljujejo aktivnosti in povezave v modelu procesa. Tako
je videti podrobneje opisana aktivnost (Koda 2.7).
Koda 2.7: XPDL - podrobnejši opis aktivnosti
<Activity Id="153190" Name="Activity">
<Implementation><No/></Implementation>
<Performer>Manager</Performer>
<Priority/>
<Documentation/>
<TransitionRestrictions>
<TransitionRestriction>
<Join Type="XOR"/>
<Split Type="XOR">
<TransitionRefs><TransitionRef Id="153204"/></TransitionRefs>
</Split>
</TransitionRestriction>
</TransitionRestrictions>
<NodeGraphicsInfos>
<NodeGraphicsInfo LaneId="1" ToolId="Interstage BPM"
IsVisible="true" Page="1">
<Coordinates XCoordinate="317.0" YCoordinate="83.0"/>
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 41
</NodeGraphicsInfo>
</NodeGraphicsInfos>
</Activity>
Prav tako pa lahko podrobneje opišemo oziroma definiramo povezave, ki se nahajajo v
diagramu. Koda 2.8 prikazuje del vsebine XPDL datoteke, ki je namenjena definiranju
povezave.
Koda 2.8: XPDL - podrobnejši opis povezave
<Transition Id="153203" Name="Arrow1"
From="153189" To="153190">
<ConnectorGraphicsInfos>
<ConnectorGraphicsInfo FillColor="light blue"
ToolId="Interstage Business Process Manager"
IsVisible="true" Page="1">
<Coordinates XCoordinate="116.0" YCoordinate="83.0"/>
<Coordinates XCoordinate="264.0" YCoordinate="83.0"/>
</ConnectorGraphicsInfo>
</ConnectorGraphicsInfos>
</Transition>
Prikazan primer je služil zgolj za demonstracijo, da bralec dobi predstavo kako zgleda
vsebina dokumenta XPDL. Jezik pa ponuja še druge značke in možnosti.
XPDL se danes uporablja v več kot 80-ih različnih produktih, ki so namenjeni izmenjavi
definicij procesa [25]. Številna podjetja te produkte oziroma orodja uporabljajo
vsakodnevno. V poplavi številnih produktov, ki omogočajo različna opravila in različno
podpirajo posamezne segmente, se je nesmiselno vezati na eno orodje. Zato podjetja
dandanes iščejo orodja, ki nudijo večjo podporo, saj si s tem omogočajo več različnih poti
in boljši dostop do drugega orodja. Kot vemo iz prakse, so določena orodja bolj primerna
za modeliranje, nekatera za izvedbo spet tretja za optimizacijo. Na tem mestu je jezik
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 42
XPDL primeren, saj dobro definira proces, ki ga lahko ustrezno prenašamo med prej
navedenimi orodji in tako nemoteno nadaljujemo delo nad ustvarjenim modelom.
2.4.4 VSD
VSD je končnica oziroma datotečni format orodja Microsoft Visio [27]. Orodje predstavlja
aplikacijo, ki omogoča delo z diagrami in vektorsko grafiko.
Visio 2010 (ter prejšnje verzije) omogoča branje in pisanje v datoteke s končnico VSD ali
VDX. VSD je lastniški binarni datotečni format, ki je uporabljen v vseh prejšnjih verzijah
orodja Visio. VDX je dobro dokumentiran format, ki temelji na XML shemi -
"DatadiagramML". Z verzijo Visio 2013 se je opustila podpora pisanja VDX datotek.
Pojavila sta se novejša formata VSDX in VSDM. Omenjena formata temeljita na skupini
XML datotek, ki so arhivirane znotraj ZIP datoteke. Razlikujeta se v tem, da datoteka
VSDM lahko vsebuje makroje. Slednja je še bolj dovzetna za varnost pred okužbami.
Tabela 2.5 zajema zbran nabor datotečnih formatov oziroma končnic, s katerimi se
srečamo ob uporabi orodja Visio. Vsaka kratica ima svoj pomen oziroma vsaki kratici
lahko podamo opis ali namen - katero področje informacij/podatkov hrani v datoteki.
Tabela 2.5: Microsoft Visio - pregled formatov
Kratica Opis
VSD Risanje (ang. drawing)
VSS Matrica, šablona (ang. stencil)
VST Predloga (ang. template)
VSW Spletna risba (ang. web drawing)
VDX Risanje - XML (ang. XML drawing) - ukinjena
VSX Matrica, šablona - XML (ang. XML stencil) - ukinjena
VTX Predloga - XML (ang. XML template) - ukinjena
vsdx Risanje - OPC/XML (ang. OPC/XML drawing)
vsdm Risanje (s podporo za makroje) - OPC/XML (ang.
OPC/XML drawing, macro-enabled)
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 43
Kratica Opis
vssx Matrica, šablona - OPC/XML (ang. OPC/XML stencil)
vssm Matrica, šablona (s podporo za makroje) - OPC/XML
(ang. OPC/XML stencil, macro-enabled)
vstx Predloga - OPC/XML (ang. OPC/XML template)
vstx Predloga (s podporo za makroje) - OPC/XML (ang.
OPC/XML template, macro-enabled)
VSL Dodatki (ang. add-on)
Če smo ustvarjeni model shranili v datoteko s končnico .vsd. Vsebina slednje uporabniku
ni berljiva - tako kot na primer XML dokument, kjer lahko direktno razberemo določene
informacije in podatke. VSD podatke shrani v obliki binarnih vrednosti. Koda 2.9
prikazuje zapis, če ničle in enice pretovorimo v HEX-a (šestnajstiško) obliko.
Koda 2.9: Primer vsebine VSD datoteke v HEX obliki
d0 cf 11 e0 a1 b1 1a e1 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 3e 00 03 00 fe ff 09 00 ................
06 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 ................
02 00 00 00 00 00 00 00 00 10 00 00 05 00 00 00 ................
01 00 00 00 fe ff ff ff 00 00 00 00 03 00 00 00 ................
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
Kot lahko vidimo na zgoraj prikazanem primeru, je takšen pogled na vsebino in hranjene
podatke precej nezanimiv. Če jih odpremo v orodju Visio pa dobimo grafično predstavitev
oziroma diagram, ki smo ga zmodelirali.
Zapis informacij in podatkov v obliki XML je bolj pregleden in lažje berljiv. Tudi velika
orodja, če se lahko tako izrazimo, se z novejšimi različicami poslužujejo tovrstnim
oblikam.
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 44
3 PREGLED OBSTOJEČIH RAZISKAV IZ PODROČJA
MEDOBRATOVALNOSTI MODELOV PROCESOV
Pomembnost sodelovanja, povezovanja in prenosa informacij se kaže na različnih
področjih. Pojem medobratovalnosti tako ni pomemben samo za podjetja, ki se nahajajo v
gospodarski panogi, temveč tudi za javni sektor, kar navaja Stojan Košti za področje e-
uprave [30]. Ker nas zanima predvsem področje modeliranja poslovnih procesov, smo
raziskavo in pregled literature omejili na to domeno. Raziskava nad BPMN notacijo in
medorodnostjo le te, ni prinesla večjega števila konkretnih zadetkov in informacij.
Zasledili smo nekatere sorodne članke in analize, ki so v sorodnih domenah [31]. Na tem
mestu lahko izpostavimo študijo Shefali Pawar [32], ki se je približala našemu delu.
Dokument vsebuje analizo treh orodij (različnih od teh, ki smo jih izbrali za naš
eksperiment), ki omogočajo modeliranje procesov. Študija je osredotočena na standard
BPMN 2.0 in podporo elementom, ki jo nudijo izbrana orodja, s ciljem izboljšati
meobratovalnost med njimi. Ugotovitve so podale, da za določene elemente sploh ni
podpore. Ne samo to, orodje je predlagalo ne standardizirano notacijo.
Pri pregledu literature oziroma obstoječih raziskav, smo bili pozorni tudi na področje
ocenjevanja prenosljivosti modelov oziroma elementov. Ocena kdaj bodo informacije
uspešno prenesene je subjektivna in načeloma odvisna od posamezne praktične rabe. Smo
pa zasledili vir v katerem so opredeljeni trije razredi. Silver v svoji knjigi BPMN method
and style [33] opisuje omenjene razrede. Slednje je predstavilo združenje WfMC (ang.
workflow management coalition) na področju prenosljivosti modela BPMN (ang. BPMN
model portability). Razredi so poimenovani: SIMPLE, STANDARD in COMPLETE - če
poskušamo imena razredov umesti v slovenski jezik, bi jih poimenovali kot: preprosto,
standardno in popolno. S tem ko orodje upošteva enega izmed razredov sklepamo, da
lahko orodje uvozi in razume vse dele serializirane BPMN instance [34]. Shapiro je v
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 45
sklopu študije bil osredotočen na prenosljivost modela v BPMN 1.1. Na podlagi le te je
definiral oziroma opredeli razrede in elemente tako:
Preprosti razred (ang. simple class)
Vključuje naslednje BPMN objekte oziroma elemente: opravilo, zaprt (ang.
collapsed) pod-proces, prehod (ekskluzivni, inkluzivni), začetni in končni element,
kjer tip ni definiran, bazeni, steze, podatkovni objekti, beležke/opombe, tok
zaporedja (nekontroliran, pogojni, privzeti).
Standardni razred (ang. standard class)
Vključuje naslednje elemente: opravilo (tip: človek, storitev, pošiljanje,
sprejemanje), odprt (ang. expanded) in zaprt pod-proces, zanke in aktivnosti z več
instancami, prehod (vzporedni, temelječi na dogodkih ali podatkih), začetni
element (tip: brez, sporočilo, časovnik), lovljenje vmesnih dogodkov v toku
zaporedja (časovnik, sporočilo), proženje vmesnih dogodkov v toku zaporedja
(sporočilo), priponka vmesnih dogodkov (časovnik, sporočilo, napaka), končni
elementi (tip: brez, napaka, sporočilo, prekinitev), bazeni, steze, podatkovni
objekti, beležke/opombe, tok zaporedja (nekontroliran, pogojni, privzeti),
asociacije.
Popolni razred (ang. complete class)
Vključuje vse tipe opravila, vse tipe dogodkov in vse tipe prehodov, ki so opisani v
notaciji BPMN 1.1, tok sporočila, transakcijske pod-procese in "ad-hoc" pod-
procese.
Ugotovimo lahko podobnosti ali enakosti z razredi skladnosti, ki so se pojavili pred
notacijo BPMN 2.0. Shapiro je s študijo in predstavitvijo razredov takrat podal dobro
izhodišče za področje prenosljivosti modelov BPMN. Danes pa so le ti, zaradi nadaljnjega
razvoja notacije BPMN, nekoliko nepopolni oziroma ne predstavljajo vseh elementov.
Spomnimo Shapiro je uporabljal različico BPMN 1.1, sedaj pa je na voljo 2.0. Nadgradnja
in dodelava razredov pa je bila zajeta v študijo, ki jo predstavi Shefali Pawar [32]. V študiji
so razredi definirani tako:
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 46
Preprosti razred
Vključuje naslednje BPMN elemente: opravilo (brez tipa), pod-proces, prehod
(ekskluzivni temelječ na podatkih, inkluzivni, vzporedni), dogodki (začetni in
končni brez tipa), bazen, steza, predmete (podatkovni objekt, beležka oziroma
opomba), tok zaporedja (nekontroliran, pogojni, privzeti), povezava elementov
(ang. link event pair).
Standardni razred
Nadgradnja preprostega razreda. Standardni razred vključuje vse elemente, ki so
navedeni v prejšnjem razredu. Dodatno pa vključuje še: opravilo (tip: človek,
storitev, pošiljanje, sprejemanje), zaprte in odprte pod-procese, zanke in aktivnosti
z več instancami, prehodi (ekskluzivni temelječ na dogodku), začetni element
(sporočilo, časovnik), lovljenje vmesnih dogodkov v toku zaporedja (časovnik,
sporočilo), proženje vmesnih dogodkov v toku zaporedja (sporočilo), priponka
vmesnih dogodkov, prekinitev (časovnik, sporočilo, napaka), končni dogodki
(napaka, sporočilo, prekinitev), predmeti (shranjevanje podatkov), tok sporočila.
Popolni razred
Predstavlja nadgradnjo preprostega in standardnega razreda. Vsebuje elemente iz
obeh razredov, hkrati pa vključuje še naslednje elemente:
o opravilo (tip: skripta (ang. script), poslovno pravilo (ang. business rule),
kompenzacija (ang. compensating)),
o pod-proces (klic akcije, ad-hoc, transakcijski),
o dogodkovne pod-procese (prekinitveni, ne-prekinitveni),
o bazen z več instancami (ang. multi-instance pool),
o prehod (kompleksni),
o začetni dogodek (signal, pogoj, večkratni, večkratni vzporedni),
o lovljenje vmesnih dogodkov v toku zaporedja (signal, večkratni, pogojni),
o proženje vmesnih dogodkov v toku zaporedja (stopnjevanje (ang.
escalation), signal, večkratni, kompenzacija),
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 47
o priponka vmesnih dogodkov, prekinitvena (stopnjevanje, signal, prekinitev,
večkratni, pogojni kompenzacija),
o priponka vmesnih dogodkov, ne-prekinitvena (sporočilo, časovnik,
stopnjevanje, signal, večkratna, pogojna),
o končni dogodek (signal, stopnjevanje, prekinitev).
V času pisanja magistrskega dela, smo naleteli tudi na vir, ki prihaja iz strani organizacije
OMG. Novejši vir je namenjen področju izmenjave modelov, ki so načrtovani ob
upoštevanju standarda BPMN [35]. Ker smo ocenili, da je področje relevantno za naše
raziskovalno področje, smo ga preverili in analizirali. Ugotovitve so podane v
nadaljevanju.
Organizacija OMG je ustvarila skupino BPMN MIWG. Slednja predstavlja nabor
strokovnjakov, ki se ukvarjajo s področjem izmenjave modelov. Poimenovanje skupine je
opredeljeno kot delovna skupina za izmenjavo BPMN modelov (ang. BPMN Model
Interchange Working Group). Primarni namen skupine je podpreti, olajšati in spodbujati
izmenjavo BPMN modelov. Vodilni je Denis Gagne iz podjetja Trisotech. Pripravili so
spletno stran, na kateri je naveden seznam orodij. Nad slednjimi opravljajo analize in teste
z vnaprej določenimi smernicami. Prav tako obstaja sekcija, ki dopušča možnost navajanja
napak oziroma ugotovitev in podajanja vprašanj. Omenjeno sekcijo bi lahko primerjali s
spletnim forumom. Ob analizi spletnega mesta, smo prišli do ugotovitev, da informacije
oziroma sam vir, ni neposredno povezan z našim delom. Ker posredna povezava s
področjem v katerem raziskujemo vendarle obstaja, ocenjujemo, da je vredno omembe.
Ugotovili smo, da je vir uporaben za različne skupine ljudi oziroma strokovnjakov.
Informacije, ki se pojavijo na spletnem mestu, so naravnane predvsem v področje izvajanja
modelov oziroma omenjenemu področju relevantnih podatkov. Zasledili smo predvsem
poročanja o napakah v sintaksi in semantiki (na primer: nepotrebno podvajanje zapisa ID v
datoteki, ki je nastala ob shranitvi ustvarjenega modela). Ocenjujemo, da bodo uporabne
informacije predvsem našli ustvarjalci in razvijalci posameznih orodij - v kolikor se orodje
nahaja na seznamu tistih, ki jih je skupina vključila v svoje delo. Slednji bodo prišli do
informacij kje se še nahajajo pomanjkljivosti. Prav tako načrtovalcem izvedljivih modelov,
kateri morajo poskrbeti, da je sintaksa in semantika pravilna (na primer: reference kažejo
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 48
na prava mesta). Vir pa bo v pomoč tudi tistim, ki so odkrili napako in potrebujejo
alternativno rešitev v svojem modelu, da se bo slednji kljub temu lahko izvedel. Slednjim
bo spletno mesto predstavljajo stran, za navajanje problematik in reševanje le teh.
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 49
4 NAČRTOVANJE IN IZVEDBA EKSPERIMENTA
V sklopu magistrskega dela smo izvedli eksperiment. Poglavje opisuje izhodiščno stanje
preden smo začeli izvajati omenjen eksperiment, kot tudi izvedbo le tega.
V prvi fazi je izbira in vzpostavitev programskega okolja. Potrebno je pridobiti in namestiti
programske rešitve oziroma orodja, ki jih za izvedbo eksperimenta potrebujemo. Omenjena
orodja, ki smo jih izbrali ter jih potrebujemo za delo, so predstavljena v poglavju
Predstavitev izbranih orodij.
Sledi poglavje (Analitični pregled izbranih orodij in njihova podprtost elementov) v
katerem predstavimo analizo oziroma pregled, ki smo ga opravili nad izbranimi orodji.
Analitičen pregled nam je dal določeno začetno sliko, katera nam je že podala nekaj
koristih informacij in ugotovitev.
Poglavje Predstavitev izhodiščnih modelov zajema predstavitev modelov s katerimi bomo
izvedli naš eksperiment. Slednje bomo ustvarili in izmenjali med izbranimi orodji.
Sledita poglavji, ki vsebujeta informacije o postopku izvedbe eksperimenta (Definiranje
postopka izvedbe) in načinu podajanja ocene (Ocenjevalni kriteriji).
V zadnjem delu poglavja smo eksperiment izvedli in sproti podajali ugotovitve, ter
izpostavili tiste dele, za katere ocenjujemo, da jih je smotrno izpostaviti ali omeniti
(Izvedba eksperimenta oziroma pridobivanje rezultatov).
4.1 Predstavitev izbranih orodij
Na tržišču je dandanes na voljo veliko različnih orodij, ki so namenjena načrtovanju
modelov. Na področju načrtovanja poslovnih procesov tako zasledimo rešitve, ki so
namenjene modeliranju osnovnejših procesov oziroma manj profesionalni rabi, kot tiste, ki
so namenjene profesionalni rabi oziroma so primerne za večje inštitucije in podjetja.
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 50
Nemogoče, še bolj pa nesmiselno je testirati in uporabiti vsa orodja, zato smo prisiljeni
sprejeti določene omejitve. V sklopu izbire orodij smo tak sprejeli naslednje omejitve
oziroma smo izbrali rešitve, ki ustrezajo spodaj navedenim pogojem:
Podpira modeliranje procesov z uporabo notacije BPMN 2.0.
Orodje nam je dosegljivo. To pomeni, da je uporaba rešitve brezplačna ali pa je
plačljiva, vendar omogoča brezplačno preizkušanje orodja (lahko tudi za samo
določeno časovno obdobje).
Jezik orodja je slovenščina ali angleščina.
Starost zadnje različice oziroma verzije orodja je 3 leta ali manj. S tem smo nekako
izluščili aktivne rešitve (tudi sodobnejše) od tistih, katerih razvoj se je ustavil.
Omogoča uvoz ali izvoz (shranitev) v BPMN formatu.
S področja načrtovanja procesov imamo kar nekaj izkušenj. Na podlagi tega poznamo tudi
nekaj primernih orodij. Slednja smo že uporabljali, zato smo seznanjeni z delovanjem in
upravljanjem le teh. Ker so nam te rešitve bližnje, iz vidika izkušenj s posameznim
orodjem, smo te dali v ospredje in eksperiment pričeli izvajati na njih.
4.1.1 Signavio
Ime predstavlja podjetje, ki je proizvajalec programske opreme in ima sedeže v Nemčiji in
Kaliforniji [36]. Primarna usmeritev njihovih programskih rešitev so orodja, na področju
upravljanja poslovnih procesov (ang. business process management - BPM).
Njihov glavi produkt je orodje Signavio Proces Editor (Slika 4.1). Slednje predstavlja
spletni urejevalnik oziroma orodje, ki omogoča modeliranje poslovnih procesov. Maja
2009 predstavljeno orodje, uporabniku omogoča ustvarjanje diagramov procesa na podlagi
notacije BPMN. Orodje se lahko uporablja v dveh oblikah oziroma na dva načina [37]:
1. Software as a Service (SaaS) - Ni potrebne namestitve. Do orodja se dostopa preko
spleta, saj gre za oblačno storitev. Za dostop do orodja potrebujete spletni
brskalnik.
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 51
2. On-Premise - Strežniška komponenta se namesti na strežnik podjetja. Ta način
omogoča popolni sistemski nadzor. V tem primeru lahko za dostop do orodja
namestimo programsko opremo na posamezni računalnik, ni pa pogoj.
Slika 4.1: Grafični vmesnik orodja: Signavio
Poleg lastnosti, ki smo jih že omenili, orodje omogoča oziroma ima značilnosti:
Modeliranje procesa z uporabno grafičnega urejevalnika in načina QuickModel -
način urejevanja procesa, ki je usmerjen v obliko preglednic (ang. spreadsheet-
oriented).
Simulacija procesa (ang. simulation of process) s katero lahko ugotovimo ozka
grla ali pa lahko ocenimo alternative.
Skladišče modelov (ang. model repository) za gradnjo več-nivojskih procesnih
arhitektur, upravljanje različic in ponovna uporaba predmetov.
Funkcije sodelovanja za izmenjavo diagramov procesa, zbiranje povratnih
informacij in uveljavljanje odobritvenih delovnih tokov (ang. approval workflows).
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 52
Objava dokumentacije procesa ob uporabi mehanizmov poročanj in integriranega
portala procesa.
V nadaljevanju se bomo z besedo Signavio sklicevali na orodje. Ker je orodje izpolnjevalo
vse potrebne pogoje iz poglavja 4.1, hkrati pa imamo že nekaj izkušen iz uporabe le tega,
smo slednjega uvrstili na seznam izbranih orodij za izvedbo eksperimenta.
4.1.2 Yaoqiang BPMN Editor
Yaoqiang BPMN Editor (v nadaljevanju tudi YBE) predstavlja odprtokodno orodje, ki ga
poznamo tudi pod oznako YBE. Grafični urejevalnik (Slika 4.2) omogoča ustvarjenje
diagrame poslovnih procesov [38]. Podpira standard BPMN 2.0 ob upoštevanju
specifikacij s strani OMG.
Ena izmed prednosti orodja je preprosta vzpostavitev. Orodja namreč ni potrebno
nameščati (izvesti instalacije), vendar da pa bi le to delovalo moramo poskrbeti, za
predhodno namestitev JRE (ang. java runtime environment) ali JDK (ang. java
development kid).
Izpostavimo nekaj glavnih lastnosti [39]:
Namestitev v obliki instalacije programske opreme ni potrebna.
Hitro in enostavno ustvarjanje, pregled, urejanje in simulacija poslovnih procesov.
Celotna podpora BPMN 2.0 diagramom. Uvoz/izvoz OMG BPMN 2.0 datotek.
Sprotna (ang. real-time) validacija BPMN sintakse.
Avtomatsko generiranje informacij BPMN 2.0 Diagram Interchange.
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 53
Slika 4.2: Grafični vmesnik orodja: Yaoqiang BPMN Editor
Uporabniški vmesnik (Slika 4.2) ne daje vtisa sodobne in moderne aplikacije. Iz vidika
dizajna in grafične predstavitve, orodje deluje precej robustno in nekoliko staromodno.
Kljub temu pa lahko povemo, da se uporabnik hitro znajde in hitro osvoji pregled na
funkcionalnostmi. Orodje omogoča tudi direktni preklop med diagramom v grafični obliki
in izvorno kodo diagrama - lastnost, ki se nam jo je zdelo vredno izpostaviti.
4.1.3 Activiti (BPM Platform)
Predstavlja platformo (v nadaljevanju poimenovano tudi kot orodje) za upravljanje
delovnih tokov in poslovnih procesov [40]. Ciljna publika so osebe na področju
poslovanja, razvijanja in sistemske administracije. Jedro predstavlja BPMN 2 "procesni
motor" (ang. process engine), ki temelji na Javi. Activiti je odprtokoden in distribuiran pod
licenco Apache. Možno ga je uporabiti na bilo katerem strežniškem ali oblačnem sistemu,
ki podpira Java aplikacije.
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 54
Začetki segajo nazaj do marca 2010, ko sta razvijalca jBPM, Tom Baeyens in Joram
Barrez, odločila zapustiti Red Hat in pričela razvijati Activiti kot uslužbenca podjetja
Alfresco. Rešitev je nastala na podlagi njunih izkušenj z razvijanjem delovnih tokov pri
jBPM. Povsem novo orodje, z novo kodo, je prišlo na tržišče z verzijo 5.0. Na ta način sta
sporočila, da gre za nadaljevanje njunega dela. Dejali bi lahko, da je predhodnik tedaj na
novo nastalega Activiti 5.0 orodje jBPM in vse različice od 1 do 4 [41].
Slika 4.3: Grafični vmesnik - Activiti Modeler
Slika 4.3 predstavlja grafični vmesnik orodja. Kot je razvidno gre za podoben dizajn, ki ga
ponuja Signavio. Že ob prvem pregledu smo dobili vtis o manjši podpori elementov.
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 55
Slednje smo tudi potrdili ob analitičnem pregledu podprtosti, kar lahko preberete v
nadaljevanju.
4.2 Analitični pregled izbranih orodij in njihova podprtost elementov
Pred izvedbo eksperimenta smo opravili analitični pregled izbranih orodij. Tovrstno
opravilo je smiselno opraviti, saj lahko hitro dobimo določeno predstavo. Pregled bi lahko
opravili preden bi namestili posamezno orodje. V tem primeru bi izvedli pregled literature
in se zgolj zanašali na navedbe v dokumentaciji. Ker pa vemo, da dokumentacija in opis
orodja v veliko primerah ni popolna oziroma podrobna, je smiselno analizo opravljati
vzporedno z praktičnim preizkusom na orodju. Omenjeno metodo smo uporabili pri
analitičnem pregledu izbranih orodij, pri čemer nas je predvsem zanimala njihova
podprtost elementov notacije BPMN 2.0. Seznam oziroma nabor posameznih elementov,
ki so del notacije (ali jih zasledimo pri modeliranju z omenjeno notacijo), smo pridobili iz
posterja BPMN 2.0 [42].
Na podlagi pridobljenih informacij in ugotovitev smo oblikovali tabelo. Tabela 4.1
prikazuje seznam elementov in njihovo grafično predstavitev. Stolpec levo predstavlja
pod-razred, v katerega spada element (predstavljeno v poglavju 2.3.5). Elementi pri katerih
so celice prazne, so del popolne BPMN skladnosti (ang. BPMN complete conformance).
Seveda pa v popolno skladnost spadajo tudi vsi preostali navedeni elementi. Desno se
nahajajo stolpci, ki predstavljajo posamezno izbrano orodje. Polni krogci označujejo
podporo določenega elementa v določenem orodju.
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 56
Tabela 4.1: Rezultati analitičnega pregleda izbranih orodij
Pod-razred Tip elementa Grafična
predstavitev Signavio
Yaoqiang
BPMN
Editor
Activiti
Modeler
Začetni dogodki
(ang. start events)
Standardni (ang.
standard)
Opisni,
analitični,
skupno
izvedljivi
Start (ang. general -
type = none) • • •
Opisni,
analitični,
skupno
izvedljivi
Sporočilo (ang.
message) • • •
Opisni,
analitični
Časovnik (ang.
timer) • • •
Analitični Pravilo (ang. rule)
• •
Analitični Signal (ang. signal)
• •
Večkratno (ang.
multiple) • •
Večkratno
vzporedno (ang.
parallel mutiple)
• •
Prekinitveni za pod-
proces (ang. event
sub-process
interrupting)
Sporočilo (ang.
message) •
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 57
Časovnik (ang.
timer) •
Eskalacija (ang.
escalation) •
Pravilo (ang. rule)
•
Napaka (ang. error)
•
Kompenzacija (ang.
compensation) •
Signal (ang. signal)
•
Večkratno (ang.
multiple) •
Večkratno
vzporedno (ang.
parallel mutiple)
•
Ne prekinitveni za
pod-proces (ang.
event sub-process
non-interrupting)
Sporočilo (ang.
message) • •
Časovnik (ang.
timer) • •
Eskalacija (ang.
escalation) • •
Pravilo (ang. rule)
• •
Signal (ang. signal)
• •
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 58
Večkratno (ang.
multiple) • •
Večkratno
vzporedno (ang.
parallel mutiple)
• •
Vmesni dogodki
(ang. intermediate
events)
Lovljenje (ang.
catching)
Analitični,
skupno
izvedljivi
Sporočilo (ang.
message) • • •
Analitični,
skupno
izvedljivi
Časovnik (ang.
timer) • • •
Analitični Pravilo (ang. rule)
• •
Analitični Povezava (ang.
link) • •
Analitični Signal (ang. signal)
• • •
Večkratno (ang.
multiple) • •
Večkratno
vzporedno (ang.
parallel mutiple)
• •
Mejni
(prekinitveni) (ang.
boundary
interrupting)
Analitični Sporočilo (ang.
message) • •
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 59
Analitični Časovnik (ang.
timer) • • •
Eskalacija (ang.
escalation) • •
Analitični Pravilo (ang. rule)
• • •
Analitični,
skupno
izvedljivi
Napaka (ang. error)
• •
Preklic (ang.
cancel) •
Kompenzacija (ang.
compensation) • •
Analitični Signal (ang. signal)
• • •
Večkratno (ang.
multiple) • •
Večkratno
vzporedno (ang.
parallel mutiple)
• •
Mejni (ne-
prekinitveni) (ang.
boundary non-
interrupting)
Analitični Sporočilo (ang.
message) • •
Analitični Časovnik (ang.
timer) • •
Analitični Eskalacija (ang.
escalation) • •
Analitični Pravilo (ang. rule)
• •
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 60
Analitični Signal (ang. signal)
• •
Večkratno (ang.
multiple) • •
Večkratno
vzporedno (ang.
parallel mutiple)
• •
Proženje (ang.
throwing)
Start (ang. general -
type = none) • • •
Analitični,
skupno
izvedljivi
Sporočilo (ang.
message) • •
Analitični Eskalacija (ang.
escalation) • •
Analitični Povezava (ang.
link) • •
Kompenzacija (ang.
compensation) • •
Analitični Signal (ang. signal)
• • •
Večkratno (ang.
multiple) • •
Končni dogodki
(ang. end events)
Standardni (ang.
standard)
Opisni,
analitični,
skupno
izvedljivi
Standardni (ang.
general - none) • • •
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 61
Opisni,
analitični,
skupno
izvedljivi
Sporočilo (ang.
message) • •
Analitični Eskalacija (ang.
escalation) • •
Analitični Napaka (ang. error)
• • •
Preklic (ang.
cancel) •
Kompenzacija (ang.
compensation) • •
Analitični Signal (ang. signal)
• •
Večkratno (ang.
multiple) • •
Opisni,
analitični,
skupno
izvedljivi
Prekinitev (ang.
terminate) • •
Aktivnosti (ang.
activities)
Opisni,
analitični Opravilo (ang. task)
• •
Tipi opravila (ang.
task types)
Analitični Pošiljanje (ang.
send task) • • •
Analitični Prejemanje (ang.
receive task) • • •
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 62
Opisni,
analitični,
skupno
izvedljivi
Človeško opravilo
(ang. user task) • • •
Ročno (ang. manual
task) • • •
Poslovno pravilo
(ang. business rule
task)
• • •
Opisni,
analitični,
skupno
izvedljivi
Storitev (ang.
service task) • • •
Skripta (ang. script
task) • • •
Transakcija (ang.
transaction)
• •
Dogodkovni pod-
proces (ang. event
sub-process)
• • •
Opisni,
analitični,
skupno
izvedljivi
Klic aktivnosti
(ang. call activity)
• • •
Opisni,
analitični,
skupno
izvedljivi
Pod-proces
(razširjeni) (ang.
expanded
subprocess)
•
Opisni,
analitični
Pod-proces (zaprti)
(ang. collapsed
subprocess)
• • •
Oznake za
aktivnosti (ang.
activity markers)
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 63
Pod-proces (ang.
sub-process
marker)
• • •
Analitični Ponovitev (ang.
loop marker) • • •
Analitični
Zaporedni (ang.
sequential mi
maker)
• • •
Analitični Vzporedni (ang.
parallel mi maker) • • •
Ad-hoc (ang. ad
hoc maker) • •
Kompenzacija (ang.
compensation
maker)
• • •
Tok (ang. flow)
Opisni,
analitični,
skupno
izvedljivi
Zaporedni tok (ang.
sequence flow) • • •
Analitični,
skupno
izvedljivi
Privzeti tok (ang.
default flow) •
Analitični,
skupno
izvedljivi
Pogojni tok (ang.
conditional flow) • •
Opisni,
analitični
Tok sporočila (ang.
message flow)
• •
Opisni,
analitični,
skupno
izvedljivi
Podatkovna
asociacija (ang. data
association)
• • •
Prehodi (ang.
gateways)
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 64
Opisni,
analitični,
skupno
izvedljivi
Ekskluzivni (ang.
exclusive) • • •
Analitični,
skupno
izvedljivi
Dogodkovni (ang.
event-based) • •
Opisni,
analitični,
skupno
izvedljivi
Vzporedni (ang.
parallel) • • •
Analitični Inkluzivni (ang.
inclusive) • • •
Kompleksni (ang.
complex) • •
Analitični
Dogodkovno
ekskluzivni (ang.
exclusive event-
based)
• •
Dogodkovno
vzporedni (ang.
parallel event-
based)
• • •
Steze (ang.
swimlanes)
Opisni,
analitični Bazen (ang. pool)
• •
Opisni,
analitični Steza (ang. lane)
• •
Pogovori (ang.
conversations)
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 65
Pogovor (ang.
conversation) •
Klic pogovora (ang.
call conversation)
•
Pogovorna
povezava (ang.
conversation link)
•
Podatki (ang. data)
Opisni,
analitični,
skupno
izvedljivi
Podatkovni objekt
(ang. data object)
• •
Zbirka podatkovnih
objektov (ang.
collection data
object)
• •
Podatkovni vhod
(ang. data input)
• •
Podatkovni izhod
(ang. data output)
• •
Opisni,
analitični
Podatkovna
shramba (ang. data
store)
• •
Koreografije (ang.
choreographies)
Koreografija -
opravilo (ang.
choreography task)
•
Pod-koreografija
(ang. sub-
choreography)
•
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 66
Klic koreografije
(ang. call
choreography)
•
Predmeti (ang.
artifacts)
Opisni,
analitični
Skupina (ang.
group)
• •
Opisni,
analitični,
skupno
izvedljivi
Tekstovna
pripomba (ang. text
annotation)
• • •
V nadaljevanju ugotovitve in rezultate, ki smo jih pridobili na podlagi analitičnega
pregleda, predstavljamo nekoliko drugače. Gledalec oziroma bralec lažje razume
informacije, če so slednje predstavljene v obliki sličic, grafik itd. Zaradi boljšega pregleda
nad zbranimi informacijam, smo opravili statistično analizo in zbrane ugotovitve podali v
grafični obliki.
Graf 4.1 prikazuje, kako dobro so izbrana orodja nudila podporo elementov iz posamezne
skupine. Pričnimo pri podpori dogodkovnim elementom. Začetne dogodke, vmesne
dogodke in končni dogodke orodja podpirajo različno. Kot lahko razberemo iz podatkov,
orodje Signavio nudi polno podporo. Omenjeno orodje ima najboljšo podporo, saj
preostala dva določenih elementov ne podpirata. Orodje Signavio nudi 100% podporo
vsem elementom, ki smo jih navedli v sklopu posamezne skupine. To pomeni, da se
omenjeni elementi v orodju nahajajo in jih lahko uporabimo pri načrtovanju modelov.
Glede na stopnjo podprtosti se na drugem mestu nahaja orodje YBE. Slednje sicer v skupini
končni dogodki nudi podporo vsem elementom, ki se v skupini nahajajo. Do odstopanj pa
je prišlo v preostalih dveh skupinah. Elemente iz skupine začetni dogodki podpira približno
60,87%, med tem ko elemente iz skupine vmesni dogodki podpira 96,78%. Najslabše se je
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 67
odrezalo orodje Activiti. Elemente iz skupine začetni dogodki podpira 13,04%, iz skupine
vmesni dogodki 25,81% in elemente iz skupine končni dogodki 22,22%.
Orodja so se v skupini aktivnosti odrezala bolje. Signavio omogoča uporabo vseh
elementov, zato ima vrednost 100%. Orodje YBE uporabo enega elementa ni omogočalo in
tako podpira 94,74% elementov glede na celotni nabor le teh. Activiti podpira 84,21% vseh
elementov, kar pomeni da omogoča uporabo 16 elementov od 19.
V Tabela 4.1 smo opredelili pet elementov iz skupine tok. Signavio podpira vseh pet
elementov (100%), YBE štiri od petih (80%) in Activiti dva od petih (40%).
Orodji Signavio in YBE sta nudili dobro podporo elementom, ki skrbijo za prehod oziroma
predstavljajo odločitvene točke. Izmed sedmih elementov sta omogočali uporabo vseh
sedmih. Activiti je nudil približno 57,14% podporo, kar pomeni, da je omogočil uporabo
štirih elementov.
Graf 4.1 prav tako prikazuje podporo elementov iz skupine steze. Med tem, ko sta Signavio
in YBE podprla oba elementa iz skupine, orodje Activiti ni podprlo nobenega. Slednje je
dokaj zanimivo, saj če bi razmišljali kot navadni uporabnik, bi najverjetneje pričakovali, da
vsa orodja omogočajo elemente iz te skupine.
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 68
Graf 4.1: Podpora izbranih orodij elementom določene skupine
23
31
9
19
5
7
2
3
5
3
2
3
8
2
16
2
4
0
0
0
0
1
14
30
9
18
4
7
2
3
5
3
2
23
31
9
19
5
7
2
0
5
0
2
Začetni dogodki
Vmesni dogodki
Končni dogodki
Aktivnosti
Tok
Prehodi
Steze
Pogovori
Podatki
Koreografija
Predmeti
Začetnidogodki
Vmesnidogodki
Končnidogodki
Aktivnosti
Tok Prehodi Steze Pogovori PodatkiKoreogr
afijaPredmet
i
Signavio 23 31 9 19 5 7 2 0 5 0 2
YBE 14 30 9 18 4 7 2 3 5 3 2
Activiti 3 8 2 16 2 4 0 0 0 0 1
Skupaj 23 31 9 19 5 7 2 3 5 3 2
Podpora elementom določene skupine
Signavio YBE Activiti Skupaj
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 69
Elemente iz skupine pogovori je omogočilo orodje YBE. Podprlo je nabor vseh elementov,
ki smo jih v sklopu omenjene skupine zajeli. Nasprotne rezultate pa sta podala preostala
dva orodja. Signavio in Activiti nista omogočila uporabe nobenega elementa iz te skupine.
Skupina podatki vsebuje nabor elementov, ki omogočajo pretok in prenos različnih
informacij, ter zapis le teh. Orodji Signavio in YBE sta omogočili uporabo vseh petih
elementov. Activiti pa s svojim vmesnikom za modeliranje procesov, ni omogočil
vključitve nobenega izmed elementov, ki se nahajajo v prej omenjeni skupini.
Elemente, ki spadajo v skupino koreografija, je orodje YBE podprlo in omogočilo uporabo.
Preostala dva orodja nista omogočila uporabo nobenega.
Število elementov iz skupine predmeti je različno. Orodja lahko omogočajo uporabo in
definiranje lastnih elementov. Na podlagi tega dejstva, ne moremo fiksno definirati nabora
gradnikov, ki jih lahko uporabimo pri načrtovanju. Graf 4.1 ponazarja informacijo o
podpori elementom, ki smo jih navedli v Tabela 4.1. Orodja so slednje podprla dobro.
Signavio in YBE v celoti. Activiti ni omogočil uporabe enega elementa.
Skozi grafe smo predstavili podporo elementom iz določene skupine. V nadaljevanju pa je
prikazan splošni pregled. Slednji nam poda boljši pregled nad celoto. Lahko bi dejali, da na
podporo elementom gledamo iz bolj oddaljene perspektive.
Graf 4.2: Podpora (število elementov) izbranih orodij glede na skupno število elementov
103 97
36
109 109 109
Signavio YBE Activiti
Podpora orodja Skupaj elementov
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 70
Graf 4.2 informacije poda v obliki število podprtih elementov glede na skupno število
elementov. Graf 4.3 pa nam omenjene podatke prikaže v obliki deleža.
Ugotovimo, da se je orodje Signavio, ob analitičnem pregledu izbranih orodij, izkazalo za
najboljšega oziroma najuspešnejšega. Glede na nabor elementov, ki smo jih zajeli, je
orodje podprlo 94,50% elementov glede na celotno število le teh. Ocenjujemo, da gre za
kar dober rezultat. Preostala dva orodja sta se odrezala slabše. YBE je omogočal uporabo
88,99% elementov. Veliko slabše pa se je odrezalo orodje Activiti, ki je omogočalo
uporabo približno 33% elementov. Slednje je bilo mogoče pričakovati, saj bi lahko dejali,
da je orodje bolj primerno kadar je procese oziroma modele potrebno izvajati.
Graf 4.3: Podpora (delež glede na celoto) izbranih orodij glede na skupno število elementov
4.3 Predstavitev izhodiščnih modelov
Za potrebe eksperimenta smo pripravili modele (v nadaljevanju poimenovani tudi kot
diagrami). Ti se razlikujejo predvsem glede na izhodiščno stanje. Posledično to prinaša
94,50%
88,99%
33,03%
0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
100,00%
Signavio 94,50%
YBE 88,99%
Activiti 33,03%
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 71
razliko v obsežnosti in kompleksnosti elementov (število vključenih elementov v sam
diagram). Diagrame smo poimenovali oziroma opredelili kot:
Model 1 (M1) - nabor skupnih elementov, pri čemer model oblikujemo v orodju
Signavio.
Model 2 (M2) - nabor skupnih elementov, pri čemer model oblikujemo v orodju
YBE.
Model 3 (M3) - nabor skupnih elementov, pri čemer model oblikujemo v orodju
Activiti.
Za boljši pregled in lažje razumevanje, bomo opredelili oziroma določili še slednje:
M1, M2 in M3 vedno predstavlja izhodiščni model oziroma model, ki smo ga
ustvarili v orodju Signavio (M1), YBE (M2) in Activiti (M3).
Novonastali model je tisti model, ki je nastal ob uvozu izhodiščnega modela v
določeno orodje. Da se ne bomo ponavljali, ga bomo poimenovali tudi v povezavi z
orodjem npr: M1 v YBE (model M1 smo uvozili v orodje YBE).
Z omenjenimi modeli poskušamo pridobiti odgovore na vprašanja, ki smo si jih postavili v
sklopu magistrskega dela. V nadaljevanju so prikazani in predstavljeni posamezni modeli.
Predvidevamo različna izhodiščna stanja, saj smo ob analitičnem pregledu ugotovili
različno podporo elementom.
Z izvedbo eksperimenta bomo preverili ali je izmenjava slednjih mogoča in do kakšne
mere. Diagrami M1, M2 in M3 zajemajo elemente, ki naj bi bili skupni vsem orodjem.
Pomensko ne predstavljajo realnega procesa in ne predstavljajo semantične pravilnosti.
Takšnim procesom ne prepisujemo praktične uporabne vloge, saj jih ni mogoče (smiselno)
vpeljati v podjetje ali organizacijo.
4.3.1 Model 1
Slika 4.4 predstavlja diagram M1, ki smo ga ustvarili v orodju Signavio.
M1 skupno vsebuje oziroma zajema:
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 72
35 elementov,
26 povezav,
31 poimenovanih elementov in
2 poimenovani povezavi.
Slika 4.4: Model M1
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 73
4.3.2 Model 2
Slika 4.5 predstavlja diagram M2, ki smo ga ustvarili v orodju YBE.
M2 skupno vsebuje oziroma zajema:
34 elementov,
22 povezav,
31 poimenovanih elementov in
1 poimenovano povezavo.
Slika 4.5: Model M2
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 74
4.3.3 Model 3
Slika 4.6 predstavlja diagram M3, ki smo ga ustvarili v orodju Activiti.
M3 skupno vsebuje oziroma zajema:
33 elementov,
23 povezav,
29 poimenovanih elementov in
1 poimenovano povezavo.
Slika 4.6: Model M3
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 75
4.4 Definiranje postopka izvedbe
Preden pričnemo opravljati delo, izvajati nalogo, ustvariti produkt itd. je smiselno narediti
načrt. Slednji nam predstavlja proces dela oziroma postopek kako bomo nekaj opravili. V
nadaljevanju je predstavljen načrt priprave in izvedbe eksperimenta za naše delo.
Predstavljen je v obliki točk, ki smo jih poimenovali koraki eksperimenta. Namen je
zabeležiti in definirati grobe korake, s katerim bomo prišli do ugotovitev, ki so tudi
predstavljene v nadaljevanju.
Koraki eksperimenta
1. Vzpostavitev delovnega okolja oziroma programskih orodij.
Pregled literature, ki je pomembna za naše področje (poglavje 2).
Namestitev in priprava programskih rešitev oziroma orodij, ki jih bomo
uporabili (poglavje 4.1).
2. Definiranje izhodiščnega stanja in priprava začetnih podatkov.
Opravimo različne preglede in analize, da dobimo nabor izhodiščnih
podatkov oziroma prvo izhodiščno sliko (lahko rečemo prve ugotovitve)
(poglavje 4.2).
Na podlagi prvih ugotovitev ustvarimo procese oziroma modele, ki jih
bomo uporabili pri eksperimentu (poglavje 4.3).
3. Uporaba programskega orodja, modeli procesov in obdelava.
Uporaba izbranega programskega orodja.
Načrtovanje oziroma vpeljava modela procesa v izbrano orodje.
Shranjevanje (izvoz modela) v datoteko.
4. Analiza stanja.
Ugotovitve do katerih smo prišli ob samem načrtovanju - vpeljavi modela v
izbrano orodje.
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 76
Analiza ustvarjene datoteke, ki je nastala ob shranjevanju modela.
5. Ugotovitve ob zaključku.
Beleženje ugotovitev ob zaključku.
Primerjava rezultatov na izhodu.
Prednosti, slabosti, izgube itd.
Če navedene točke, s katerimi smo opredelili korake eksperimenta, povzamemo in
razložimo. Za potrebe eksperimenta je potrebno poznati področje v katerem delujemo. Da
se srečamo s vsemi potrebnimi informacijami, moramo opraviti pregled literature in orodij,
kar povzemamo s točko 1. To ni dovolj za pričetek izvedbe eksperimenta. Potrebno je
definirati izhodiščno stanje (točka 2). Običajno že pred samim eksperimentom izvemo
veliko informacij oziroma pridobimo veliko odgovorov. Slednje lahko potrdimo, saj smo
tudi sami ob analitičnem pregledu dobili dobro predstavitev, kaj lahko pričakujemo pri
izvajanju eksperimenta (poglavje 4.2).
Lahko bi dejali, da v točki 3 pričnemo dejansko izvajati eksperiment. S pod koraki smo
dodatno razdelili opravila oziroma postopek. Najprej izberemo začetno - izhodiščno
programsko orodje. Izberemo takšnega, ki ima najboljšo podporo. V našem primeru je
smiselno, saj slednji podpira vse (pomembne) elemente, ki jih tudi preostala izbrana
orodja. Tako bomo lažje ujeli tiste elemente, ki jih določeno orodje ni podprlo. Vpeljani
oziroma ustvarjeni model shranimo v datoteko, ki jo orodje podpira in jo lahko uvozimo v
naslednjo orodje. Uspešnost uvoza in beleženje ugotovitev, smo zajeli v točki 4. V tem
koraku tudi preverjamo zgradbo datoteke. Izpostavimo strukturo, določene značke in
vrednosti. Ob zaključku eksperimenta (točka 5) pa opravimo splošen pregled oziroma
interpretiramo rezultate in ugotovitve. Na tem mestu opravimo tudi različne primerjave,
podamo kakšne predloge itd.
Posebno obliko eksperimenta bomo izvedli tako, da bomo izvedli vse možne kombinacije
in tako preverili možnost izvoza modela in možnost uvoza. Slika 4.7 prikazuje kateri
modeli so povezani, s posameznimi izbranimi orodji. Tako na primer ugotovimo, da z
modelom M1 in M2 delujemo znotraj orodij Signavio in YBE. Razlika pri omenjenih
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 77
modelih je ta, da smo prvega oblikovali v orodju Signavio, med tem, ko smo drugega v
YBE. Tako imamo različno postavljena izhodišča oziroma izhodiščna okolja.
Slika 4.7: Prikaz relacij uporabljenih modelov v izbranih orodij
4.5 Ocenjevalni kriteriji
Poglavje navaja in opisuje kriterije oziroma postavke, po katerih bomo ocenjevali
uspešnost uvoza modela v orodje. Pri določitvi le teh smo strmeli k objektivnosti. Ker
subjektivni kriteriji nimajo takšne teže, smo jih izpustili oziroma smo jih poskušali
minimalno vključiti.
Pri analizi in preverjanju uspešnosti uvoza modela, bomo preverjali kriterije, ki smo jih
opredelili v naslednjih točkah.
1. Število elementov
Koliko izmed vseh elementov se je preneslo v orodje. Vrednost je predstavljena v
obliki števila, ki predstavlja delež elementov, ki se pojavijo v modelu, ki je nastal
ob uvozu, glede na izhodiščni model. Primer: 6 od 10-ih elementov se pojavi v
novonastalem modelu.
2. Število povezav
Koliko izmed vseh povezav med elementi se je preneslo v orodje. Vrednost je
predstavljena v obliki števila, ki predstavlja delež elementov, ki se pojavijo v
modelu, ki je nastal ob uvozu, glede na izhodiščni model. Primer: 6 od 10-ih
povezav se pojavi v novonastalem modelu.
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 78
3. Oblika elementov
Koliko izmed vseh elementov je ohranilo enako obliko. Preverja se ali je prišlo do
pomanjšanja ali povečanja oblike elementa. Vrednost je predstavljena v obliki
števila, ki predstavlja delež elementov, ki se pojavijo v modelu, ki je nastal ob
uvozu, glede na izhodiščni model in so ohranili enako obliko. Primer: 6 od 10-ih
elementov je ohranilo enako obliko v novonastalem modelu.
4. Oblika povezav
Koliko izmed vseh povezav je ohranilo enako obliko. Preverja se ali je prišlo do
razlik pri povezavi med elementi. Ali povezave vsebujejo enake lome, dolžino itd.
Vrednost je predstavljena v obliki števila, ki predstavlja delež povezav, ki se
pojavijo v modelu, ki je nastal ob uvozu, glede na izhodiščni model in so ohranile
enako obliko. Primer: 6 od 10-ih povezav je ohranilo enako obliko v novonastalem
modelu.
5. Poimenovanje elementov
Koliko elementov je ohranilo enako poimenovanje (oznaka oz. label se mora
nahajati zraven elementa). Preverja se ali je prišlo do napak ali razlik pri
poimenovanju elementov. Ali je zapis oblikovan enako (mala oziroma velika
tiskana pisava) ali so črke izpuščene itd. Vrednost je predstavljena v obliki števila,
ki predstavlja delež elementov, ki se pojavijo v modelu, ki je nastal ob uvozu, glede
na izhodiščni model in so ohranili enako poimenovanje. Primer: 6 od 10-ih
elementov je ohranilo enako poimenovanje v novonastalem modelu.
6. Poimenovanje povezav
Koliko povezav je ohranilo enako poimenovanje (oznaka oz. label se mora nahajati
zraven povezave). Preverja se ali je prišlo do napak ali razlik pri poimenovanju
povezav. Ali je zapis oblikovan enako (mala oziroma velika tiskana pisava) ali so
črke izpuščene itd. Vrednost je predstavljena v obliki števila, ki predstavlja delež
povezav, ki se pojavijo v modelu, ki je nastal ob uvozu, glede na izhodiščni model
in so ohranili enako poimenovanje. Primer: 6 od 10-ih povezav je ohranilo enako
poimenovanje v novonastalem modelu.
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 79
7. Indeks kakovosti uvoza diagrama
Indeks kakovosti uvoza diagrama je vrednost, ki pove uspešnost prenosa
informacij. Poda nam celostno predstavo, saj vključuje združitev vseh predhodno
navedenih kriterijev. Na podlagi podanega indeksa, bomo lahko pridobili tudi
odstotek uspešnosti uvoza. Primer: 27 od 30 elementov se je uspešno preneslo v
orodje. Uspešnost uvoza je 90%.
4.6 Izvedba eksperimenta oziroma pridobivanje rezultatov
V poglavju opisujemo izvedbo in analizo posebne oblike eksperimenta, s pomočjo katerega
bomo prišli do odgovorov na zastavljena vprašanja. Do sedaj naveden teoretični pogled in
opravljeno analitično in statistično analizo, smo preizkusili tudi praktično. Eksperiment
pričnemo s modelom M1, ki smo ga že predstavili skozi poglavja do sedaj. Ugotovitev
oziroma informacij, ki se bodo ponavljale ne bomo ponovno opisovali, da se izognemo
podvajanju - na primer: ocenjujemo, da se struktura datotek ali poimenovanje značk v
grobem ne bo spremenila, zato bomo navedli zgolj spremembe.
4.6.1 M1 - Izhodišče Signavio in analiza vsebine datoteke
V poglavju 4.4 smo definirali eksperiment. Začeli smo z orodjem Signavio, ker je nudil
najboljšo podporo. Ob analitičnem pregledu in statistični analizi smo to potrdili. V
primerjavi s preostalimi izbranimi orodji, Signavio podpira enake kot YBE in Activiti, ter še
nekatere druge elemente. Orodje omogoča izvoz in uvoz modela v in iz datotek s sledečimi
končnicami:
Izvoz Uvoz
Signavio archive (SGX)
BPMN 2.0 XML
XML
PNG (pixel graphic)
SVG (vector graphic)
Signavio archive (SGX)
BPMN 2.0 XML
XPDL 2.1
ARIS markup language
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 80
Najbolj relevanten je zapis v datoteki s končnico .bpmn. Slednji temelji na XML obliki, za
katero vemo, da je namenjena oziroma najpogosteje uporabljena pri izmenjavi informacij
in podatkov. Ustvarjena datoteka vsebuje 648 vrstic. Če pogledamo vsebino informacij, ki
so zajete, bi lahko dejali, da se slednje v grobem delijo na dva dela. V prvem delu imamo
predvsem definicije in informacije o posameznih elementih in gradnikih. Slednje zajemajo
podatke o ID vrednosti elementa, imenu ter meta podatkih. Približno na polovici vsebine se
omenjene informacije zaključijo in prične se del, ki je namenjen grafičnem definiranju
elementov. V drugi polovici tako zasledimo informacije o velikosti posameznega elementa
in njegovi legi, ki je definirana v obliki koordinatnih vrednosti za X in Y.
Struktura datoteke je sestavljena v obliki hierarhije značk, kar daje vsebini preglednost in
lažje razumevanje. XML zapis omogoča delno neposredno razumevanje vsebine, saj
slednja običajno ni zakodirana oziroma zapisana na "prikriti" način. To se pokaže tudi v
tem primeru, saj že ob pogledu na značke in vrednosti, lahko razberemo kateri element je
predstavljen in kako je poimenovan. V nadaljevanju bomo izpostavili določene dele
vsebine in značke, ki se največkrat ponovijo in nekako zajemajo in oblikujejo posamezne
elemente oziroma informacije.
Koda 4.1: M1.bpmn - Značke zunanji nivo
<?xml version="1.0" encoding="UTF-8"?>
<definitions xmlns="http://www.omg.org/spec/BPMN/20100524/MODEL"
xmlns:bpmndi="http://www.omg.org/spec/BPMN/20100524/DI" xmlns:omgdc="http://www.omg.org/spec/DD/20100524/DC"
xmlns:omgdi="http://www.omg.org/spec/DD/20100524/DI" xmlns:signavio="http://www.signavio.com"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" exporter="Signavio Process Editor, http://www.signavio.com"
exporterVersion="8.0.0" expressionLanguage="http://www.w3.org/1999/XPath" id="sid-4725e70c-cd1b-4d49-b987-
67b87388671b" targetNamespace="http://www.signavio.com/bpmn20"
typeLanguage="http://www.w3.org/2001/XMLSchema"
xsi:schemaLocation="http://www.omg.org/spec/BPMN/20100524/MODEL
http://www.omg.org/spec/BPMN/2.0/20100501/BPMN20.xsd">
<error id="sid-fbf14695-b98a-4e27-bfe1-de9b45dddae3"/>
<globalManualTask id="sid-404ffcc2-0740-4f8e-a37b-d257bf134904" name="Izvedi ročno"/>
<process id="sid-0b5dbd31-d4f9-49c6-9bf2-740f9ac8a2b8" isClosed="false" isExecutable="false"
processType="None">
..</process>
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 81
<bpmndi:BPMNDiagram id="sid-3fe52b2e-8259-4a0b-b80d-1bd76bf55c18">
..</bpmndi:BPMNDiagram>
</definitions>
Vidimo definiranje shem, imenskega prosta ter nekaterih drugih lastnosti (Koda 4.1). V
poglavju 2.3.6 Grafični model BPMNDI smo nekaj pomembnejših lastnosti izpostavili in
razložili. Razberemo tudi katero orodje je sestavilo datoteko. Značka <definitions>
predstavlja značko na najvišjem nivoju (tudi najbolj zunanjo značko), ki zajema vse ostale
značke. Že samo poimenovanje značke opisuje pomen oziroma vlogo - vsebina znotraj
značke bo definirala sam model. Na naslednjem nivoju se v našem primeru nahajajo štiri
značke:
<error>
<globalManualTask>
<process>
<bpmndi:BPMNDiagram>
V modelu M1 smo uporabili element končni dogodek, ki je tipa napaka. Slednji se sklicuje
na prvo značko <error>, ki se nahaja na začetku našega nivoja in je namenjena definiranju
napake. Sledi ji značka <globalManualTask>, s katero definiramo elemente in gradnike na
globalni ravni. Elementi definirani globalno so dosegljivi izven posameznega procesa.
Znački <process> in <bpmndi:BPMNDiagram> bomo označili kot najpomembnejši v tem
sklopu. Omenjeni znački namreč zajemata informacije, ki definirajo proces oziroma ga
grafično predstavijo. <process> s pomočjo pod-nivojskih značk predstavi nabor vseh
elementov, ki se nahajajo v procesu modela. Informacije, ki so predstavljene so semantično
naravnane. V tem delu so predvsem shranjene informacije o vrednostih id, name itd.
Slednje so primarno shranjene, kot vrednosti atributov posamezne značke (elementa).
Celotna vsebina datoteke je preobsežna za prikaz. Prav tako ni smiselno predstaviti vseh
vrednosti in atributov, saj se v veliki meri ponavljajo, prav tako pa sama vrednost za nas ni
relevantna. Na tem mestu lahko spomnimo, da smo ob pregledu literature v poglavju 2.3.5
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 82
v obliki pod-razredov, zajeli elemente in njihove atribute. Določene informacije in znanje
se lahko pridobi tudi iz specifikacij.
Za lažje razumevanje in prikaz povezav med elementi, smo pripravili primer. V model M1
smo vključili element začetni dogodek tipa časovnik. Poimenovali smo ga kar začetek
časovnik. Slika 4.4, ki prikazuje M1, potrjuje navedeno. Vidimo tudi, da je omenjeni
element povezan z elementom tipa opravilo. V slednjega prihaja še en tok zaporedja, ki pa
ima izvor v elementu tipa sporočilo, ki smo ga poimenovali začetno sporočilo. Koda 4.2
prikazuje kako je element začetek časovnik zapisan v datoteko.
Koda 4.2: M1.bpmn - Začetni dogodek tipa časovnik - definiranje elementa
<startEvent id="sid-20F9D041-A2B4-4FE5-990F-562738760B92" isInterrupting="true" name="začetek
časovnik">
<extensionElements>
<signavio:signavioMetaData metaKey="bgcolor" metaValue="#ffffff"/>
<signavio:signavioMetaData metaKey="preceedingprocesses" metaValue=""/>
</extensionElements>
<outgoing>sid-654B0DEA-6053-449B-80D9-AEBB5BDE0A82</outgoing>
<timerEventDefinition id="sid-e1836ae5-de60-470f-9926-c0332f4e9c2f"/>
</startEvent>
Potem, ko smo izvedli analizo vsebine datoteke, lahko trdimo skladnost poimenovanja
značk, s poimenovanjem posameznega elementa BPMN notacije. Na primeru vidimo, da
Koda 4.2 prikazuje definiranje začetnega dogodka. Slednje ugotovimo že iz poimenovanja
same značke - <startEvent>. Omenjena značka ima določene lastnosti shranjene z
definiranjem atributov. Ima podano identifikacijsko vrednosti, ki mora biti unikatna (id),
ime (name) in podatek, ki pove ali gre za prekinitveni tip elementa (isInterrupting).
Dodatne informacije so definirane tudi z uvedbo notranjih značk oziroma pod-nivojskih
značk. Najprej zasledimo dodatne elemente (<extensionElements>), kot vidimo hranijo
meta podatke. Sledita dve znački, ki ju moramo izpostaviti, saj igrata pomembno vlogo.
Prva značka <outgoing> nam poda informacijo, da iz elementa teče tok. Vrednost značke
predstavlja identifikacijsko vrednost toka. V našem primeru je id vrednost omenjenega
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 83
toka sid-654B0DEA-6053-449B-80D9-AEBB5BDE0A82. Kje se navedena vrednost še
pojavi, bomo prestavili v nadaljevanju. Druga značka (<timerEventDefinition>) nam pove,
da gre za element, ki vsebuje časovnik.
Kot smo že omenili, elementi niso definirani in predstavljeni samo na enem mestu v
vsebini datoteke. V prvem delu, ki smo ga pravkar povzeli, so zajeti predvsem semantični
podatki elementa. Element začetek časovnik z identifikacijsko vrednostjo sid-20F9D041-
A2B4-4FE5-990F-562738760B92 pa se še pojavi na več mestih. Najprej ga zasledimo na
mestu, kjer so definirani toki zaporedja (<sequenceFlow>). Koda 4.3 prikazuje primer v
katerem je definiran tok. Omenjeni tok predstavlja povezavo med elementoma začetek
časovnik in opravilo predstavlja storitev. Razložimo. Da res gre za začetni element, ki smo
ga vzeli za primer, vidimo po sourceRef vrednosti, ki je enaka id vrednosti našega začetek
časovnik elementa. Atributa sourceRef in targetRef vsebujeta identifikacijske vrednosti
elementov, kjer ima tok izvor (source) in cilj (target). Na podlagi tega dejstva bi dejali, da
bo povezava oziroma tok tekel iz elementa poimenovanega začetek časovnik (sid-
20F9D041-A2B4-4FE5-990F-562738760B92) proti elementu opravilo predstavlja storitev
(sid-3DBC623E-7EE5-4C85-9CCA-2119479D432C). Trditev je pravilna in se ujema tudi z
grafično predstavitvijo modela M1.
Koda 4.3: M1.bpmn - Definiranje zaporednega toka
<sequenceFlow id="sid-654B0DEA-6053-449B-80D9-AEBB5BDE0A82" name="" sourceRef="sid-20F9D041-
A2B4-4FE5-990F-562738760B92" targetRef="sid-3DBC623E-7EE5-4C85-9CCA-2119479D432C"/>
Dejali smo, da se približno na polovici vsebine dokumenta, pričnejo definicije elementov,
ki ponazarjajo njihovo grafično predstavitev. Koda 4.4 prikazuje kako je definiran element
začetek časovnik, ki smo za vzeli za primer.
Zunanja značka <bpmndi:BPMNShape> je tista, ki zajema vse informacije o grafični
predstavitvi elementa. Vsebuje dva atributa. Vrednost bpmnElement je enaka id vrednosti
elementa, ki mu definiramo grafično obliko oziroma lastnosti, ki vplivajo na vizualni del
elementa v modelu procesa. Na ta način je ustvarjena tudi povezava med definicijami, ki se
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 84
navezujejo na enak element, vendar so definicije porazdeljene na več mestih v dokumentu.
Značka ima tudi lastno identifikacijsko vrednost, za katero ugotovimo, da je enaka prejšnji
(vrednosti bpmnElement), le da ima na koncu še dodano "_gui". Ponovno lahko hitro
vidimo povezave. Dodatek "_gui" pa v tem primeru predstavlja okrajšavo za graphical
user interface, kar pomeni, da gre za grafično predstavitev vmesnika - v našem primeru
elementa.
Koda 4.4: M1.bpmn - Primer: Začetni dogodek tipa časovnik - definiranje oblike elementa
<bpmndi:BPMNShape bpmnElement="sid-20F9D041-A2B4-4FE5-990F-562738760B92" id="sid-20F9D041-
A2B4-4FE5-990F-562738760B92_gui">
<omgdc:Bounds height="30.0" width="30.0" x="47.6089423337356" y="609.0"/>
<bpmndi:BPMNLabel labelStyle="sid-66dc7a49-0015-4d1a-85ef-ac1ff826be81">
<omgdc:Bounds height="11.0" width="95.85713958740234" x="14.680372540034426" y="641.0"/>
</bpmndi:BPMNLabel>
</bpmndi:BPMNShape>
Ugnezdene značke, torej značke na nižjem nivoju, opisujejo višino in širino gradnika oz.
elementa, ter njegovo lego, ki je podana v obliki koordinat x, y (omgdc:Bounds). Z
enakimi atributi pa znotraj značke <bpmndi:BPMNLabel> definiramo lastnosti za oznako
oziroma napis elementa (ang. label).
Poglejmo še tok z id vrednostjo sid-654B0DEA-6053-449B-80D9-AEBB5BDE0A82, ki
smo ga omenili prej. Koda 4.2 prikazuje element iz katerega omenjeni tok teče ven. To
pomeni, da element predstavlja izvor toka. Slednje potrdimo na podlagi definirane značke,
<outgoing>, ki določa da obstaja tok (povezava) do drugega elementa. Slika 4.4 prikazuje
povezavo med elementoma in potrjuje prejšnjo trditev. Tok gre do elementa
poimenovanega Opravilo predstavlja storitev. Koda 4.5 predstavlja definiranje
omenjenega elementa. Skladno z modelom in po naših pričakovanjih se tok, ki smo ga
vzeli za primer, nahaja v znački <incoming>. Značka določa oziroma opredeljuje vse toke,
ki prihajajo v element. Zraven že omenjenega toka pa v element prihaja še eden, katerega
identifikacijska vrednost je sid-55A9D1DC-CAC3-4F81-87FE-8680F41C66F6.
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 85
Koda 4.5: M1.bpmn - Primer: Opravilo tipa storitev - definiranje elementa
<serviceTask completionQuantity="1" id="sid-3DBC623E-7EE5-4C85-9CCA-2119479D432C"
implementation="webService" isForCompensation="false" name="Opravilo predstavlja storitev"
startQuantity="1">
<extensionElements>
<signavio:signavioMetaData metaKey="bgcolor" metaValue="#ffffcc"/>
<signavio:signavioMetaData metaKey="risklevel" metaValue=""/>
<signavio:signavioMetaData metaKey="externaldocuments" metaValue=""/>
</extensionElements>
<incoming>sid-55A9D1DC-CAC3-4F81-87FE-8680F41C66F6</incoming>
<incoming>sid-654B0DEA-6053-449B-80D9-AEBB5BDE0A82</incoming>
<multiInstanceLoopCharacteristics behavior="All" id="sid-e5dd9a0b-1a29-4296-bf49-8639b7478e97"
isSequential="false"/>
</serviceTask>
Kot smo omenili bi lahko dejali, da so elementi definirani v dveh delih. V prvem so
definirani semantični podatki, v drugem so definirane vrednosti, ki poskrbijo za vizualni ali
grafični del. Podobno je tudi pri tokovi (povezavah). Če smo prej analizirali kako je tok
definiran iz semantičnega vidika, si še poglejmo kako je so informacije zapisane in
predstavljene za grafični del.
Koda 4.6 prikazuje zapis informacij, ki se nanašajo na vizualni del oziroma grafično
predstavitev povezave v modelu. V modelu M1 vidimo, da analizirani tok ni predstavljen z
direktno povezavo oziroma linijo med elementoma. Tok se na več mestih lomi - spreminja
smer. Značka <bpmndi:BPMNEdge> poskrbi za definiranje tovrstnih zadev oziroma stanj.
Omenjena značka vsebuje atributa, ki identificirata značko (id) oziroma element
(bpmnElement). Na pod-nivoju pa imamo nabor značk, ki definirajo točke, kjer pride do
loma toka oziroma spremembe smeri. Omenjene <omgdi:waypoint> značke vsebujejo
atributa x in y, ki vsebujeta vrednost, ki ponazarja mesto loma.
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 86
Koda 4.6: M1.bpmn - Primer: Definiranje toka - grafični del
<bpmndi:BPMNEdge bpmnElement="sid-654B0DEA-6053-449B-80D9-AEBB5BDE0A82" id="sid-
654B0DEA-6053-449B-80D9-AEBB5BDE0A82_gui">
<omgdi:waypoint x="77.6089423337356" y="624.0"/>
<omgdi:waypoint x="109.6089423337356" y="624.0"/>
<omgdi:waypoint x="109.6089423337356" y="524.0"/>
<omgdi:waypoint x="142.6089423337356" y="524.0"/>
</bpmndi:BPMNEdge>
Pomembnejše značke in vsebino smo izpostavili skozi navedene primere. Elementi so
definirani s približno enako strukturo in načinom. Na podlagi tega dejstva ni smiselno, da
na takšen način analiziramo vsak element. Ker bi se v osnovi precej ponavljali, smo ta del
izpustili.
4.6.2 M1 - Uvoz v YBE in ugotovitve
Ob pregledu literature in specifikacij orodja YBE, smo zaznali trditev, da orodje podpira
standard BPMN 2.0. Ugotovili smo, da trditev ne drži v celoti. V poglavju 4.2 smo opravili
analitični pregled podprtosti elementov glede na posamezno orodje in ugotovili
pomanjkanje podpore določenim elementom v orodju YBE. Ker nas zanima kaj se zgodi v
praksi, bomo model M1, poskusili prenesti v orodje YBE. Datoteko, katera definira M1 in
je bila ustvarjena z orodjem Signavio, bomo poskušali odpreti v orodju YBE.
Pri nalaganju modela nam orodje ni javilo napak ali opozoril. Slika 4.8 prikazuje dobljen
zaslon, ob koncu uvoza modela v orodje YBE. Predstavlja prvi vpogled v uspešnost
prenosa modela med uporabljenima orodjema. Novonastali model lahko primerjamo z
modelom M1 (Slika 4.4) in tako dobimo že prvi vtis o uspešnosti prenosa informacij.
Če smo pogledali modela bi na prvi pogled dejali, da sta si modela precej podobna. Ali je
temu res tako pa v nadaljevanju, kjer smo opravili analizo novonastalega modela. Pobližje
smo pogledali model, saj nas zanima če in kje prihaja do odstopanj. Ugotovitve in
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 87
morebitne spremembe zapisane v nadaljevanju. Prav tako smo podali odgovore in
vrednosti na točke, ki smo jih definirali v poglavju 4.5.
Slika 4.8: Model M1 v orodju YBE (M1 v YBE)
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 88
Kot smo že dejali sta modela precej podobna, vendar je pri prenosu informacij prišlo do
nekaterih odstopanj in napak. V praksi to predstavlja določene težave in morebitno
dodatno delo in stroške. Slednje pa je lahko za nekatera podjetja ključnega pomena in
nedopustno. Spet druga bi tolerirala takšna stanja oziroma odstopanja. Vendar vse to je v
domeni podjetja ali podjetij, ki bi si v izbranih orodjih izmenjevala ustvarjene modele.
V poglavju 4.5 smo navedli določene kriterija (lahko rečemo tudi postavke), po katerih
bomo lahko modela primerjali oziroma zabeležili spremembe. V poglavju 4.3.1 smo
navedli, da model M1, ki je bil ustvarjen v orodju Signavio in predstavlja izhodiščno stanje
oziroma izhodiščni model, vsebuje določeni število elementov in povezav. Navedenih
oziroma povsem enakih vrednosti ne moremo potrditi tudi za model, ki je nastal ob uvozu
v orodje YBE.
Izhodiščni model je zajemal nabor 35 elementov, ki se razlikujejo glede na vlogo oziroma
tip, ter nekatere druge lastnosti (na primer: poimenovanje, pozicijo v modelu itd). Pri
uvozu ni prišlo do izgube informacij na tem nivoju. Tako se jih v M1 v YBE tudi nahaja 35.
Slednje bi lahko označili za dobro, saj elementi predstavljajo najbolj pomembni del
modela. Pri prenosu povezav med elementi oziroma gradniki smo zaznali težave. Pri
prenosu se je izgubila ena povezava. V orodje YBE se je preneslo 25 povezav med tem, ko
jih M1 vsebuje 26.
Če primerjamo vizualno ali grafično predstavitev, se prejšnji rezultati ponovijo oziroma
poslabšajo. Na področju elementov se je orodje YBE dobro izkazalo, saj so vsi elementi
ohranili enako obliko (35 od 35). Med tem, ko pri elementih ni prišlo do odstopanj in
sprememb, ki bi elemente oblikovno popačile ali spremenile, pa so slednjih bile deležne
povezave. Enako obliko je ohranilo 15 od 26 povezav. Sprememba, ki se najpogosteje in v
večini primerov pojavi je pojavitev dodatnih lomov povezave. Do slednjih pride tudi zaradi
različne predstavitve gradnikov, ki jo posamezno orodje nudi. Če povemo drugače. Ne
smiselno bi bilo pričakovati popolnoma enak videz ali predstavitev modela, saj imajo
različna orodja, različno oblikovane knjižnice, ki vsebujejo predstavitev posameznih
elementov. Čeprav so ikone in groba oblika elementov definirane v standardu, slednji ne
definira podrobnosti, kot je na primer fiksna določitev debeline obrobe, skupen nabor ikon,
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 89
točno določeno točko od katere se izriše element glede na podane vrednosti za širino in
višino itd. Zasledili smo tudi napačen prikaz povezave med elementoma. Mejni element
Meja - signal, ki se nahaja na elementu Primer opravila, je povezan s komentarjem.
Povezava med omenjenima elementoma je sicer pravilno definirana in opredeljena, vendar
njena ponazoritev ni točna. Kot lahko vidimo na Slika 4.8, ima povezava puščico na strani
komentarja, kar ni pravilno.
Preverili smo tudi kako so se elementi in povezave prenesle iz vidika poimenovanja.
Trdimo lahko, da so elementi ostali enako poimenovani in pri samem poimenovanju ni
prišlo do napak (na primer: manjkajočih črk, preimenovanja, dodajanja posebnih znakov
itd). Izpostavljamo pa sledeče: prvo je lociranje oznak (label). V enem primeru (mejni
element Meja - pogoj) se slednja nahaja nad elementom, med tem ko se pri izhodiščnem
modelu nahaja pod elementom. Kot drugo pa izpostavljamo način oziroma obliko zapisa v
posameznih elementih. V nekaterih je upoštevan prelom besed (na primer: besedilo v
komentarju je razdeljeno v dve vrstici), med tem ko pri drugih ni. Omenjeno označujemo
kot odstopanja in ne kot neposredni napaki, saj ni prišlo do izgub informacij. Vrednosti in
vsebina ostaja definirana in navedena. Ker pa smo pri primerjavi opazili razlike, jih v
sklopu analize in ugotovitev, navajamo v vednost. Model M1 vsebuje dve poimenovani
povezavi. Povezava, ki je tipa tok zaporedja je svoje poimenovanje ohranila tudi v
novonastalem modelu M1 v YBE. Podatkovna asociacija, ki povezuje podatkovni objekt To
je podatkovni objekt in element Pošlji sporočilo, svojega poimenovanja ni ohranila.
Analizirali smo prenos modela v orodje YBE. Skozi vsebino smo odgovorili na točke, ki
smo jih opredelili kot ocenjevalne kriterije v poglavju 4.5. Ostala nam je še točka, ki
podaja indeks kakovosti uvoza diagrama. Če združimo do sedaj opisane vrednosti in
ugotovitve, dobimo vrednost 142. Ker je izhodiščni model imel indeks 155, vidimo, da je
prišlo do izgub. Odstotek uspešnosti prenosa je 91,6%.
Graf 4.4 prikazuje povzetek ugotovitev. Vrednosti se delijo v dva dela. Prvi predstavlja
statistične podatke na strani orodja Signavio (izhodiščni model oziroma stanje). Drugi
predstavlja orodje YBE oziroma statistično stanje po uvozu modela. Vrednosti so napisane
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 90
glede na posamezno postavko (ocenjevalni kriterij) in omogočajo takojšnje primerjanje in
vpogled, kje se pojavijo odstopanja.
Graf 4.4: Ocenjevalni kriteriji za M1 v YBE
Zanimala nas je tudi zgradba in struktura datoteke, ki jo sestavi oziroma pripravi orodje
YBE. Ker smo že analizirali datoteko, ki jo je sestavilo orodje Signavio in v kateri je
zapisan model M1, smo enako storili za model M1 v YBE.
Prvi vpogled v izvorno kodo datoteke M1_v_YBE.bpmn nam je dal vtis podobnosti z
datoteko M1.bpmn. Kod ne moramo primerjati neposredno, saj smo ugotovili, da je pri
prenosu informacij prišlo do določenih izgub. Posledično bi bila na primer primerjava
števila vrstic oziroma količine zapisov ne točna oziroma ne relevantna. Kot zanimivost pa
lahko navedemo, da datoteka v kateri se nahaja M1 v YBE, kljub določenim
pomanjkljivostim vsebuje več zapisov. Slednja jih ima 728, med tem ko jih izvorna
vsebuje 648. Vsebino datoteke bi lahko razdelili podobno in na enake sekcije, kot smo to
storili pri izvorni BPMN datoteki. Na začetku imamo definicijo jezika, shem itd., kateri
sledili vsebina, ki definira model. Slednja je v grobem razdeljena na dva dela. Najprej so
opredeljeni elementi in njihov semantični opis, ter tokovi in povezave. V drugem delu se
Številoelementov
Številopovezav
Oblikaelementov
Oblikapovezav
Poimenovanjeelementov
Poimenovanjepovezav
Signavio 35 26 35 26 31 2
YBE 35 25 35 15 31 1
0
5
10
15
20
25
30
35
40
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 91
nahajajo definicije za grafično ali oblikovno predstavitev omenjenih elementov.
Pričakovano so značke poimenovane enako oziroma glede na smernice standarda. V večini
primerov nam že samo poimenovanje značke pove za kakšen tip elementa ali povezave
gre. Ker smo izvorno datoteko pripravili v orodju Signavio, se kot del poimenovanja značk
uporablja predpona signavio. YBE omenjene predpone ni preimenoval ali spreminjal.
Zasledili pa smo nekatere lastne predpone orodja YBE, ki pa se pojavljajo v tistih značkah,
ki jih orodje Signavio ni definiralo. Koda 4.7 prikazuje zapis v datoteki, ki definira stran, ki
predstavlja delovno površino - polje kjer modeliramo. Vidimo, da je orodje YBE uporabilo
svojo predpono yaoqiang, v povezavi z pageFormat in page. Definiranje strani oziroma
formata strani, je podano skozi atribute omenjenih značk. Opredeljene so različne lastnosti,
ko je na primer: višina, širina, barva ozadja, orientacija itd.
Koda 4.7: M1_v_YBE.bpmn - Definiranje strani zapis v datoteki
<yaoqiang:pageFormat height="842.4" imageableHeight="832.4" imageableWidth="587.6" imageableX="5.0"
imageableY="5.0" orientation="0" width="597.6"/>
<yaoqiang:page background="#FFFFFF" horizontalCount="1" verticalCount="2"/>
Oznako yaoqiang smo zasledili še na začetku nekaterih vrednosti, ki so zapisane pod
atributom ID. Opazili smo, da je orodje YBE na mestih, kjer je Signavio na koncu vrednosti
dodal "_gui", vrednosti spremenilo. Medtem, ko je glavna identifikacijska vrednost (po
kateri lahko iščemo relacije med elementi v dokumentu) ostala enaka, je YBE omenjeni
dodatek odstranil in pred vrednostjo dodal "Yaoqiang-". Koda 4.8 prikazuje del vsebine
datoteke, kjer je definiran grafični del elementa. Slednja tudi prikazuje preimenovano ID
vrednost elementa.
Koda 4.8: M1_v_YBE.bpmn - Preimenovanje identifikacijskih vrednosti
<bpmndi:BPMNShape bpmnElement="sid-3F5245E4-89E2-43C7-94D3-FCA99B05A446" id="Yaoqiang-sid-
3F5245E4-89E2-43C7-94D3-FCA99B05A446">
<omgdc:Bounds height="80.0" width="100.0" x="190.0" y="95.0"/>
<bpmndi:BPMNLabel>
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 92
<omgdc:Bounds height="19.8359375" width="77.0" x="201.5" y="127.08203125"/>
</bpmndi:BPMNLabel>
</bpmndi:BPMNShape>
Po izvedbi primerjalne analize smo ugotovili, da je prišlo do določenih odstopanj. Prav
tako je prišlo, da do izgube informacij. Navedli smo, da se v novonastalem modelu ne
nahaja ena izmed povezav. Preverili smo vsebino datoteke. Glede na to, da model M1 v
YBE ni prikazal povezave med elementoma, smo logično sklepali, da v vsebini datoteke, ne
bomo zasledili nobenih informacij. Ob izvedbi analize vsebine datoteke smo ugotovili, da
temu ni tako in da ni prišlo do večjih sprememb. Na podlagi te ugotovitve in ustreznega
zapisa v datoteki, bi povezava v grafični predstavitvi modela morala obstajati. Ker se pa
slednja je zapisala v datoteko, ocenjujemo, da je prišlo do napake pri tolmaču orodja YBE,
ki ni zagotovil ustrezne in pravilne predstavitve modela.
4.6.3 M1 - Uvoz v Activiti in ugotovitve
V poglavju so zapisane ugotovitve, do katerih smo prišli na podlagi izvedbe eksperimenta -
prenos M1 v Activiti. Ker smo predhodno opravili analitični pregled orodja (poglavje 4.2),
že imamo določene informacije. Na podlagi le teh smo si že ustvarili določeno sliko
oziroma si postavili pričakovanja. Analiza je pokazala, da se je orodje Activiti predstavilo v
najslabši luči. Rezultati in ugotovitve so namreč pokazale, da orodje nudi najslabšo
podporo elementom. Kljub temu, da M1 predstavlja skupen nabor elementov, ocenjujemo,
da bo izmed izbranih orodij Activiti imel največ težav. Ugotovitve so zapisane v
nadaljevanju.
Platforma omogoča tako izvajanje modelov oziroma procesov, kot tudi načrtovanje.
Vmesnik omenjenega orodje je temu primerno nekoliko razdeljen. Zanima nas predvsem
načrtovalski del (Activiti Modeler), ki omogoča izmenjavo modelov.
Orodje ni javilo napak pri uvozu modela M1. Ob koncu postopka prenosa informacij, smo
na seznamu, ki zajema načrtovane modele, zagledali identifikacijsko vrednost našega
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 93
modela - tj. sid-0b5dbd31-d4f9-49c6-9bf2-740f9ac8a2b8. Podobno kot smo storili pri
prejšnjem orodju, bomo novonastali model poimenovali po enakem vzorcu - M1 v Activiti.
Slika 4.9: Model M1 v orodju Activiti (M1 v Activiti)
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 94
Ob urejanju modela M1 v Activiti opazimo, da ima orodje podobni vmesnik, kot Signavio.
Slika 4.9 prikazuje stanje modela M1 po uvozu v orodje Activiti. Takoj lahko opazimo
odstopanje od izvornega modela (Slika 4.4). Po prvem vtisu pa bi dejali tudi večje
odstopanje od tistega, ki smo ga zaznali pri orodju YBE (Slika 4.8). Poglejmo si model
pobližje in skozi ocenjevalne kriterije, ki smo jih navedli v poglavju 4.5.
Izhodiščni model M1 predstavlja nabor 35 elementov. V M1 v Activiti nam najprej pade v
oči neurejenost povezav, na vrhu modela. Vzrok slednjega je manjkanje elementa Pošlji
sporočilo. Omenjeni element pa ni edini, ki se ni uspešno prenesel v orodje. Zasledili smo
tudi pomanjkanje na področju komentarjev oziroma opomb. Nobeden element takšnega
tipa se ni prenesel. Po opravljeni statistični analizi oziramo pregledu, smo ugotovili, da se
je uspešno preneslo (zgolj) 29 elementov.
Posledično, ker se v novonastalem modelu ne nahajajo vsi elementi, je prišlo do odstopanj
tudi na področju povezav. Activiti ni uspešno prenesel in določil vseh povezav. Manjkajoče
povezave so predvsem na mestih, kjer je obstajala relacija med komentarjem in enim
izmed drugih elementov. Prav tako se povezava tipa asociacija ni uspešno prenesla.
Zanimivo in nepričakovano pa je Activiti prenesel povezave, ki vodijo do elementa Pošlji
sporočilo, med tem, ko slednjega kot smo že omenili ni. Izhodiščni model vsebuje 26
povezav. Uspešno prenesenih je bilo 20 povezav.
Zanima nas tudi grafična predstavitev prenesenih informacij. V tem koraku smo ocenjevali
obliko elementov in povezav, ki so se prenesle. Orodje ni imelo težav s predstavitvijo
elementov. Gradniki so brez večjih odstopanj oblikovani enako, kot ponazarja izhodiščni
model. Izmed 35 elementov izhodiščnega modela, je ohranilo obliko 29 elementov. To
pomeni, da so vsi elementi, ki so bili preneseni ohranili obliko. Pri povezavah je prišlo do
odstopanj. M1 vsebuje 26 povezav. Activiti je uspešno prenesel 20 povezav, med tem, ko
jih je uspešno predstavil 16. Štiri povezave, ki ustvarijo razliko predstavljajo tisti del, v
katerem smo navedli, da je prišlo do prenosa povezav do elementa, med tem ko se sam
element ni prenesel.
Izhodiščni model ima 31 poimenovanih elementov. To pomeni, da je posameznemu
elementu določena vrednost pod atributom name. Prišteli pa smo tudi tiste elemente, ki
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 95
predstavljajo komentarje oziroma vrednost predstavlja opombo. Ob pregledu smo ugotovili
ujemanje v poimenovanju v 25 primerih. M1 zajema dva tipa povezav med elementi.
Najpogosteje uporabljeno povezavo tipa tok zaporedja in povezavo asociacije. Obe smo v
izhodiščnem modelu poimenovali. Activiti ni prenesel elementa, ki predstavlja podatkovni
objekt in povezav do le tega. Ker je orodje imelo že predhodno težave pri prenosu
informacij, določitve pravilnega poimenovanja ni bilo mogoče preveriti. Na Slika 4.9 lahko
vidimo, da je zaporedni tok poimenovan. Opazili smo odstopanje, ko smo povezavo
oziroma tok želeli spremenit. V tem primeru je oznaka, ki predstavlja del povezave in
vsebuje vrednost poimenovanja povezave, izginila. Ob kliku na povezavo smo med atributi
zaznali pravilo poimenovanje in ohranjanje vrednost, napaka se pojavi zgolj pri ponovnem
prikazu oznak (label). Ocenjujemo, da je uspešno poimenovanje ohranila samo 1
povezava, med tem ko M1 vsebuje 2. Izpostavljamo pa dejstvo, da kljub prenosu
poimenovanja povezave toka zaporedja, je potrebno biti pozoren, saj se je orodje odzvalo
nekoliko nenavadno.
Sedma točka ocenjevalnih kriterijev določa podajanje indeksa kakovosti uvoza diagrama.
Od izhodiščne vrednosti 155 je Activiti dosegel indeks 120. Na podlagi tega lahko
določimo odstotek uspešnosti, ki znaša 77,4%. Omenimo še dejstvo, ne samo, da Activiti ni
informacije predstavil pravilno, prišlo je izgub informacij. Izmenjava modelov med
izbranima orodjema v praksi ne bi prinašala 100% rezultatov. Graf 4.5 ponazarja vizualno
predstavitev rezultatov, ki jih prinaša prenos modela M1 v orodje Activiti.
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 96
Graf 4.5: Ocenjevalni kriteriji za M1 v Activiti
Orodje omogoča uvoz modelov, kot tudi izvoz oziroma shranjevanje. Ustvarjeni model, ki
je nastal na podlagi prenosa M1, M1 v Activiti smo shranili in informacije zapisal v
datoteko s formatom .bpmn20.xml. V nadaljevanju smo zapisali naše ugotovitve, do katerih
smo prišli na podlagi analize in pregleda izvorne kode omenjene datoteke (v nadaljevanju
tudi M1_v_Activiti.bpmn20.xml).
Vsebina datoteke ima podobno strukturo, ki smo jo omenjali že v prejšnjih primerih. Na
začetku so navedene definicije jezika, shem, imenskega prostora itd. Sledi zapis
informacij, ki v glavnem poskrbijo za semantično predstavitev modela. V približno drugi
polovici vsebine, pa se nahajajo značke s katerimi definiramo grafično predstavitev. Na
začetku analize smo preverili dolžino datoteke oziroma količino zapisa informacij. Opazili
smo, da M1_v_Activiti.bpmn20.xml vsebuje občutno manj zapisov, kot jih imata datoteki
M1.bpmn (Signavio) in M1_v_YBE.bpmn - 209. Vzrok pripisujemo številnim napakam na
strani orodja Activiti, ki niso omogočile (pravilnega) prenosa vseh informacij. Kot smo
ugotovili in zapisali določeni elementi manjkajo. Slednjih posledično ni potrebno zapisati v
datoteko, kar načeloma pomeni manj vsebine - manjša datoteka. Značke so poimenovane
na enak način, kot smo opazili pri prejšnjih primerih. V večini primerov ime ponazarja tip
Številoelementov
Številopovezav
Oblikaelementov
Oblikapovezav
Poimenovanje
elementov
Poimenovanje povezav
Signavio 35 26 35 26 31 2
Activiti 29 20 29 16 25 1
0
5
10
15
20
25
30
35
40
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 97
elementa. Takšno prednost omogoča XML, ki nudi možnost poimenovanja lastnih značk.
V tem primeru pa smernice oziroma pogoje določa tudi sam standard BPMN.
Na splošno pa smo opazili okrnjeno strukturo. Med tem, ko je datoteka z izvornim
modelom M1, vsebovala še kar nekaj dodatnih značk in atributov, ki so podajale vrednosti
za določene meta podatke (npr.: metaKey, metaValue itd), slednjih v datoteki
M1_v_Activiti.bpmn20.xml ni moč zaslediti. Prav tako je ob shranjevanju prišlo do
določenih izgub informacij oziroma do zapisa posplošenih informacij. Koda 4.9 prikazuje
primer, ki kaže kako so se trije začetniki dogodki, ki se razlikujejo glede na tip, zapisali v
datoteko.
Koda 4.9: M1_v_Activiti.bpmn20.xml - Definiranje začetnih dogodkov
<startEvent id="sid-53F78080-5E74-47E8-8704-D73383BC2FAE" name="Začetni dogodek
navadni"></startEvent>
<startEvent id="sid-A87EAD52-E252-4341-BCDC-DF826EB8CDCD" name="začetno
sporočilo"></startEvent>
<startEvent id="sid-20F9D041-A2B4-4FE5-990F-562738760B92" name="začetek časovnik"></startEvent>
Ugotovimo, da so se vsi dogodki zapisali enako, brez posebej določenega oziroma
podanega tipa. Natančneje - v tem primeru se je vsem določil tip brez. Izvorni model pa
vsebuje začetne dogodke tipa: brez določila, sporočilo in časovnik. Koda 4.10 prikazuje
kako so omenjeni dogodki definirani v izvorni datoteki.
Koda 4.10: M1.bpmn - Definiranje začetnih dogodkov
<startEvent id="sid-53F78080-5E74-47E8-8704-D73383BC2FAE" name="Začetni dogodek navadni">
<extensionElements>
<signavio:signavioMetaData metaKey="bgcolor" metaValue="#ffffff"/>
<signavio:signavioMetaData metaKey="preceedingprocesses" metaValue=""/>
<signavio:signavioLabel ref="text_name" valign="middle" x="17.0" y="-21.0"/>
</extensionElements>
<outgoing>sid-DB3C97BB-6B52-4A7E-810A-29F0C6B62817</outgoing>
</startEvent>
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 98
<startEvent id="sid-A87EAD52-E252-4341-BCDC-DF826EB8CDCD" isInterrupting="true" name="začetno
sporočilo">
<extensionElements>
<signavio:signavioMetaData metaKey="bgcolor" metaValue="#ffffff"/>
<signavio:signavioMetaData metaKey="viaitsystem" metaValue=""/>
<signavio:signavioMetaData metaKey="preceedingprocesses" metaValue=""/>
<signavio:signavioLabel bottom="false" left="false" ref="text_name" right="false" top="true"
valign="bottom" x="15.0" y="-8.0"/>
</extensionElements>
<outgoing>sid-55A9D1DC-CAC3-4F81-87FE-8680F41C66F6</outgoing>
<messageEventDefinition id="sid-46c3473a-0b7b-40a4-853a-6467512a7e85"/>
</startEvent>
<startEvent id="sid-20F9D041-A2B4-4FE5-990F-562738760B92" isInterrupting="true" name="začetek
časovnik">
<extensionElements>
<signavio:signavioMetaData metaKey="bgcolor" metaValue="#ffffff"/>
<signavio:signavioMetaData metaKey="preceedingprocesses" metaValue=""/>
</extensionElements>
<outgoing>sid-654B0DEA-6053-449B-80D9-AEBB5BDE0A82</outgoing>
<timerEventDefinition id="sid-e1836ae5-de60-470f-9926-c0332f4e9c2f"/>
</startEvent>
Enako oziroma podobno se zgodi z vmesnimi dogodki. Ali orodje ni določilo tipa
elementa, ali pa je določilo napačnega (na primer: v izvornem modelu je določen vmesni
dogodek tipa sporočilo, shranil pa se je tip časovnik). Prav tako smo opazili, da določenim
elementom manjka vrednost za atribut name, ki predstavlja poimenovanje oziroma ime
posameznega elementa. V vsebini datoteke tudi nismo zasledili določenih povezav.
Izpuščene so bile povezave, ki so vodile do manjkajočega elementa, vendar jih je
načrtovalec modelov prikazal. Kot tudi tiste, ki smo jih definirali v pod-procesu. V delu,
kjer se nahajajo definicije za grafično predstavitev elementov, ni prišlo do večjih
odstopanj. Navedemo lahko opazko pri definiranju vrednosti. Na mestih, kjer je Signavio
uporabil na koncu identifikacijske vrednosti končnico "_gui", je orodje Activiti slednjo
odstranilo in na začetek vrednosti dodalo predpono "BPMNShape_" (Koda 4.11).
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 99
Koda 4.11: M1_v_Activiti.bpmn20.xml - Primer definiranja grafične predstavitve
<bpmndi:BPMNShape bpmnElement="sid-20F9D041-A2B4-4FE5-990F-562738760B92"
id="BPMNShape_sid-20F9D041-A2B4-4FE5-990F-562738760B92">
<omgdc:Bounds height="30.0" width="30.0" x="47.6089423337356" y="609.0"></omgdc:Bounds>
</bpmndi:BPMNShape>
Activiti se je odrezal najslabše. Iz vidika načrtovanja in izmenjave modelov predstavlja
najmanj ugodno in primerno rešitev. Pokazala so se večja odstopanja, ki otežujejo
takojšnje nadaljnje delo. V obzir pa navajamo dejstvo, da je orodje primerno tudi za
področje izvajanja modelov in procesov. Ali se na omenjenem področju orodje bolje
izkaže ne moremo trditi, saj bi v tem primeru morali opraviti podrobnejšo analizo samo te
platforme.
Ob koncu poglavja smo pripravili graf, ki zajema in združuje do sedaj navedeno. Graf 4.6
ponazarja vizualno predstavitev rezultatov, ki smo jih dobili z izvedbo eksperimenta, pri
katerem smo uporabili model M1 in izbrana orodja. Omogoča hitro prepoznavanje
odstopanj od izhodišča (Signavio). Prav tako pa imamo takojšnjo primerjavo med rezultati
iz posameznih orodij.
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 100
Graf 4.6: Uspešnost prenosa M1 v YBE in Activiti
4.6.4 M2 - Izhodišče YBE in analiza vsebine datoteke
Model M2 smo načrtovali v orodju YBE. Slednjega, na podlagi rezultatov analitičnega
pregleda, uvršamo na drugo mesto, glede na podporo elementov. Orodje omogoča izvoz in
uvoz modela v in iz datotek s sledečimi končnicami:
Izvoz Uvoz
.bpmn
.png
.sgx
.svg
.bpmn,
.bpmn20.xml ali
.xml.
35
26
35
26
31
2
35
25
35
15
31
1
29
20
29
16
25
1
0
5
10
15
20
25
30
35
40
Številoelementov
Število povezav Oblikaelementov
Oblika povezav Poimenovanjeelementov
Poimenovanjepovezav
Signavio YBE Activiti
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 101
Pri izmenjavi modela smo uporabili .bpmn. Na podlagi tega smo diagram shranili v
datoteko, ki ima prej omenjeno končnico. Nastala datoteka vsebuje 581 zapisov oziroma
vrstic. Če se za trenutek vrnemo na začetek. Pri načrtovanju izhodiščnih modelov, smo se
poskušali čim bolj izenačit. Želimo doseči kar se da podobna izhodiščna stanja.
Pri samem načrtovanju smo opazili, da je prišlo do razlik od med načrtovanjem M1 in
načrtovanjem M2. Kljub temu, da bi naj modeli M1, M2 in M3 si bili enaki, saj vsi
vsebujejo skupne elemente, prihaja do odstopanj. Izpostavimo določena odstopanja in
razlike, ki jih pri načrtovanju M1 nismo zasledili:
Onemogočen je tok zaporedja iz opravila, ki ima podan tip oziroma lastnost
kompenzacija. M2 vsebuje element "Opravilo1", ki ima omenjeno lastnost in ga ni
bilo mogoče povezati z elementom vmesnega dogodka tipa časovnik. Signavio je
to omogočil.
YBE ni dovolil pripeti element opombe na povezave.
Vnesena vsebina v element tipa opombe je prikazana v eni vrstici, razen če vsebine
ne prelomimo sami (shift+enter). YBE se ne ozira na velikost elementa. Na ta
način je vsebina prikazana tudi čez podlago elementa, torej izven meje elementa.
Ob načrtovanju dogodkovnega pod-procesa (ang. event subprocess), smo prejeli
obvestilo, ki nas je opozorilo, da element ne sme vsebovati vhodne ali izhodne
toke zaporedja. Prav tako pa je bilo onemogočeno vstavljanje povezave.
Razlika se pojavi pri definiranju elementa klic aktivnosti. Pri načrtovanju v orodju
Signavio se slednje definira tako, da izberemo element tipa opravilo in obkljukamo
lastnost call activity. Orodje YBE ima v naboru elementov posebej definiran
element call activity, ki mu lahko tudi določimo različni tip (npr. človek - human).
Pri mejnih elementih je Signavio dopuščal možnost poljubne pozicije oznake (ang
label) elementa. Pri orodju YBE je slednje onemogočeno.
Razlika se pojav tudi pri načinu prikaza povezav med elementi. Orodje YBE
ponuja drugačno lomljenje povezav. Na voljo imamo direktne linije, krivulje itd.
YBE ne omogoča poimenovanje povezave tipa asociacija.
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 102
Ker je struktura in vsebina datoteke, ki vsebuje diagram v veliki meri enaka oziroma
podobna tisti, ki hrani model M1, o slednji ne bomo veliko navajali. Kot smo že navedli, se
na začetku vsebine nahajajo definicije datoteke, jezika, imenskega prostora itd. Sledijo
definicije elementov (ponekod se ob definiranju elementa, definira pozicija napisa (label)).
Primer definicije elementa prikazuje Koda 4.12.
Koda 4.12: Primer definiranja elementa tipa opravilo - skripta
<scriptTask completionQuantity="1" id="_3" isForCompensation="false" name="Primer opravila"
startQuantity="1">
<incoming>_4</incoming>
<outgoing>_11</outgoing>
</scriptTask>
V drugi polovici se nahajajo definicije za prikaz posameznega elementa. Tako na primer
zasledimo informacije o poziciji in legi elementa. Koda 4.13 prikazuje definiranje
slednjega, za prej uporabljen element.
Koda 4.13: Primer definiranja lastnosti za pozicijo in obliko elementa tipa opravilo - skripta
<bpmndi:BPMNShape bpmnElement="_3" id="Yaoqiang-_3">
<dc:Bounds height="65.0" width="95.0" x="177.221518358403" y="63.13978809187489"/>
<bpmndi:BPMNLabel>
<dc:Bounds height="19.8359375" width="77.0" x="186.221518358403" y="87.72181934187489"/>
</bpmndi:BPMNLabel>
</bpmndi:BPMNShape>
V nadaljevanju smo predstavljeno datoteko poskušali uvoziti v preostala izbrana orodja.
Rezultate in ugotovitve smo zapisali v nadaljevanju.
4.6.5 M2 - Uvoz v Signavio in ugotovitve
Signavio predstavlja orodje, ki je do sedaj podalo najboljši vtis. Na podlagi tega dejstva
sklepamo, da se bo orodje pri uvozu dobro odrezalo. Ker Signavio ob uvozu ni javil
nobene napake, smo zagledali diagram, ki ga prikazuje Slika 4.10. Poimenovali smo ga M2
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 103
v Signavio. Na prvi pogled lahko rečemo, da gre za dokaj dobro porazdelitev in postavitev
gradnikov glede na izvorni model. Vendar lahko tudi kar hitro opazimo, da povsem
natančno oziroma enako niso postavljeni.
Slika 4.10: Model M2 v orodju Signavio (M2 v Signavio)
Poglejmo diagram pobližje in ga primerjamo z izvornim stanjem. Izvorni model M2
vsebuje 34 elementov. Signavio je uspešno prenesel 33 elementov, kar pomeni skoraj vse.
Zataknilo se je pri elementu dogodkovni podproces, ki je izvorno razširjeni pod-proces, ki
vsebuje začetni dogodek pod1_zacetek, opravilo pod1_opravilo1 in končni dogodek
pod1_konec. Orodje je omenjene tri elemente uspešno preneslo. Prav tako je preneslo tudi
element dogodkovni podproces, vendar je pri slednjem uporabilo zaprti tip definiranja pod-
procesa. Element je sicer enako poimenovan in naravnan v pravo smer, če gledamo
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 104
skupino gradnikov, vendar je pri uvozu prišlo do drugačne predstavitve in to moramo
upoštevati in izpostaviti.
M2 zajema 22 povezav med gradniki. Če sodimo po številu, lahko rečemo, da je prenos
informacij bil dober, saj je orodje Signavio uspešno preneslo vseh 22 povezav. Ocenjevalni
kriteriji, ki so bolj zanimivi pa podajajo rezultate na področju primerjave prenosa oblike
gradnikov in povezav med slednjimi. Navedli smo, da M2 vsebuje 34 elementov in 22
povezav. M2 v Signavio je prikazal 33 elementov, za katere lahko rečemo, da so ohranili
obliko. Pri tem moramo upoštevati, da lastne knjižnice za grafiko vplivajo na prikaz
gradnika. V kolikor ne gre za drastične spremembe prikaza elementa, lahko slednje
zanemarimo. Slika 4.10 prikazuje določene primere odstopanja. Tako zasledimo na primer
spremembe, ki prikažejo, da je tekst prikazan preko robov gradnika - primer elementa: to je
podatkovni objekt. V tem primeru je izbira elementa pravilna, prav tako je je vsebina
(napis) elementa pravilna. V kolikor bomo element povečali, bomo dosegli lepši prikaz.
Razen stilske izboljšave nismo spreminjali ali popravljali ničesar. Podobno stanje smo
opazili pri povezavah. Povezave so urejene zadovoljivo, če ponovno upoštevamo različne
definicije gradnikov in povezav v stilskih knjižnica orodja. V podrobnem pregledu in
primerjavi smo zasledili, da se je povsem enako preneslo 11 povezav.
Signavio se je tudi pri poimenovanju elementov in povezav dobro odrezal. V M2 smo
poimenovali 31 elementov in 1 povezavo. Če ne upoštevamo napačno izbiro elementa
dogodkovni podproces opazimo, da so vsi elementi ohranili enako poimenovanje. Prav
tako je poimenovanje ohranila povezava.
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 105
Graf 4.7: Ocenjevalni kriteriji za M2 v Signavio
Graf 4.7 prikazuje zbrane vrednosti, pridobljene na podlagi ocenjevalnih kriterijev, v
grafični predstavitvi. Na podlagi navedenih vrednosti ugotovimo indeks oziroma zadnji
ocenjevalni kriterij. Izhodiščni model M2 ima indeks 144. Preneseni model M2 v Signavio
je dosegel indeks 131, kar pomeni, da gre za 90,97% uspešnost. Izgube so bile predvsem
na področju oblike povezav, za kateri pa smo navedli, da niso bile drastične in bi jih bilo
mogoče zanemariti. S tem bi se indeks kakovosti uvoza diagrama povišal.
Ustvarjen model smo tudi izvozili v datoteko s končnico bpmn. Opravili smo pregled
strukture in vsebine datoteke. Slednji ni prinesel novih ugotovitev. Orodje Signavio je
pripravilo podobno datoteko, kot v prvem primeru, kjer smo uporabili M1. Omenimo, da
datoteka, ki vsebuje M2 v Signavio vsebuje 512 zapisov oziroma vrstic. Datoteka, ki je
nastala na podlagi izvoza izvornega modela M2 iz orodja YBE, pa 581. Do razlik prihaja v
definiranju lastnih atributov orodja ali pa je orodje YBE vključilo kakšno značko (ali
atribut) brez vrednosti, med tem, ko ga je Signavio izpustil.
Številoelementov
Številopovezav
Oblikaelementov
Oblikapovezav
Poimenovanjeelementov
Poimenovanjepovezav
YBE 34 22 34 22 31 1
Signavio 33 22 33 11 31 1
0
5
10
15
20
25
30
35
40
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 106
4.6.6 M2 - Uvoz v Activiti in ugotovitve
Izbran model M2 smo uvozili tudi v orodje Activiti. Do sedaj je orodje podalo nekoliko
slabši vtis. Zasluga slednjega je predvsem v ne dobri podpori elementom BPMN 2.0. Slika
4.11 prikazuje dobljen model, po tem, ko smo M2 uvozili v orodje Activiti. Skladno z
dogovorom bomo slednjega poimenovali M2 v Activiti. Hitro vidno je odstopanje, ki ga
zasledimo na vrhu diagrama. Do takšnega popačenja modela je prišlo zaradi napake, ki je
posledica izgube informacij. Če primerjamo izvorni model in M2 v Activiti vidimo, da
manjka element Pošlji sporočilo, kar je tudi razvidno na Slika 4.11. Zanimivo je, da so se
povezave na element ohranile. Med drugim lahko vidimo tudi, da manjkajo vsi elementi
tipa opombe. Preverimo sedaj vrednosti podane skozi ocenjevalne kriterije. Izhodiščni M2
model vsebuje 34 elementov. Že pogled na prej omenjeno sliko nam da vedeti, da je prišlo
do izgub podatkov. M2 v Activiti je prenesel 29 elementov od 34. Vendar omenjenih 29 ni
povsem točnih in pravilnih. Pravilno se je preneslo 23 elementov. Prišlo je tudi do
odstopanj na področju povezav. Od izhodiščnih 22 se je preneslo 17 povezav.
Oblikovne informacije (govorimo o grafični predstavitvi) so slabo zajete in predstavljene.
Če bi opredelili pozitivno usmerjenost za področje elementov, je področje povezav v
nasprotju. Navedli smo, da se je uspešno preneslo 23 elementov. Omenjeni elementi so
tudi ohranili obliko. Če enako analizo opravimo nad povezavami ugotovimo, da prihaja do
večjega odstopanja. Izmed 17 povezav sta enako obliko ohranili zgolj dve povezavi. Del
razloga, zakaj je takšna vrednost, se nahaja v različnih definicijah oziroma predstavitvah v
grafičnih knjižnicah predstavitve gradnikov v orodju. Del pa pripisujemo izgubi
informacij. Vidimo lahko, da manjkajo določeni elementi - na primer: Pošlji sporočilo in
To je podatkovni element.
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 107
Slika 4.11: Model M2 v orodju Activiti (M2 v Activiti)
Tako kot pri uvozu M2 v Signavio smo, na področju poimenovanja elementov in povezav,
prišli do podobnih ugotovitev. Navedli smo, da je orodje uspešno preneslo 23 elementov.
Vseh poimenovanih elementov je 31. M2 v Activiti jih ima 24. Razlog zakaj jih omenjen
model ima 24 in ne 23, je v elementu Dogodkovni podproces. Navedeni element je sicer
pravilno poimenovan, vendar se ni prenesel pravilno. Slika 4.11 prikazuje, kako se trije
elementi, ki so del pod-procesa, nahajajo izven le tega. Tok zaporedja, ki je poimenovan, je
ohranil poimenovanje tudi v novonastalem modelu.
Graf 4.8 prikazuje navedene ugotovitve v grafični obliki. Ugotovili smo, da se je orodje
najslabše odrezalo in temu primerno je dosežena vrednost indeksa uspešnosti prenosa, ki
znaša 90. Glede na izhodiščni model, ki ima vrednost 144, to pomeni 62,5% uspešnost.
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 108
Graf 4.8: Ocenjevalni kriteriji za M2 v Activiti
V naslednji fazi smo poskušali izvoziti novonastali model v datoteko. Naleteli smo na
težave, saj orodje Activiti ni omogočilo oziroma ni izvedlo shranitve modela. Pojavil se je
napis "Create of BPMN XML failed", ki sporoča, da ni bilo mogoče kreirati datoteke. Po
več poskusih nam je vendarle uspelo, vendar smo pred tem morali preveriti celotni diagram
in vsak element prestaviti in povezavam ponovno določiti vhodne in izhodne točke.
Ugotovili smo, da po uvozu modela slednjega ne moremo direktno shraniti. Potrebno je
vložiti čas in vsak element ponovno preveriti, kar na nek način pove, da orodje ni primerno
za izmenjavo datotek.
Graf 4.9 ponazarja vizualno predstavitev rezultatov, ki smo jih dobili z izvedbo
eksperimenta, pri katerem smo uporabili model M2 in izbrana orodja. Omogoča hitro
prepoznavanje odstopanj od izhodišča (YBE). Prav tako pa imamo takojšnjo primerjavo
med rezultati iz posameznih orodij.
Številoelementov
Številopovezav
Oblikaelementov
Oblikapovezav
Poimenovanje
elementov
Poimenovanje povezav
YBE 34 22 34 22 31 1
Activiti 23 17 23 2 24 1
0
5
10
15
20
25
30
35
40
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 109
Graf 4.9: Uspešnost prenosa M2 v Signavio in Activiti
4.6.7 M3 - Izhodišče Activiti in analiza vsebine datoteke
Zadnji v fazi načrtovanih modelov, ki zajemajo skupne elemente, je M3. Omenjeni model
smo načrtovali v orodju Activiti. Analitični pregled je pokazal smernico, ki nakazuje, da bo
orodje povzročajo največ težav, saj ima slabšo podporo, kot preostala izbrana orodja. V
tem primeru pa smo Activiti uporabili za načrtovanje izhodiščnega modela. Načrtovan
diagram smo izvozili v format s končnico bpmn. Orodje omogoča izvoz in uvoz modela v
in iz datotek s sledečimi končnicami:
Izvoz Uvoz
.bpmn
.png
.sgx
.svg
.bpmn20.xml ali
.bpmn.
34
22
34
22
31
1
33
22
33
11
31
1
23
17
23
2
24
1
0
5
10
15
20
25
30
35
40
Številoelementov
Število povezav Oblikaelementov
Oblika povezav Poimenovanjeelementov
Poimenovanjepovezav
YBE Signavio Activiti
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 110
Pri samem načrtovanju smo zaznali kar nekaj pomanjkljivosti, ki jih pri prejšnjih orodjih
nismo. V nekaterih situacijah smo izvedli prilagoditev, med tem, ko pri nekaterih tudi ta ni
bila mogoča, saj orodje ni nudilo podporo elementu. V nadaljevanju so navedene
zabeležene prilagoditve oziroma ugotovitve:
Orodje ne omogoča definiranje elementa tip opravilo brez, da bi slednjemu
določili tip. Na podlagi te ugotovitve smo elementu Zaporedno izvajanje
opravila določili tip človek - human ali človeško opravilo.
Ker orodje med naborom elementov ni ponujalo mejnega elementa tipa
pravilo, elementa Meja - pogoj ni bilo mogoče vključiti.
Opazili smo drugačno poimenovanje opravila tipa pošiljanje, ki je izvorno
poimenovan kot Send task, Activiti pa slednjega ponuja pod oznako Mail
task.
Nabor ne zajema podatkovnih elementov, zato slednjega ni bilo mogoče
vključiti v diagram.
V navezi na prejšnji element, ni bilo mogoče vključiti povezave tipa
asociacija. Slednjo smo lahko uporabili za povezavo do elementa, ki je tipa
opombe.
Onemogočeno je poljubno premikanje oznak (label) elementa.
Podobno kot v primeru na začetku, smo elementu Opravilo1 določiti tip
človek - human.
Element tipa klic aktivnosti se nahaja kot ločen gradnik, zato opravilu Izvedi
ročno nismo morali določiti omenjene lastnosti. V diagram smo vključili
ločen element, ki smo ga poimenovali Klic aktivnosti in predstavlja opravilo
z istoimenskim tipom.
Element tipa opomba, ne moremo povezati s tokom zaporedja.
Ustvarjeni diagram smo shranili v datoteko s končnico bpmn20.xml. Slednja vsebuje 237
zapisov oziroma vrstic. Slednje je, če posplošimo, za polovico manj od M1 in M2. Razlog
je predvsem v načinu zapisa oziroma količini hranjenih informacij. Lahko bi dejali, da gre
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 111
za minimalističen stil hranitve informacij. Koda 4.14 prikazuje primer kako so elementi in
povezave definirane oziroma predstavljene v datoteki.
Koda 4.14: Primer definiranja elementov in povezav v M3
<startEvent id="sid-3147B292-85DC-41EC-8A68-D1627CFD68C8" name="Začetni dogodek
navadni"></startEvent>
<sequenceFlow id="sid-0B45D3DF-30A5-4F21-96AB-B0F484AC2501" sourceRef="sid-3147B292-85DC-
41EC-8A68-D1627CFD68C8" targetRef="sid-27767D28-AD84-4F80-A14B-
65C475B118C1"></sequenceFlow>
<scriptTask id="sid-27767D28-AD84-4F80-A14B-65C475B118C1" name="Primer opravila"
activiti:autoStoreVariables="false"></scriptTask>
<userTask id="sid-780D116F-A8CE-4A96-825B-B9F6DFB33F88" name="Zaporedno izvajanje
opravila"></userTask>
Koda 4.15: Primer definiranja grafičnih prikaza elementov in povezav v M3
<bpmndi:BPMNShape bpmnElement="sid-26A1074B-C712-43F1-990C-483C93FA4C64"
id="BPMNShape_sid-26A1074B-C712-43F1-990C-483C93FA4C64">
<omgdc:Bounds height="30.0" width="30.0" x="272.71764116525236"
y="125.07465234658329"></omgdc:Bounds>
</bpmndi:BPMNShape>
<bpmndi:BPMNEdge bpmnElement="sid-6D288EBB-B388-42D8-B123-D3134D54F9C4" id="BPMNEdge_sid-
6D288EBB-B388-42D8-B123-D3134D54F9C4">
<omgdi:waypoint x="730.0" y="165.0"></omgdi:waypoint>
<omgdi:waypoint x="885.0" y="165.0"></omgdi:waypoint>
</bpmndi:BPMNEdge>
Koda 4.15 prikazuje primer definiranja grafične predstavitve elementa in povezave.
Omenjene definicije zasledimo v drugi polovici vsebine datoteke. Opazili smo, da kljub
okrnjeni hranitvi informacij, se sama struktura v grobem ni spremenila. Na začetku se
nahajajo informacije o datoteki, jeziku, imenskemu prostoru itd., sledijo definicije
elementov in povezav, ter v drugi polovici in v zadnjem delu še informacije o grafični
predstavitvi elementov in povezav. Omenimo lahko vrstni red zapisa, ki je nekoliko
drugačen. Do sedaj so se definicije elementov in povezav v grobem ločile - najprej
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 112
elementi, nato povezave. V tem primeru smo zasledili, več zapisov, kjer je najprej
definiran element, ter nato še takoj tokovi (povezave), ki so del omenjenega elementa.
V nadaljevanju smo omenjeno datoteko in model, poskušali prenesti v preostala izbrana
orodja. Rezultati in ugotovitve so navedene v nadaljevanju.
4.6.8 M3 - Uvoz v Signavio in ugotovitve
Tokrat smo v Signavio uvozili model M3, ki je bil načrtovan v orodju Activiti. Pri izvedbi
uvoza nismo imeli težav, saj orodje ni javilo nobene napake ali opozorila. Slika 4.12
prikazuje prenesen model M3 v orodje Signavio. Poimenovali smo ga M3 v Signavio.
Že na prvi pogled, lahko opazimo določene pomanjkljivosti. Najbolj izstopajo dogodki. Ne
glede na skupino - tj. začetni, vmesni (mejni) ali končni dogodki - večini manjka ustrezno
definiranje tipa. Signavio je tako vsem navedenim elementom definiral tip brez (ang.
none). V tem primeru vidimo, da ni prišlo zgolj do pomanjkanja informacij med prenosu
podatkov. Opazimo lahko drugačno interpretiranje in prilagajanje elementov. Menimo, da
je slednja situacija bolj ne zaželena, kot sama izguba elementa. Ta namreč sporoča, da
kljub temu, da so elementi preneseni, slednji v veliki meri niso pravilni. Od načrtovalca
oziroma uporabnika to zahteva dodatni čas in trud, saj je potrebno preveriti vsak element in
ga ustrezno popraviti in dopolniti. V tem primeru se ne moremo zanašati na pravilen
prenos elementov in izvesti zgolj dopolnjevanje z tistimi, ki niso preneseni.
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 113
Slika 4.12: Model M3 v orodju Signavio (M3 v Signavio)
Primer nepopolnega prenosa oziroma prilagajanja smo zasledili pri naslednji elementih:
Meja - čas - določen tip je brez, pravilni tip je čas.
Meja - signal - določen tip je brez, pravilni tip je signal.
Pošlji sporočilo - določen tip je storitev, pravilni tip je pošiljanje.
Prišlo je do napake - določen tip je brez, pravilni tip je napaka.
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 114
Zaporedno izvajanje opravili - manjka oznaka (ikona) za zaporedno izvajanje.
Opravilo predstavlja storitev - manjka oznaka (ikona) za vzporedno izvajanje.
Začetno sporočilo - določen tip je brez, pravilni tip je sporočilo.
Začetek časovnik - določen tip je brez, pravilni tip je časovnik.
Element Izvedi ročno ima določen tip brez, pravilni tip je človek. Prav tako
omenjeni element ne vsebuje lastnosti ponavljaje.
Element Opravilo1 ima pravilno določen tip, vendar nima definirane lastnosti
kompenzacija.
Vmesni dogodek ima določen tip brez. Pravilni tip je signal.
Elementi Tukaj lahko napišemo opombo, Vmesni dogodek - proženje tipa signal in
Vmesni dogodki (lovljenje), predstavljajo manjkajoče elemente, ki se niso prenesli
in so tipa opombe.
Vmesni dogodek (lovljenje) - določen tip je brez, pravilni tip je sporočilo.
Vmesni dogodek (lovljenje) - določen tip je brez, pravilni tip je časovnik.
Vmesni dogodek (lovljenje) - določen tip je brez, pravilni tip je signal.
Element Dogodkovni vzporedni, ki predstavlja prehod, je definiran s tipom
dogodkovni prehod. Pravilni tip je dogodkovni vzporedni prehod.
Izvedli smo tudi pregled skozi ocenjevalne kriterije. Izvorni model M3 vsebuje 33
elementov in 23 povezav. Pravilno se je preneslo zgolj 15 elementov, kar je manj kot
polovica. Pri tem smo vključili tudi tiste elemente, ki jim je manjkala kakšna lastnost (npr.
opravilo ni vključevalo in označilo, da se izvajanje slednjega ponavlja). Na področju
povezav je bil prenos uspešnejši. Izmed 23 definiranih povezav, je orodje Signavio
prikazalo 20 povezav. Prav tako so rezultati bili zadovoljivi za področje oblike elementov
in povezav. V splošnem so vsi preneseni gradniki ohranili svojo obliko. V kolikor
upoštevamo vredno pravilno prenesenih elementov, lahko podamo vrednost 15. Izkupiček
na področju oblike povezav je sto odstoten, saj pri nobeni povezavi nismo opazili
odstopanja, če gledamo iz grafičnega oziroma vizualnega vidika. Dosežena vrednost je 20.
Dobre rezultate na področju oblike elementov in povezav, pripisujemo podobnosti
grafičnih knjižnic orodij. Že iz primerjave slik modelov lahko opazimo, enak izbor barv in
način prikaza elementov. Podobno kot navedli pri obliki elementov, lahko navedemo pri
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 115
poimenovanju slednjih. Izmed 29 poimenovanih elementov izhodiščnega modela, jih ima
M3 v Signavio poimenovanih 26. Trije elementi, ki so bili poimenovani in se niso prenesli
predstavljajo tri elemente tipa opombe. V kolikor ponovno upoštevamo pravilnost
elementa kot celote, lahko v tem primeru gledamo zgolj 15 elementov, ki so pravilno
preneseni. Na podlagi te omejitve, lahko trdimo, da je pravilno poimenovanih 15
elementov. Izhodiščni M3 vsebuje eno poimenovano povezavo. Poimenovanje slednje se je
uspešno preneslo tudi v M3 v Signavio.
Izhodiščni indeks kakovosti modela znaša 142. Ob upoštevanju prej navedenih omejitev, tj.
upoštevanja zgolj nabora pravilno prenesenih elementov, M3 v Signavio doseže vrednost
86. To pomeni, da gre za 60,56% uspešnost. Zbrane ugotovitve in zabeležene rezultate, na
podlagi ocenjevalnih kriterijev, prikazuje Graf 4.10.
Graf 4.10: Ocenjevalni kriteriji za M3 v Signavio
Dobljen model M3 v Signavio smo poskušali shraniti oziroma izvoziti v datoteko. Orodje s
shranjevanjem ni imelo težav. Po izvedbi omenjenega procesa, nismo dobili obvestil o
napakah. Novonastala datoteka vsebuje 397 zapisov oziroma vrstic. Slednje je dokaj
zanimivo, saj jih ima izvorna datoteka 237. Odgovor zakaj je temu tako se skriva v uporabi
in vključevanju dodatnih atributov in informacij iz strani orodja Signavio. Tako že na
Številoelementov
Številopovezav
Oblikaelementov
Oblikapovezav
Poimenovanje
elementov
Poimenovanje povezav
Activiti 33 23 33 23 29 1
Signavio 15 20 15 20 15 1
0
5
10
15
20
25
30
35
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 116
začetku vsebine, kjer se nahajajo posamezne definicije dokumenta, zasledimo nekaj
dodatnih atributov. Na primer: podatke o orodju, verziji orodja, povezavo do XML shem
itd. Nekaj dodatnih atributov je tudi v sekciji, kjer je definirana grafična predstavitev
elementov. V tem delu smo na primer zaznali atribute, ki definirajo predstavitev napisa
elementa. Sama struktura in oblika vsebine datoteke je podobna kot v prejšnjih primerih,
zato se tukaj ne bomo podvajali.
4.6.9 M3 - Uvoz v YBE in ugotovitve
V zaključni fazi eksperimenta, nam je ostala še ena kombinacija. V tem koraku smo model
M3 uvozili v orodje YBE. Pri uvozu nismo naleteli na obvestila o napakah ali na
kakršnakoli druga obvestila. Slika 4.13 prikazuje dobljen zaslon oziroma uvoženi model, ki
smo ga poimenovali M3 v YBE.
Na prvi pogled opazimo podoben prikaz, kot smo ga videli pri M3 v Signavio. Zaznati je
moč odstopanja in napake. Prav tako je ponekod popačena oblika povezav, s čemer orodje
Signavio, ki smo ga uporabili v prejšnjem koraku, ni imelo težav. Ugotovili smo, da je
prišlo do kar nekaj napak in odstopanj pri prenosu, ki smo jih navedli v nadaljevanju.
Meja - čas - določen tip je brez, pravilni tip je čas.
Meja - signal - določen tip je brez, pravilni tip je signal.
Pošlji sporočilo - določen tip je storitev, pravilni tip je pošiljanje.
Prišlo je do napake - določen tip je brez, pravilni tip je napaka.
Zaporedno izvajanje opravili - manjka oznaka (ikona) za zaporedno izvajanje.
Opravilo predstavlja storitev - manjka oznaka (ikona) za vzporedno izvajanje.
Začetno sporočilo - določen tip je brez, pravilni tip je sporočilo.
Začetek časovnik - določen tip je brez, pravilni tip je časovnik.
Element Izvedi ročno ima določen tip brez, pravilni tip je človek. Prav tako
omenjeni element ne vsebuje lastnosti ponavljaje.
Element Opravilo1 ima pravilno določen tip, vendar nima definirane lastnosti
kompenzacija.
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 117
Vmesni dogodek ima določen tip brez. Pravilni tip je signal.
Elementi Tukaj lahko napišemo opombo, Vmesni dogodek - proženje tipa signal in
Vmesni dogodki (lovljenje), predstavljajo manjkajoče elemente, ki se niso prenesli
in so tipa opombe.
Vmesni dogodek (lovljenje) - določen tip je brez, pravilni tip je sporočilo.
Vmesni dogodek (lovljenje) - določen tip je brez, pravilni tip je časovnik.
Vmesni dogodek (lovljenje) - določen tip je brez, pravilni tip je signal.
Element Dogodkovni vzporedni, ki predstavlja prehod, je definiran s tipom
dogodkovni prehod. Pravilni tip je dogodkovni vzporedni prehod.
Element Klic aktivnosti ima tip podproces, pravilno tip je brez.
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 118
Slika 4.13: Model M3 v orodju YBE (M3 v YBE)
Ob upoštevanju naštetega se je pravilno preneslo 14 elementov, medtem, ko jih izhodiščni
model M3 vsebuje 33. Situacija in ugotovitve so na tem področju precej podobne
prejšnjemu koraku, kjer smo uvažali v Signavio. Razlika je v enem elementu tj. Klic
aktivnosti, ki je v Signavio pravilno definiran, med tem, ko v YBE ni. Na področju povezav
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 119
je orodje uspešno prikazalo 20 povezav. Manjkajoče tri so posledica, ne prikazovanja
elementov tipa opombe. Če primerjamo elemente in povezave iz vidika grafične
predstavitve ugotovimo, da je prišlo do razlik. Vsi pravilno preneseni elementi, so
primerno oblikovani, kar pomeni doseganje vrednosti 14. Zaznali pa smo manj natančno
prikazovanje povezav. Slednje je posledica tega, da orodje YBE uporablja drugačno
grafično knjižnico. Spremembe v definiranju oblike, vplivajo na detajle v prikazu. Na
podlagi ocenjevalnih kriterijev je M3 v YBE v omenjeni točki dosegel vrednost 12.
Omenimo, da tukaj govorimo predvsem o manjših odstopanjih od prikaza enake povezave
- na primer: povezava nima ravne linije, ko jo ima na izhodiščnem modelu. Slednje bo za
nekatere uporabnike zanemarljivo. Pri poimenovanju naletimo na enako stanje kot v
prejšnjem koraku. Tako kot Signavio je orodje YBE sicer pravilno poimenovalo vse
elemente, ki jih je uspešno preneslo - tj. 30. Vendar če upoštevamo zgolj tiste, ki pravilni
kot celota, lahko podamo vrednost oziroma oceno 14. Uspešno se je poimenovala tudi ena
povezava.
Graf 4.11: Ocenjevalni kriteriji za M3 v YBE
Graf 4.11 prikazuje grafični prikaz ugotovitev in vrednosti. Na podlagi slednjega lahko
podamo tudi zadnji ocenjevalni kriterij, ki podaja indeks uspešnosti. Indeks izhodiščnega
modela znaša 142. Pri izvedbi prenosa M3 v orodje YBE smo naleteli na največ
Številoelementov
Številopovezav
Oblikaelementov
Oblikapovezav
Poimenovanje elementov
Poimenovanje povezav
Activiti 33 23 33 23 29 1
YBE 14 20 14 12 14 1
0
5
10
15
20
25
30
35
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 120
pomanjkljivosti. Zaradi večjega števila zaznanih odstopanj, je model M3 v YBE dosegel
indeks 75. Slednji pove, da gre za 52,81% uspešnost.
Graf 4.12: Uspešnost prenosa M3 v Signavio in YBE
Graf 4.12 ponazarja vizualno predstavitev rezultatov, ki smo jih dobili z izvedbo
eksperimenta, pri katerem smo uporabili model M2 in izbrana orodja. Omogoča hitro
prepoznavanje odstopanj od izhodišča (Activiti). Prav tako pa imamo takojšnjo primerjavo
med rezultati iz posameznih orodij.
33
23
33
23
29
1
15
20
15
20
15
1
14
20
14 12
14
1
0
5
10
15
20
25
30
35
Številoelementov
Število povezav Oblikaelementov
Oblika povezav Poimenovanjeelementov
Poimenovanjepovezav
Activiti Signavio YBE
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 121
5 ZAKLJUČEK
Poglavje vsebuje zapisane končne ugotovitve. Podani so odgovori in sklici do informacij v
dokumentu. V zadnjem delu poglavja je zaključno besedilo oziroma sklep, ter predlogi in
smernice za nadaljnjo delo.
5.1 Analiza predpostavk in omejitev
Področje poslovnih procesov, modelov in diagramov je zelo široko in obsežno. V takšnem
primeru so omejitve potrebne in pogosta praksa pri delu na področju raziskovanja ali
opravljanja analiz. V poglavju 1.3 smo omejitve omenili in razložili. Če slednje na kratko
povzamemo in spomnimo kje je bilo potrebno ustvariti meje.
Omejitve smo sprejeli na področju:
Standardov - zanimal nas je standard oziroma notacija BPMN 2.0 (področje smo
opisali v poglavju 2.3).
Orodij - orodja so morala nuditi podporo izbranemu standardu, biti v slovenskem
ali angleškem jeziku in biti dosegljiva (npr: odprtokodna, možnost testiranja itd).
Izbrana orodja smo predstavili v poglavju 4.1.
Modelov (diagramov) - nemogoče je testirati vse možne kombinacije oz. vse
modele (diagrame), ki jih je moč sestaviti v izbranih orodjih. Ustvarili smo modele,
ki so nam zadostovali za izvedbo posebne oblike eksperimenta (opisani v poglavju
4.3).
Merjenja uspešnosti prenosa - postavk ali točk, ki jih bomo spremljali pri prenosu
informacij je veliko. Potrebno se je bilo omejiti. V ta namen smo tudi predstavili
ocenjevalne kriterije, ki smo jih predstavili v poglavju 4.5.
V poglavju 1.3 smo navedli tudi predpostavki. Lahko bi jih poimenovali tudi hipotezi.
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 122
Kompleksnost poslovnega procesa negativno vpliva na uspešnost uvoza poslovnega
procesa.
Na podlagi ugotovitev se s trditvijo delno strinjamo. V poglavju 4.6 opisujemo
izvedbo eksperimenta oziroma pridobivanja podatkov. S slednjim smo prišli do
ugotovitve, da imajo izbrana orodja že težave s prenosom in prikazom tistih
gradnikov, kateri so jim skupni. Na podlagi zbranih ugotovitev smo mnenja, da
višja kompleksnost modela negativno vpliva na prenos. Vendar, ker tega
neposredno nismo preverjali, slednjega ne moremo zagotovo trditi. Navajamo zgolj
iz izkušenj in znanja, ki smo ga pridobili v času izvajanja eksperimenta, ter uporabe
izbranih orodij.
Struktura/zgradba datoteke (ki nastane ob izvozu poslovnega procesa) nima vpliva
na uspešnost prenosa informacij.
Poglavja 4.6.1 do 4.6.9 opisujejo in navajajo zbrane ugotovitve o uspešnosti
prenosa izhodiščih modelov (poglavje 4.3) med izbranimi orodji (poglavje 4.1). V
sklopu analize, smo pregledali tudi sestavo na novo ustvarjenih datotek. Ugotovili
smo, da ni prišlo do večjih razlik v sami strukturi, kljub temu, da so različna orodja
ustvarjala datoteko, ki je hranila ustvarjen model (diagram). V primerih kjer je bilo
moč opaziti razlike, so bila odstopanja zanemarljiva. Na podlagi teh dejstev se
strinjamo s predpostavko in ocenjujemo, da struktura datoteke nima neposrednega
vpliva na uspešnost prenosa informacij. Opomba: struktura predstavlja obliko
sintakse oziroma izvorne kode datoteke. Število značk in atributov vpliva na
uspešnost prenosa.
5.2 Doseganje ciljev in pridobitev odgovorov na raziskovalna vprašanja
V izhodišču definiranja magistrske naloge smo si zadali cilje, ki jih z omenjeno nalogo
poskušamo doseči. Cilje smo opredelili v poglavju 1.2. Tabela 5.1 predstavlja obrazložitev,
kje v dokumentu se nahaja relevantna vsebina za posamezni cilj. Prav tako je ob
posameznem cilju naveden krajši komentar.
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 123
Tabela 5.1: Analiza ciljev magistrskega dela
Cilj Sklic (poglavje) Komentar
C1 2
Preučitev teorije, ki je relevantna za celotno
magistrsko nalogo, smo opravili v poglavju 2. V
sklopu podpoglavij smo podrobneje predstavili
določene segmente. Tako se informacije o
modeliranju procesov nahajajo v poglavju 2.1,
medobratovalnosti 2.2, BPMN 2.3 in tako naprej.
Ker je vsebina povezana in se informacije
prepletajo, izpostavljamo celotno poglavje 2.
C2 3
Poglavje 3 izpolnjuje cilj. V slednjem smo opravili
pregled obstoječih raziskav. Pridobili smo vpogled
v trenutno stanje in zbrali informacije, ki so se
nanašale na naše področje.
C3 2.4
V navedenem poglavju izpostavljamo datotečne
formate, ki jih najpogosteje zasledimo na področju
medobratovalnosti modelov procesov. Vsak format
smo v podpoglavjih na kratko predstavili.
C4
C5 4.6
V fazi kjer smo izvajali posebno obliko
eksperimenta, smo podali informacije o uspešnosti
preslikav oziroma prenosa informacij iz enega
orodja v drugega, preko ustvarjenih datotek.
Predstavili smo kateri elementi so se uspešno
prenesli in kateri ne. Analizirali smo tudi vsebino
datoteke, ter izpostavili ugotovitve za katere smo
ocenili, da so vredne omembe. Omenili smo
postavke, ki vplivajo na kvaliteto prenosa
informacij.
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 124
Cilj Sklic (poglavje) Komentar
C6 4.5
V poglavju opisujemo in navajamo ocenjevalne
kriterije, na podlagi katerih smo podajali oceno
uspešnosti prenosa informacij. Prav tako pa so nam
slednji omogočili prikaz ugotovitev v obliki
statističnih grafov itd.
V poglavju 1.4 smo zapisali in predstavili raziskovalna vprašanja. V sklopu raziskave in
pisanja magistrskega dela, smo poskušali priti do odgovorov. Tabela 5.2 navaja, kje v
dokumentu se nahaja relevantna vsebina, glede na raziskovalno vprašanje. Ob vsaki
vrednosti smo zapisali tudi krajši komentar.
Tabela 5.2: Analiza raziskovalnih vprašanj magistrskega dela
Raz. vpr. Sklic (poglavje) Komentar
RV1 2.4
Odgovor na vprašanje smo pridobili delno ob
pričetku dela in raziskav. Ker nas je že na
izhodišču zanimala notacija in standard BPMN,
smo se omejili znotraj te domene. Ob pregledu
literature smo vključili tiste standarde in
datotečne formate, ki smo jih zasledili
najpogosteje. Poglavje 2.4 opisuje omenjene
standarde in formate.
RV2 4.1
Ob pregledu orodij in selekciji le teh, smo
izbrali tri orodja, ki so nam bila dosegljiva.
Med izvedbo eksperimenta smo navajali tudi
možnosti izvoza modela oziroma smo navedli v
kakšne datotečne formate lahko izvozimo
ustvarjen model (poglavje 4.6).
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 125
Raz. vpr. Sklic (poglavje) Komentar
RV3 4.6
Z izvedbo posebne oblike eksperimenta smo
ugotovili, kateri elemente se uspešno prenesejo
in kateri ne. Predhodno opravljen analitični
pregled orodij (poglavje 4.2) nam je že podal
nekaj informacij o podrtosti, med tem, ko smo
z eksperimentom podali praktični primer. Prav
tako omenili različne dejavnike, ki najbolj
vplivajo na spremembe prenosa informacij. Na
tem mestu lahko izpostavimo predvsem dva.
Prvi je različen nabor značk in atributov
posameznih značk, ki hranijo informacije (več
pomeni natančnejše definiranje). Na drugi
strani pa imamo razlike v grafičnih knjižnicah
orodij, ki poskrbijo za nekatera odstopanja pri
prikazu.
RV4 4.5
Stopnjo prenosljivosti smo izmerili na podlagi
lastno ustvarjene lestvice, ki smo jo
poimenovali ocenjevalni kriteriji. S slednjo
smo pridobili vrednosti, s katerimi smo lahko
opravili primerjavo.
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 126
Raz. vpr. Sklic (poglavje) Komentar
RV5 4.6
Z izvedbo eksperimenta smo ugotovili kako se
elementi prenesejo, če jih uporabimo v
različnih izhodiščnih orodjih. Ugotovili smo,
da je bil prenos bolj uspešen, če je izhodiščni
diagram bil ustvarjen v orodju Signavio. Zaradi
različne podpore orodij, so izhodiščni modeli
oziroma diagrami bili različno kompleksni
oziroma so vsebovali različni nabor elementov.
Bolj kot vpliv kompleksnost, izpostavljamo
omejen nabor posameznih orodij. Ocenjujemo,
da je omenjena postavka glavni razlog, ki je
vplival na uspešen prenos ali prikaz modela.
RV6 4.2, 4.6
Ob sami izvedbi analitičnega pregleda
podprtosti elementov izbranega orodja
(poglavje 4.2) smo dobili vpogled kateri
gradniki in elementi so bolje podprti, kateri
manj. Tudi sam eksperiment je podal dodatne
informacije in vpogled o nivoju podpore
elementov oziroma iz drugega vidika, izgubah
elementov (poglavje 4.6).
5.3 Predlogi za nadaljnjo delo
Ker je področje obsežno ocenjujemo, da so določena področja dokaj neraziskana in manj
bogata z viri literature. Navedeno je prednost, saj je tako mogoče odkrivati nove stvari in je
moč priti do novi spoznanj. Področje je zanimivo, zato je smiselno raziskovati in analizirati
tudi v prihodnje. Sami smo bili primorani sprejeti določene omejitve. Te so bile na
področju verzij standarda, orodij, diagramov in ocenjevalnih kriterijev (poglavje 1.3).
Omenjeno pa se lahko z nadaljnjimi raziskavami in delom dopolni ali spremeni.
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 127
Smernic in predlogov za nadaljnjo delo je več, mi pa bomo navedli slednje.
1. Novejše različice orodij
Kot vemo se tehnologije in svet na splošno razvija. Vsi strmimo k izboljšanju in k
napredku. Na podlagi tega smo deležni novih različic orodij, ki bodo bolj
izpopolnjene oziroma bodo prinašale boljše rezultate.
2. Druga orodja
Tržišče omogoča uporabo produktov in rešitev različnih proizvajalcev. Imamo
možnost izbire različnih orodij, ki nam lahko za enako stvar nudijo različne
informacije.
3. Novejši standard
Ne razvijajo se samo tehnologije in orodja. Tudi pravila in standardi se
dopolnjujejo. Vpeljujejo se novosti in dodatne definicije, kar (običajno) pripelje do
izboljšanja.
4. Analiza nad izbranim orodjem
Uporaba izbranega orodja. Opravi se podrobnejši pregled in raziskava na področju
orodja. Izvede se analiza slednjega, ter posebna oblika eksperimenta, kjer se
pripravi določen nabor modelov (diagramov), ki bodo podali ugotovitve in
odgovore na vsa zastavljena vprašanja.
5. Druga smer
Raziskovalno delo pa lahko usmerimo v drugo smer. V našem primeru bi lahko na
primer opravili raziskavo na področju, kjer bi uporabili elemente, ki so pomembni
na primer za izvajanje procesov.
5.4 Sklep
Z raziskavo in pripravo magistrskega dela smo:
spoznali in preučili področje modeliranja ob uporabi standarda BPMN,
spoznali in preučili področje izmenjave modelov (diagramov) nastalih ob
upoštevanju standarda BPMN,
spoznali in preučili vrste zapisov informacij,
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 128
analizirali izbrana orodja in njihovo podporo elementov standarda BPMN 2.0,
izvedli eksperiment, ter praktično preverili uporabo orodij, modeliranje diagrama in
prenos le tega.
Ocenjujemo, da bo magistrsko delo v pomoč (predvsem):
osebam, ki iščejo primerno orodje za delo - modeliranje diagramov v BPMN,
osebam, ki bodo opravili analizo orodja, ki smo ga uporabili pri delu mi,
osebam, ki jih zanima področje izmenjave diagramov,
razvijalcem posameznih orodij namenjenih modeliranju v BPMN,
osebam, ki jih v splošnem zanima standard BPMN.
Ob koncu izpostavimo.
V času pisanja magistrskega dela, smo naleteli na uporaben vir, ki je namenjen področju
izmenjave diagramov oziroma modelov. Vir prihaja iz strani organizacije OMG in je nastal
na podlagi ustanovitve MIWG. Omenjeni vir smo analizirali in predstavili v poglavju 3,
kjer smo navedli rezultate pregleda literature. Vir želimo izpostaviti saj menimo, da zna
biti v veliko pomoč pri nadaljnjih raziskavah. Uporaben bo predvsem strokovnjakom, ki
skrbijo za razvoj posameznih orodij (skupina MIWG na svoji spletni strani navaja seznam
orodij), raziskovalcem, ki jih zanima sintaktično in semantično pravilen zapis informacij v
datoteke, ki hranijo ustvarjene modele, ter ne nazadnje osebam, ki sestavljajo modele,
diagrame, poslovne procese itd. z namenom izvajanja le teh.
Z izvedbo analitičnega pregleda izbranih orodij (poglavje 4.2) in izvedbo posebne oblike
eksperimenta (poglavje 4.6), smo ugotovili, da orodja, kljub navedbi upoštevanja
standarda, ne nudijo popolne podpore. Ugotovitve kažejo prednost orodju Signavio
(poglavje 4.1.1), ki se je odrezalo najboljše. Vendar mu popolnosti ne pripisujemo, saj
rezultati niso bili sto-odstotni. Z nekoliko več odstopanja mu sledi orodje YBE (poglavje
4.1.2). Medtem, ko se je orodje Activiti (poglavje 4.1.3) odrezalo precej slabše. Menimo,
da bi se situacija ponovila tudi na drugih orodjih in uporabi drugih testnih primerov - torej,
če bi izbrali druga orodja in spremenjen testni model. Navedeno je tudi lahko morebiten
predlog za možnost izvedbe nadaljnjega dela in raziskav.
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 129
Če poskušamo naše ugotovitve posplošiti na trenutno stanje in preostala orodja, bi dejali,
da orodje s popolno podporo ne obstaja. Če povemo drugače, menimo, da na tržišču še ni
orodij za načrtovanje diagramov v BPMN, ki bi bile zmožne medsebojno izmenjati
informacije, brez dodatnega dela in sredstev, ter omogočiti nemoteno nadaljevanje dela.
Trdimo, da bo prilagajanje še vedno potrebno in prisotno. V kakšni meri bo slednje
potrebno, je seveda odvisno od uporabljenih orodij. Odvisno pa je tudi od subjektivne
ocene. Pomembno bo tudi dejstvo, kje postaviti mejo, da je določen prenos še sprejemljiv
oziroma ne. Omenjene meje pa bodo uporabniki določili sami.
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 130
6 LITERATURA
[1] “Kompatibilnost.” [Online]. Available: http://hr.wikipedia.org/wiki/Kompatibilnost.
[Accessed: 28-Oct-2014].
[2] “Computer compatibility.” [Online]. Available:
http://en.wikipedia.org/wiki/Computer_compatibility. [Accessed: 28-Oct-2014].
[3] “Forward compatibility.” [Online]. Available:
http://en.wikipedia.org/wiki/Forward_compatibility. [Accessed: 28-Oct-2014].
[4] “Backward compatibility.” [Online]. Available:
http://en.wikipedia.org/wiki/Backward_compatibility. [Accessed: 28-Oct-2014].
[5] IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer
Glossaries, 610. 1990.
[6] G. Polančič, “COBIT 4.1.” [Online]. Available:
http://www.slideshare.net/grepol/gregor-polancic-cobit. [Accessed: 03-Jun-2013].
[7] Polančič Gregor; Živkovič Aleš, “Modeliranje poslovnih procesov z notacijo
BPMN,” 2010.
[8] G. Polančič, “Modeliranje poslovnih procesov z notacijo BPMN 1.2,” 2011.
[9] S. Kolmanič, “Modeliranje in simulacija.” [Online]. Available: http://graph-srv.uni-
mb.si/cgai/slo/Ares/Modeliranje in simulacija.pdf. [Accessed: 21-Feb-2014].
[10] “Business Process Modelling - Business Process Models examples, diagrams,
history, development and explanation.” [Online]. Available:
http://www.businessballs.com/business-process-modelling.htm. [Accessed: 03-Jun-
2013].
[11] “What is interoperability?” [Online]. Available:
http://www.businessdictionary.com/definition/interoperability.html. [Accessed: 31-
Jan-2014].
[12] “Interoperabilnost | Interoperabilna hrbtenica.” [Online]. Available:
http://nio.ezdrav.si/?page_id=94. [Accessed: 31-Jan-2014].
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 131
[13] OMG, “Business Process Model and Notation (BPMN),” 2011.
[14] OMG, “BPMN 2.0 Specifiacations.” [Online]. Available:
http://www.omg.org/spec/BPMN/2.0/PDF/. [Accessed: 21-Feb-2014].
[15] B. Silver, BPMN Method and Style, 2nd Edition, with BPMN Implementer’s Guide.
Cody-Cassidy Press (October 17, 2011), 2011, p. 286.
[16] D. Gagne, “BPM Standards - What is new in BPMN 2.0 and XPDL 2.2 (BBC
2011).” [Online]. Available: http://www.slideshare.net/dgagne/bpm-standards-what-
is-new-in-bpmn-20-and-xpdl-22-bbc-2011. [Accessed: 12-Nov-2014].
[17] B. D.o.o., “BPMN.” [Online]. Available:
http://www.bpmlab.si/index.php?Itemid=65&catid=43:modeliranje&id=72:bpmn&o
ption=com_content&view=article. [Accessed: 05-Jun-2013].
[18] “XML Schema (W3C).” [Online]. Available:
http://en.wikipedia.org/wiki/XML_Schema_(W3C). [Accessed: 24-Feb-2014].
[19] “OMG: BPMN 2.0 - BPMN20.xsd.” [Online]. Available:
http://www.omg.org/spec/BPMN/20100501/BPMN20.xsd. [Accessed: 24-Feb-
2014].
[20] K. Mertins, F. Bénaben, R. Poler, and J.-P. Bourrières, Enterprise Interoperability
VI: Interoperability for Agility, Resilience and Plasticity of Collaborations. Springer
Science & Business Media, 2014, p. 539.
[21] “Datoteka.” [Online]. Available: http://sl.wikipedia.org/wiki/Datoteka. [Accessed:
20-Jun-2013].
[22] “XML - Wikipedija, prosta enciklopedija.” [Online]. Available:
http://sl.wikipedia.org/wiki/XML. [Accessed: 24-Feb-2014].
[23] “Extensible Markup Language (XML).” [Online]. Available:
http://en.wikipedia.org/wiki/XML. [Accessed: 24-Feb-2014].
[24] “XPDL.” [Online]. Available: http://en.wikipedia.org/wiki/XPDL. [Accessed: 25-
Jun-2013].
[25] “XPDL.org.” [Online]. Available: http://www.xpdl.org/index.html. [Accessed: 25-
Jun-2013].
[26] “XPDL BPMN Example 1.” [Online]. Available:
http://www.xpdl.org/nugen/p/xpdlbpmnexample1/public.htm. [Accessed: 25-Jun-
2013].
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 132
[27] “.VSD (Microsoft Visio).” [Online]. Available: http://en.wikipedia.org/wiki/.vsd.
[Accessed: 26-Jun-2013].
[28] “Podatke, informacija, znanje.” [Online]. Available: http://colos.fri.uni-
lj.si/eri/RACUNALNISTVO/INFORMATIKA/podatke_informacija_znanje.html.
[Accessed: 28-Jun-2013].
[29] “Informacija.” [Online]. Available: http://sl.wikipedia.org/wiki/Informacija.
[Accessed: 28-Jun-2013].
[30] S. Košti, “Interoperabilna prihodnost,” 2010. [Online]. Available:
http://www.monitorpro.si/si/_detajl/?id=41186.
[31] R. Ben Salem, R. Grangel, and J. P. Bourey, “A comparison of model
transformation tools: Application for Transforming GRAI Extended Actigrams into
UML Activity Diagrams,” Computers in Industry, vol. 59, no. 7, pp. 682–693, 2008.
[32] S. N. Pawar, “BPMN tools---a comparative analysis to improve interoperability,”
Purdue University, 2011.
[33] B. Silver, Executable BPMN. BPMN method & style. 2009.
[34] R. M. Shapiro, “XPDL 2.1 - Integrating Process Interchange & BPMN,” 2008.
[35] “BPMN Tools tested for Model Interchange.” [Online]. Available: http://bpmn-
miwg.github.io/bpmn-miwg-tools/. [Accessed: 12-Sep-2014].
[36] “Signavio,” Wikipedia, the free encyclopedia. .
[37] “SaaS vs. On-Premise | Signavio.” [Online]. Available:
http://www.signavio.com/products/process-editor/saas-vs-on-premise/. [Accessed:
29-Jan-2014].
[38] “User:Blenta/Yaoqiang BPMN Editor - Wikipedia, the free encyclopedia.” [Online].
Available: http://en.wikipedia.org/wiki/User:Blenta/Yaoqiang_BPMN_Editor.
[Accessed: 30-Jan-2014].
[39] “Yaoqiang BPMN Editor | Free software downloads at SourceForge.net.” [Online].
Available: http://sourceforge.net/projects/bpmn/. [Accessed: 30-Jan-2014].
[40] “Activiti.” [Online]. Available: http://www.activiti.org/. [Accessed: 06-Feb-2014].
[41] “Activiti (software) - Wikipedia, the free encyclopedia.” [Online]. Available:
http://en.wikipedia.org/wiki/Activiti_(software). [Accessed: 06-Feb-2014].
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 133
[42] “BPMNPoster – www.bpmb.de.” [Online]. Available:
http://www.bpmb.de/index.php/BPMNPoster. [Accessed: 06-Feb-2014].
[43] “Z-order.” [Online]. Available: http://en.wikipedia.org/wiki/Z-order. [Accessed: 24-
Feb-2014].
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 134
7 PRILOGE
A. BPMN 2.0 elementi
Priloga vsebuje nabor elementov, ki jih najpogosteje zasledimo in uporabimo pri
modeliranju modelov oziroma načrtovanju diagramov. Najprej so navedeni osnovni
elementi (Tabela 7.1), nato sledi še razširjen nabor (Tabela 7.2).
Tabela 7.1: Seznam osnovnih elementov namenjenih modeliranju
Element Opis Notacija
Dogodek
(ang. event)
Je nekaj kar se zgodi v času
izvajanja poslovnega procesa.
Dogodki vplivajo na tok
izvajanja in imajo po navadi
vzrok - prožilec (ang. cause -
trigger) in vpliv - posledico ali
rezultat (ang. impact - result).
BPMN definira tri tipe
dogodkov, katere ločimo glede
na mesto v poslovnem procesu
- začetni (ang. start), vmesni
(ang. intermediate) in končni
(ang. end).
Aktivnost
(ang. activity)
Aktivnost je generični izraz za
delo, ki se zgodi oziroma
izvede v procesu. Tipi
aktivnosti, ki so del procesa
modela sta: pod-proces (ang.
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 135
Element Opis Notacija
sub-process) in opravilo (ang.
task), ki predstavljena z
zaobljenim pravokotnikom.
Aktivnosti se uporabljajo pri
standardnih procesih in
koreografijah.
Prehod
(ang. gateway)
Uporablja se za nadzor
divergence in konvergence toka
zaporedja v procesu in
koreografiji. Določa vejitev
(ang. branching), razcepitev
(ang. forking), združevanje
(ang. merging) in pridruževanje
(ang. joining) poti.
Tok zaporedja
(ang. sequence flow)
Tok zaporedja se uporablja za
prikaz zaporedja aktivnosti, ki
se bodo izvedla v procesu.
Tok sporočila
(ang. message flow)
Uporabimo, da toku sporočimo,
da je sporočilo med dvema
udeležencema (ang.
participants) pripravljeno na
pošiljanje (ang. send) ali
sprejem (ang. receive).
Tok asociacije /
asociacija
(ang. association)
Namenjena je ustvarjanju
povezave med predmeti in
BPMN elementi. Na primeri
element opomba lahko
povežemo k določenemu
grafičnemu elementu. Puščica
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 136
Element Opis Notacija
na asociaciji pove smer toka.
Bazen
(ang. pool)
Pri sodelovanju (ang.
collaboration) predstavlja
grafično upodobitev
udeleženca. V procesu ima tudi
vlogo "steze" in grafičnega
zabojnika, ki vsebuje niz
aktivnosti.
Steza
(ang. lane)
Steza je pod-razdelek (ang.
sub-partition) znotraj bazena v
procesu ali kot ločeno
grupiranje elementov v
preprostem procesu. Steze
organizirajo in kategorizirajo
aktivnosti. Pogosto se
uporabljajo za določitev
notranjih vlog (na primer:
vodja, partner), sistemov (na
primer: določena programska
aplikacija, ki je del
informacijskega sistema v
podjetju) ali zunanjih oddelkov
(na primer: finance, oddelek za
odpremo).
Podatkovni objekt
(ang. data object)
Podatkovni objekti nimajo
neposrednega vpliva na tok
zaporedja ali tok sporočila v
procesu. V procesu
zagotavljajo informacije na
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 137
Element Opis Notacija
primer kako so dokumenti,
podatki ali drugi objekti
uporabljeni ali kako so se
spremenili v času izvajanja
procesa. Podatkovni objekti
lahko zagotovijo informacije,
ki so potrebne ali pa so izhodni
rezultat procesa. Predstavljajo
lahko različen tip objekta -
lahko je v elektronski ali fizični
obliki. Prav tako lahko
predstavljajo samostojni objekt
ali zbirko objektov.
Sporočilo
(ang. message)
Uporablja se za preslikavo
vsebine komunikacije, ki je
med dvema udeležencema.
Skupina
(ang. group)
Skupina predstavlja grupiranje
grafičnih elementov, ki
pripadajo skupni kategoriji
oziroma zbirki. Omenjena
zbirka ne vpliva na tok
zaporedja. Grupiranje
elementov se lahko uporabi za
potrebe dokumentacije ali
analize.
Opomba / beležka
(ang. text
annotation)
Predstavljajo mehanizem, ki ga
uporablja načrtovalec procesa,
ko hoče priskrbeti dodatne
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 138
Element Opis Notacija
informacije v obliki teksta.
Opombe ali beležke, kot lahko
poimenujemo mehanizem, so v
veliko pomoč bralcu
poslovnega procesa, saj
pripomorejo k boljšemu
razumevanju le tega.
Tabela 7.2 vsebuje razširjeni nabor elementov. Za potrebe modeliranja vseh zahtevnosti
procesov, osnovni nabor ni zadostoval. V omenjeno tabelo smo vključili dodatne elemente,
ter dodatne različice elementov, ki se že nahajajo v Tabela 7.1.
Tabela 7.2: Razširjeni seznam elementov namenjenih modeliranju
Element Opis Notacija
Dimenzije toka
(ang. flow dimension)
Začetna (ang. start),
vmesna (ang.
intermediate), končna
(and. end).
Začetna
Navaja kje se bo specifični
proces ali koreografija
začela.
Vmesna
Se nahaja med začetnim in
končnim elementom. Vpliva
na tok izvajanja, vendar ga
ne more pričeti oziroma
končati.
Končni
Navaja kje se bo proces ali
koreografija končala
oziroma zaključila.
Začetni
Vmesni
Končni
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 139
Element Opis Notacija
Dimenzije tipa
(ang. type dimension)
Brez (ang. none),
sporočilo (ang.
message), časovnik
(ang. timer), napaka
(ang. error), preklic
(ang. cancel),
kompenzacija (ang.
compensation),
pravilo/pogoj (ang.
conditional), povezava
(ang. link), signal
(ang. signal),
večkratno (ang.
multiple), prekinitev
(ang. terminate).
Začetni in nekateri vmesni
dogodki imajo "prožilce", ki
podajo namen dogodka.
Obstajajo številne možnosti
kako se ti dogodki sprožijo.
Končni dogodki lahko
definirajo "rezultat", ki je
posledica konca toka
zaporedja. Začetni dogodki
lahko reagirajo samo na
lovljenje (ang. catch)
prožilca. Končni dogodki
lahko ustvarijo (ang. throw)
samo rezultat. Vmesni
dogodki lahko prožijo in
lovijo prožilce. Gradniki
bodo prazni kadar gre za
lovljenje, ter polno
pobarvani, kadar gre za
proženje.
Obroba nekaterih dogodkov
je črtkana, kar pomeni, da
omenjeni element ne bo
prekini aktivnosti.
Opravilo
(ang. task)
Opravilo je vrsta aktivnosti
v procesu. Uporabi se takrat,
kadar "dela" ni mogoče
razbiti na manjše dele.
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 140
Element Opis Notacija
Opravilo koreografije
(ang. choreography
task)
Predstavlja eno ali več
izmenjav sporočila. Vsako
opravilo vključuje dva
udeleženca.
Proces/pod-proces
(ang. proces/sub-
process)
Pod-proces je sestavljena
aktivnost, ki je lahko del
procesa ali koreografije.
Aktivnost je sestavljene
tako, da jo je mogoče
razčleniti na več aktivnosti.
Naslednji štirje elementi
predstavljajo posamezne tipe
pod-procesov.
Zaprti pod-proces
(ang. collapsed sub-
process)
Podrobnosti pod-procesa
niso vidne v diagramu.
Gradnik vsebuje simbol
"plus", kar pomeni, da je
aktivnost pod-proces in da
vsebuje oziroma združuje
niz aktivnosti.
Odprt (tudi razširjeni)
pod-proces
(ang. expanded sub-
process)
Obroba (tudi meja) pod-
procesa je razširljiva.
Znotraj meje so navedeni
vsi elementi in podrobnosti
pod-procesa. Opomba: tok
zaporedja ne more pričkati
obrobe pod-procesa.
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 141
Element Opis Notacija
Zaprta pod-kategorija
(ang. collapsed sub-
choreograaphy)
Podrobnosti, ki jih
opredeljuje pod-kategorija,
niso vidne v diagramu. Znak
"plus", ki je naveden pod
imenom opravila,
simbolizira pomen pod-
procesa. Prav tako opozarja,
da element združuje določen
niz aktivnosti.
Odprta (tudi
razširjena) pod-
kategorija
(ang. expanded sub-
choreography)
Obroba (tudi meja) je
razširljiva. Znotraj meje se
nahajajo elementi, ki jih
pod-koreografija vsebuje, ki
so vidni. Opomba: tok
zaporedja ne more prečkati
meje pod-kategorije.
Kontrolni tipi prehoda
(ang. gateway control
types)
Ikona (simbol), ki se nahaja
v elementu prehoda, določa
tip. Slednji definira potek
toka. Na voljo so naslednji
tipi:
Ekskluzivni (ang. exclusive)
prehod je lahko predstavljen
z ali brez simbola "X".
Dogodkovni (ang. event-
based) in vzporedno
dogodkovni (ang. parallel
event-based) prehod lahko
ustvari novo instanco
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 142
Element Opis Notacija
procesa.
Vključitveni (ang. inclusive)
prehod in združevanje.
Kompleksni (ang. complex)
prehod za kompleksne
pogoje in situacije.
Vzporedni (ang. parallel)
prehod za vejitve in
združevanje toka.
Normalni tok
(ang. normal flow)
Označuje tisti tok toka
zaporedja, ki se ne prične na
vmesnem dogodku, ki je
pritrjen na obrobo
aktivnosti.
Nekontroliran tok
(ang. uncontrolled
flow)
Označuje tisti tok, ki ni bil
označen z nobenimi pogoji
ali ni šel skozi noben
prehod. Najpreprostejši
primer je tok zaporedja med
dvema aktivnostma.
Kontroliran/pogojni
tok
(ang. conditional
flow)
Tok zaporedja lahko ima
pogojni izraz, ki se ga skozi
proces preverja. V kolikor
bo kontroliran tok prišel iz
aktivnosti, bo imel na
začetku povezave simbol
"diamanta". V kolikor bo
prišel iz prehoda,
omenjenega simbola ne bo.
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 143
Element Opis Notacija
Privzeti tok
(ang. default flow)
Za podatkovne ekskluzivne
prehode (ang. data-based
exclusive gateway) ali
vključitvene prehode, je en
kontroliran tok označen kot
privzeti tok. Slednji se
uporabi kadar noben pogoj
ni izpolnjen.
Tok izjeme
(ang. exception flow)
Se pojavi izven normalnega
toka, ki se nahaja v procesu.
Izhodišče toka izjeme je
vmesni element (ang.
intermediate event), ki je
pritrjen na mejo (obrobo)
aktivnosti.
Kompenzacijska
asociacija
(ang. compensation
association)
Se pojavi izven normalnega
toka, ki se nahaja v procesu.
Izhodišče toka
kompenzacijske asociacije
je vmesni element
kompenzacije (ang.
compensation intermediate
event). Slednji je prožen z
napako transakcije ali pa ga
proži dogodek kompenzacije
(ang. compensation event)
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 144
Element Opis Notacija
Podatkovni objekt
(ang. data object)
Podatkovni objekti
zagotavljajo informacije o
tem, kar aktivnosti
potrebujejo za izvajanje
in/ali kar ustvarjajo.
Podatkovni objekt lahko
predstavlja en objekt ali
zbirko objektov (ang.
collection). Vhodni podatki
(ang. data input) in izhodni
podatki (ang. data output)
zagotavljajo enake
informacije za proces.
Razcep
(ang. fork)
Zasledimo tudi izraz:
Razcep-IN
(ang. AND-Split)
BPMN uporablja izraz
razcep za delitev poti na dva
ali več vzporednih poti.
Uporabi se v delu procesa,
kjer je vzporedno izvajanje
aktivnosti bolj primerno kot
zaporedno.
Na voljo sta dve opciji:
Številni izhodni toki
zaporedja (ang. multiple
outgoing sequence
flows) - zgornja notacija.
Predstavlja, da je
"nekontrolirani" tok
najbolj primeren za
večino situacij.
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 145
Element Opis Notacija
Vzporedni prehod (ang.
parallel gateway) -
spodnja notacija.
Uporablja se redkeje.
Običajno v kombinaciji z
drugimi prehodi.
Pridružitev
(ang. join)
Zasledimo tudi izraza:
Pridružitev-AND ali
sinhronizacija
(ang. AND-Join or
synchronization)
BPMN uporablja izraz
pridružitev za združevanje
dveh ali več vzporednih
poti, v eno pot.
Vzporedni prehod (ang.
parallel gateway) je
uporabljen za ponazoritev
pridruževanja številnih
tokov zaporedja.
Odločitev, točka
vejitve
(ang. decision,
branching point)
Odločitve so prehodi, ki
nahajajo v procesu ali
koreografiji. Tok lahko v
takšni točki izbere eno ali
več alternativnih poti.
Predstavljeno v naslednjih
petih elementih.
Ekskluzivni
(ang. exclusive)
Odločitev predstavlja točko
vejitve, kjer alternative
temeljijo na pogojnem
izrazu, ki ga vsebuje izhodni
tok zaporedja. Izbrana bo
samo ena izmed alternativ.
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 146
Element Opis Notacija
Dogodkovni
(ang. event-based)
Odločitev predstavlja točko
vejitve, ker alternative
temeljijo na dogodku, ki se
pojavi v tisti točki procesa
ali koreografije. Specifični
dogodek (običajno
sprejemnik sporočila)
določa katera pot bo
izbrana. Na voljo so različni
tipi dogodka, ki jih lahko
uporabimo (npr. časovnik).
Izbrana bo samo ena izmed
alternativ, ki so na voljo.
Na voljo sta dve možnosti
za sprejem sporočila:
Uporabi se opravilo tipa
sprejem (ang. receive) -
zgornja notacija.
Uporabi se vmesni
dogodek tipa sporočilo -
spodnja notacija.
Vključitveni
(ang. inclusive)
Odločitev točko vejitve, kjer
alternative temeljijo na
pogojnem izrazu, ki ga
vsebuje izhodni tok
zaporedja. Na nek način
predstavlja grupiranje
povezanih samostojnih
binarnih (da/ne) odločitev.
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 147
Element Opis Notacija
Ker je vsaka pot neodvisna,
je možna uporaba vseh poti
ali nobene. Pravilno
načrtovanje predvideva
uporabo vsaj ene poti. Da
dosežemo omenjeni pogoj,
lahko nastavimo privzeti
pogoj.
Obstajata dve možnosti za
tovrstni tip odločitve:
Prva uporablja zbirko
pogojnih tokov
zaporedja - zgornja
notacija.
Druga uporablja
vključitveni prehod -
spodnja notacija.
Združevanje
(ang. merging)
Zasledimo tudi izraz:
Združevanje-ALI
(ang. OR-Join)
BPMN uporablja izraz
združevanje za ekskluzivno
združevanje dveh ali več
poti v eno.
Prehod ekskluzivnega
združevanja se uporablja za
prikaz združevanja številnih
tokov zaporedja - zgornja
notacija.
Če so vsi vhodni toki
alternativni, potem prehod
ni potreben - nekontroliran
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 148
Element Opis Notacija
tok se obnaša enako
(notacija spodaj).
Ponavljanje
(ang. looping)
BPMN omogoča dva
mehanizma za izvedbo
ponavljanja v procesu.
Opisano v naslednjih dveh
vrsticah tabele.
Ponavljanje aktivnosti
(ang. activity looping)
Atribut v opravilu ali pod-
procesu bo opredelil, ali se
slednji izvede enkrat ali
večkrat. Obstajata dve
različici ponavljanja:
standardna ali večkratna.
Notacija vsebuje simbol, ki
označuje da se element
izvede večkrat.
Ponavljanje toka
zaporedja
(ang. sequence flow
looping)
Ponavljanje in zanke lahko
dosežemo, z povezovanjem
toka zaporedja na prejšnji
element (ang. "upstream"
object).
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 149
Element Opis Notacija
Večkratne instance
(ang. multiple
instances)
Atribut v opravilu ali pod-
procesu bo opredelil, ali se
slednji izvede enkrat ali
večkrat. Niz treh
horizontalnih črt določa
zaporedne (ang. sequential)
večkratne instance, med tem
ko niz treh vertikalnih črt
določa vzporedne (ang.
parallel) večkratne instance.
Procesna prekinitev
(ang. proces break)
Procesna prekinitev je
mesto v procesu, kjer je
opredeljena zakasnitev.
Vmesni dogodek bo
prikazoval dejansko
obnašanje.
Transakcija
(ang. transacition)
Transakcija je pod-proces s
posebnim protokolom.
Slednji določa, da se vsi
vključeni strinjajo z
odločitvijo izvajanja
aktivnosti (npr. aktivnost je
prekinjena). Atribut
aktivnosti opredeljuje ali
aktivnost predstavlja
transakcijo. Dvojna polna
obroba elementa ponazarja,
da je pod-proces transakcija.
Medobratovalnost rešitev za modeliranje poslovnih procesov v BPMN Stran 150
Element Opis Notacija
Povezava izven strani
(ang. off-page
connector)
Objekt prikazuje kje tok
zaporedja zapusti stran in
kje se nahaja na drugi.
Vmesni dogodek povezava
lahko služi kot povezava
izven strani.