modeliranje poslovnih procesov v bpmn · 2017. 11. 28. · medobratovalnost rešitev za modeliranje...

Smetanova ulica 17

2000 Maribor, Slovenija

Goran Graf

MEDOBRATOVALNOST REŠITEV ZA

MODELIRANJE POSLOVNIH PROCESOV V

BPMN

Magistrsko delo

Maribor, februar 2015

I



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.

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



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].


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.


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.


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


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.


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.


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).


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:


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.


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


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


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


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).


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].


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.


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"/>


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


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:


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.


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


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


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.


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.


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


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,


Elementi Atributi


Timer catching event id, name, timerEventDefinition

Timer boundary event id, name, timerEventDefinition,


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,


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.


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,



callActivity id, name, calledElement, ioSpecification,



Elementi Atributi


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,


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


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


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


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.


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].


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.


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.


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


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

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


<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">



</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


ž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


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"/>


</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">



</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


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)


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



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.


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


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:


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),


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


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.


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.


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.


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).


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.


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.


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.


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.


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) •


Č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)

• •


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 Povezava (ang.

link) • •


• • •

Večkratno (ang.

multiple) • •

Večkratno

vzporedno (ang.

parallel mutiple)

• •

Mejni

(prekinitveni) (ang.

boundary

interrupting)

Analitični Sporočilo (ang.

message) • •


Analitični Časovnik (ang.

timer) • • •

Eskalacija (ang.

escalation) • •


• • •

Analitični,

skupno

izvedljivi

Napaka (ang. error)

• •

Preklic (ang.

cancel) •

Kompenzacija (ang.

compensation) • •


• • •

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) • •


• •



• •

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) • •


escalation) • •

Analitični Povezava (ang.

link) • •

Kompenzacija (ang.



• • •

Večkratno (ang.

multiple) • •

Končni dogodki

(ang. end events)

Standardni (ang.

standard)

Opisni,

analitični,

skupno

izvedljivi

Standardni (ang.

general - none) • • •


Opisni,

analitični,

skupno

izvedljivi

Sporočilo (ang.

message) • •


escalation) • •

Analitični Napaka (ang. error)

• • •

Preklic (ang.

cancel) •

Kompenzacija (ang.



• •

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) • • •


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)


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)


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)


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)

•


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


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.


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


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


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%


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.


YBE.


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:


35 elementov,

26 povezav,

31 poimenovanih elementov in

2 poimenovani povezavi.

Slika 4.4: Model M1


4.3.2 Model 2

Slika 4.5 predstavlja diagram M2, ki smo ga ustvarili v orodju YBE.


34 elementov,

22 povezav,


1 poimenovano povezavo.

Slika 4.5: Model M2


4.3.3 Model 3

Slika 4.6 predstavlja diagram M3, ki smo ga ustvarili v orodju Activiti.


33 elementov,

23 povezav,


1 poimenovano povezavo.

Slika 4.6: Model M3


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.


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


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.


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.


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)

PDF

Signavio archive (SGX)

BPMN 2.0 XML

XPDL 2.1

ARIS markup language


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


<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>


<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


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


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


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">


</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.


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=""/>


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


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"/>




</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


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)


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,


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


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


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">


<bpmndi:BPMNLabel>



</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


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)


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


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.


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


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:signavioLabel ref="text_name" valign="middle" x="17.0" y="-21.0"/>


<outgoing>sid-DB3C97BB-6B52-4A7E-810A-29F0C6B62817</outgoing>

</startEvent>


<startEvent id="sid-A87EAD52-E252-4341-BCDC-DF826EB8CDCD" isInterrupting="true" name="začetno

sporočilo">

<extensionElements>


<signavio:signavioMetaData metaKey="viaitsystem" metaValue=""/>


<signavio:signavioLabel bottom="false" left="false" ref="text_name" right="false" top="true"

valign="bottom" x="15.0" y="-8.0"/>


<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>




<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).


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.


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

.pdf

.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


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.


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


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


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.


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


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.


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.


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


YBE 34 22 34 22 31 1

Activiti 23 17 23 2 24 1

0

5

10

15

20

25

30

35

40


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

.pdf

.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



Poimenovanjepovezav

YBE Signavio Activiti


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


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


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.


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.


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


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


Activiti 33 23 33 23 29 1

Signavio 15 20 15 20 15 1

0

5

10

15

20

25

30

35


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.


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.


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


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


Activiti 33 23 33 23 29 1

YBE 14 20 14 12 14 1

0

5

10

15

20

25

30

35


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



Poimenovanjepovezav

Activiti Signavio YBE


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.


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.


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.


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).



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.



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.


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,


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.


Č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.


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].


[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].


[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.


[29] “Informacija.” [Online]. Available: http://sl.wikipedia.org/wiki/Informacija.


[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].


[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].


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.



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



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



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



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


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



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.



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.



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



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.



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)



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.



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)


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.



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.



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)


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



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).



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.



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.

modeliranje poslovnih procesov v bpmn · 2017. 11. 28. · medobratovalnost rešitev za modeliranje...

Documents