Utveckling av ramverk för editering och simuleringav BPMN

(1)

Utveckling av ramverk för editering och simulering av BPMN

Erik Eldh

eeldh@kth.se Johan Pettersson johapet@kth.se Handledare: Farzad Kamrani

Examinator: Rassul Ayani 22 september 2010

(2)

Sammanfattning

Business Process Modelling Notation (BPMN) är ett sätt att graskt rita upp ett diagram för en aärsprocess. Ett BPMN-diagram består av era olika så kallade ödesobjekt (eng. ow objects). Dessa är sammanlänkade i diagramet via sekvensöden (eng. sequence ows). Dessa diagram är endast graska representationer för aärsprocessen och det nns ett behov av att kunna simulera dessa diagram för olika ändamål. Den simulering som idag nns tillgänglig för BPMN är att diagrammet utvärderas genom att kontrollera om det är giltigt. För att evaluera dessa diagram mer precist har specikationen av vår uppdragsgivare utvidgats för att innefatta arbetare (eng. agents) och uppgifter (eng. tasks). Genom att på detta sätt simulera diagrammet och erhålla data för de olika attributen denierade för arbetarna och uppgifterna kan slutsatser dras om vilken tilldelning som är den mest optimala.

För att kunna designa och simulera ett ödesdiagram enligt BPMN- specikationen implementerades en editor och simulator i Java. Simulatorn är implementerad enligt principen diskret händelsestyrd simulering (DHS).

Då ödet når ett ödesobjekt exekveras den vilket bland annat innebär att framtida händelser eventuellt genereras och läggs till i framtida händelsekön.

Simulatorn fortsätter exekveringen genom att den framtida händelse med närmast tid exekveras. På detta sätt traverserar simulatorn diagramet tills händelsekön är tom vilket är då ödet nått en sluthändelse.

Då det i programmet är möjligt att moddelera BPMN-diagram enligt egna preferenser kan ett stort antal olika diagram simuleras. BPMN-diagram modellerade i andra program som exporterats enligt XPDL-standarden kan även laddas.

Programmet med simulator och editor evaluerades med två olika modeller och optimeringsalgoritmer. Det resultat som erhölls av dessa simuleringar skilde sig ej från det förväntade resultatet.

(3)

Abstract

Business Process Modelling Notation (BPMN) is a way to graphically draw a diagram of a business process. A BPMN diagram consists of several so-called

ow objects. These are interconnected in the graph through sequence ows.

BPMN models are merely graphical representations of business process and there is a need to simulate these diagrams for dierent purposes. The simulation that now is available for BPMN is that the model is evaluated by checking if it is correct. To evaluate these models more precise the specica- tion has been extended by our principals to include workers and tasks. By simulating the diagram and obtaining data based on the various attributes dened for the workers and the tasks, conclusions can be drawn concerning the optimal assignment.

In order to design and simulate a ow chart according to BPMN specica- tion an editor and simulator was implemented in Java. The simulator is implemented based on the principle of discrete event simulation (DES). When the ow reaches a ow object it is executed which among others means that possible future events are generated and added to the future event queue.

The simulator continues the execution by selecting the future event with the smallest timestamp. In this way the simulator traverses the graph until the future event list is empty which is when the ow reaches a nal event.

Since it is now possible to model BPMN diagrams according to own preferences, a large number of dierent graphs can be simulated. BPMN diagrams model made in other applications and exported using the XPDL- standard can also be loaded.

The program with the simulator and editor were evaluated using two dierent models and optimization algorithms. The results from these two evaluations indicates that the developed program is performing in compari- son with the expected result.

(4)

Förord

Denna rapport beskriver ett utvecklingsarbete som utfördes på KTH i Kista.

Målet var att utveckla en simulator för aärsprocesser och uppgiften utgör ett examensarbete vid institutionen för informationsteknik vid KTH. Vi vill tacka vår uppdragsgivare och handledare Farzad Kamrani för hans stöd under arbetets gång och även vår examinator Rassul Ayani.

KTH, Kista i maj 2010

Erik Eldh och Johan Pettersson

(5)

Innehåll

1 Inledning 1

1.1 Bakgrund . . . . 1

1.2 Syfte . . . . 1

2 Simulering av Business Process Modeling Notation (BPMN) 3 2.1 Allmänt om BPMN . . . . 3

2.2 Utvidgning av BPMN . . . . 4

2.3 Simulering . . . . 5

2.4 Existerande program . . . . 5

3 Metod 6 4 Utvecklingsarbete 7 4.1 Modellering . . . . 7

4.2 Grask representation . . . . 9

4.3 Simulering . . . 10

4.4 Graskt gränssnitt . . . 10

4.5 Att spara diagram . . . 11

5 Resultat 14 5.1 Evaluering . . . 14

5.1.1 Evaluering 1 . . . 14

5.1.2 Evaluering 2 . . . 17

6 Slutsats 18

7 Diskussion 19

A Programmet 21

B Exempel på sparning av diagram i XPDL 23

C BPMN Objekten 27

(6)

Figurer

1.1 Exempel på ett BPMN-diagram . . . . 2 2.1 Grask representation av ödesobjekt . . . . 3 4.1 UML Diagram över de klasser som representerar ödesobjek-

ten . . . . 8 4.2 Flödesobjekt modellerade i programmet . . . . 9 4.3 Flödesbanor modellerade i programmet . . . 10 4.4 De noder som skapas vid sparande i XML-dokumentet . . . . 12 4.5 En representation av en aktivitet i XPDL genererad av BizAgi. 13 5.1 Operational Planning Concept Development . . . 15 5.2 Evalueringsmodell . . . 17 A.1 Exempel på ett BPMN-diagram modellerat i programmet. . . 21 A.2 Exempel på hur arbetarnas färdigheter och aktiviteternas uppgifter

denieras i programmet. . . 22

(7)

Kapitel 1

Inledning

1.1 Bakgrund

Business Process Modeling Notation (BPMN) är en standard inom organisationer och används för att skapa en grask representation av aärsprocess- er bland annat för att tekniker och administratörer ska ha ett gemensamt språk[8]. En aärsprocess är en samling aktiviteter och uppgifter som sam- manlänkas för att tillhandahålla en specik tjänst eller producera en produkt.

Sammanlänkningen illustreras genom att rita upp ett ödesdiagram över af- färsprocessen liknande ett UML-diagram (Unied Modeling Language). Ett sådant diagram är endast en statisk representation av aärsprocessen, men att på ett bra sätt kunna simulera ett BPMN-diagram kan hjälpa många företag att utvecklas och optimera sin verksamhet. En illustration av hur ett BPMN-diagram kan se ut nns i gur 1.1.

Där BPMN för närvarande används för att tillhandahålla en gemensam notation för aärsprocesser har vår uppdragsgivare en annan approach, och använder BPMN för att mäta mervärdet av en process för att sedan optimera den med hjälp av olika optimeringsmetoder. För att mervärdet ska kunna mätas behövs ett sätt att kunna simulera ödet i aärsprocessen.

1.2 Syfte

Vår uppdragsgivare har uttryckt ett behov av att kunna modellera och simulera BPMN-diagram i ett ramverk där utvidgning och vidareutveckling skall vara enkla att implementera och som ska användas som en plattform för test av olika tilldelningsalgoritmer. Själva simuleringen ska kunna köras med olika optimeringsalgoritmer som uppdragsgivaren själv kan implementera.

Syftet med denna rapport är att visa hur ett sådant ramverk (editor och simulator) kan implementeras i Java.

(8)

Figur 1.1: Exempel på ett BPMN-diagram

(9)

Kapitel 2

Simulering av Business Process Modeling Notation (BPMN)

Detta avsnitt behandlar principerna bakom ett BPMN-diagram och hur ett sådant kan simuleras med hjälp av att utvidga BPMN specikationen.

2.1 Allmänt om BPMN

BPMN är som tidigare nämnts en standard inom stora och små organisationer för att skapa modeller över verksamheten. Dessa modeller används inom organisationen för att alla berörda parter ska ha en gemensam notation och ett standardiserat sätt att diskutera aärsprocesser. Ett BPMN-diagram är uppbyggt av ett antal olika objekt, så kallade ödesobjekt (eng. ow objects). Det nns ett ertal olika ödesobjekt, där vägskäl (eng. gateways),

Figur 2.1: Grask representation av ödesobjekt

(10)

aktiviteter (eng. activites) och händelser (eng. events) är huvudgrupperna.

Dessa objekt manipulerar hur ödet, via olika banor i diagrammet kallade sekvensöden (eng. sequence ows), dirigeras till olika objekt i diagrammet.

Dessa ödesobjekt ligger i pooler (eng. pools) som representerar separata organisationer med tillgång till olika resurser. Ett exempel på hur poolerna illustreras nns att se i gur 1.1 som innehåller två olika pooler. Polerna kom- municerar mellan sig genom att skicka meddelanden via meddelandeöden (eng. message ow).

Vägskäl ändrar ödet på olika sätt beroende på vilken typ av vägskäl det är. Ett vägskäl kan ha era ut- och ingångar som aktiveras beroende på vilken typ av vägskäl ödet har nått. När man når ett vägskäl kan era eller en utgång aktiveras och omdirigera ödet beroende på olika villkor för utgångarna. Ett vägskäl kan då dela upp ödet genom att den aktiverat er än en utgång. Likaså kan ett vägskäl sammanlänka era ingångar och dirigera

ödet till en utgång.

Aktiviteter i BPMN är de uppgifter i aärsprocessen som ska utföras.

En aktivitet kan vara atomär eller sammansatt. En atomär aktivitet är en arbetsuppgift (eng. task).

Av händelseobjekten nns det tre olika typer, start, mellanliggande (eng.

intermediate) och sluthändelser, som symboliserar olika moment i ödet.

Ett komplett diagram ska ha minst en starthändelse och en sluthändelse. Av typen mellanliggande händelse nns era typer. Till exempel kan man illustrera en lunchrast i aärsprocessen genom att använda en väntande händelse (eng. timer event) med parametern 45 minuter. Händelseobjekten kan också generera meddelanden som skickas via meddelandeöden. Dessa händelser denieras som gripande (eng. catching) om de tar emot ett meddelande eller kastande (eng. throwing) om de skickar iväg ett meddelande.

Dessa huvudtyper av ödesobjekt illustreras i ett BPMN-diagram enligt

gur 2.1 och en mer utförlig beskrivning av ödesobjekten nns i Bilaga C.

2.2 Utvidgning av BPMN

I ett försök att evaluera en aärsprocess mervärde har en forskningsgrupp på Kungliga Tekniska Högskolan och Totalförsvarets forskningsinstitut (FOI) använt sig av en utvidgning av BPMN där resurser, både maskiner och män- niskor, denieras som arbetare (eng. agents) [6] som har vissa egenskaper.

Arbetarna är resurser som en organisation har till sitt förfogande. Arbet- suppgifterna i aärsprocessen utökas med attribut som denierar vikten av arbetarnas egenskaper. Mervärdet som en viss tilldelning av en arbetare till en arbetsuppgift skapar räknas sedan ut, i sin enklaste form genom att sum- mera produkterna av attributen och egenskaperna. Genom denna utvidgning kan man beräkna den optimala arbetsfördelningen inom aärsprocessen, vem som ska göra vad, för att det bästa resultatet ska nås. När aärsprocessen

(11)

har arbetare knutna till sig får man även en ny aspekt att ha i åtanke. Hur arbetarna kommer att interagera med varandra och hur snabbt arbetet kommer att gå. Då kan man inte bara optimera en aärsprocess för att nå det bästa resultatet utan även för att nå ett accepterat resultat på snabbast tid.

2.3 Simulering

För att ett BPMN-diagram som inkluderar arbetare ska kunna utvärderas måste en simulering göras, detta på grund av den odeterminism som näs- tan alltid nns i diagrammen och som beror på vägskälen. Genom att i en simulator implementera de olika ödesobjekten denierade i BPMN speci-

kationen och använda arbetare kan en aärsprocess simuleras. Genom att låta stafettpinnar (eng. tokens), markörer som symboliserar vart i aärspro- cessen ödet nått, passera genom diagrammet och exekvera objekten från en starthändelse till en slutändelse genom olika ödesobjekt där aktiviteter och vägskäl är de mest intressanta kan det totala arbetet beräknas. För att, trots osäkerheten i modellen, kunna hitta ett medelvärde av antalet gånger som en aktivitet utförs behöver ett stort antal traverseringar göras av modellen. Den genom simulering erhållna datan användas till att hitta den mest optimala arbetsfördelningen i aärsprocessen.

2.4 Existerande program

Det nns idag ett ertal program vars uppgift är att rita upp ett diagram över en aärsprocess enligt BPMN. Exempel är MagicDraw [7], BizAgi [3]

och Intalio [4]. Dessa kan inte simulera diagrammet mer än att kontrollera att den är exekverbar (nit). Dessa program använder sig av en gemensam standard för hur diagrammet ska exporteras kallad XPDL (XML Process Denition Language). Aärsprocesser skapade och exporterade enligt detta format kan laddas i alla program som stödjer standarden.

(12)

Kapitel 3

Metod

Ett ramverk där ett BPMN-diagram kan designas graskt och simuleras ska implementeras i Java. Implementationen av BPMN-diagrammen görs så generell som möjligt för att framtida utvidgningar ska vara enkla att implementera. De aärsprocesser som ska modelleras med hjälp av programmet ska kunna användas på olika sätt. Till exempel ska diagrammet kunna köras i en simulator utan något GUI genom exporterade modeller.

XPDL, som är en standard för att spara modeller över aärsprocesser ska kunna användas. Genom att implementera laddningsmetoder som läser från XML formaterade ler knyts inte simulatorn till den designer som har använts utan den kan användas på diagram skapade i andra designprogram.

Till utvecklingen av BPMN-simulatorn och den graska designern an- vänds programmeringsspråket Java och närmare bestämt versionen Java SE 6 Update 18 utvecklat av Sun Microsystems (nuvarande Oracle). För den graska BPMN-designern används ett externt bibliotek vid namn jGraph [2]

för den diagramvy som ska visas.

jGraph är ett Java Swing baserat bibliotek speciellt anpassat för att hantera grafer av olika slag. Olika objekt, i jGraph kallade cells, placeras i en vy där användaren kan interagera med dem. Dessa kan även sammanlänkas via banor, i jGraph kallade edges.

(13)

Kapitel 4

Utvecklingsarbete

Detta kapitel beskriver utvecklingsarbetet där en grask BPMN-diagram designer och en simulator som hanterar ett ertal olika ödesobjekt skapades.

4.1 Modellering

De olika ödesobjekten specicerade i BPMN byggdes upp som enskilda klasser i Java. En superklass kallad FlowObject denierades med de enklaste funktionerna ett ödesobjekt har, så som till vilka den är kopplad och vilken typ av ödesobjekt den är. De tre huvudtyperna av ödesobjek- ten nämnda i kapitel 2.1 ärver dessa egenskaper men implementerar också ny funktionalitet för metoder denierade i klassen FlowObject. Då det även

nns undergrupper till de tre huvudtyperna implementerades också dessa som enskilda klasser som ärver av huvudtyperna. BPMN-specicationen in- nehåller ett antal attribut för de olika ödesobjekten som denierar deras parametrar [8]. Då alla parametrar inte var aktuella för hur vi valde att deniera objekten användes inte alla då de inte bidrog till mer funktionalitet. Ett UML-diagram över de olika klassernas samhörighet nns i gur 4.1.

Aktiviteterna implementerades för att innehålla en uppgift som innehåller parametrar vilka denierar vikten av arbetarnas egenskaper för arbetsuppgiften.

Likaså innehåller varje arbetare en färdighet (eng. skill) som innehåller olika parametrar för hur väl den kan utföra en uppgift. Då en uppgift ska utföras i en aktivitet implementerades en körningsmetod som tar in en arbetares färdigheter och applicerar på sin arbetsuppgift under simulering.

Flera olika vägskäl implementerades ur de olika huvudtyperna för vägskäl.

Ett parallellvägskäl som har funktionen att antingen dela upp eller sätta ihop ett sekvensöde implementerades som två enskilda klasser. Detta för att skilja på de två specika användningssätten. Dessa två nya vägskäl kallades delande vägskäl (split gateway) och ett sammanförande vägskäl (merging gateway). För dessa två olika vägskäl implementerades två metoder som körs

(14)

Figur 4.1: UML Diagram över de klasser som representerar ödesobjekten vid exekvering av det enskilda vägskälet. För det delande vägskälet skapades en metod som genererar en ny stafettpinne för varje utgång vägskälet har och för det sammanförande skapades en metod som väntar tills en stafettpinne från varje ingång når vägskälet innan den låter en av dem passera genom dess utgång och kasserar de extra stafettpinnarna.

Ett chansbaserat vägskäl (implementerat som en Complex Gateway) implementerades med hjälp av en slumpgenerator. Metoder för att sammanlän- ka dess olika utgångar till andra ödesobjekt för ett villkor skapades genom att implementera att man kan deniera villkor i procent. Den standardutgång som lades till i vägskälet används då inget av de andra villkoren i vägskälet uppfylldes.

Då aärsprocessen kan innehålla olika pooler i ett och samma diagram skapades pool- och diagramobjekt. Poolobjekten implementerades för att innehålla de ödesobjekt som knyts till poolen. Även de arbetare som ska utföra de olika arbetsuppgifterna denierade i poolens aktiviteter kopplas till poolen. Arbetare kan samarbeta i grupp och detta implementerades som ett grupp av agentobjekt i ett objekt kallat team. Team- och agentobjekten delar på en metod för att dess färdigheter ska evalueras, dock kan team objektet ta er faktorer i åtanke. Diagramobjekten innehåller de olika polerna.

Sekvensöden implementerades för att veta hur de olika ödesobjekten är sammanlänkade och innehåller identikationsnummer på de två olika ödes- objekten som den knyter samman. Likaså implementerades meddelandeödet för att innehålla identikationsnumren på de olika ödesobjekten den sam- manlänkar men även mellan vilka pooler ödet går.

(15)

4.2 Grask representation

Den graska representationen av diagrammet implementerades med hjälp av biblioteket jGraph. Den graska delen av diagrammet implementerades fristående från de tidigare modellerade klasserna över ödesobjekten. Detta för att lätt kunna skilja de två huvudkomponenterna ifrån varandra. De BPMN-diagram som skapas knyts till en DefaultGraphModel från jGraph biblioteket.

För att erhålla den graska representationen av ödesobjekten skapades klassen BPMNCell. Denna klass innehåller referenser (vilken typ av ödes- objekt den är, dess namn och vilken pool den tillhör) till vilket ödesobjekt den ska gestalta. För att rita upp det ödesobjekt som ska visas i diagramet implementerades klassen BPMNCellView som överlagrar rendreringern i klassen VertexView från jGraph biblioteket. Genom detta erhålls full kontroll över hur de celler som ska läggas till i diagrammet ser ut. Till BPMNCel- lView knöts referenser till de olika bilder som ska användas i diagrammet beroende på vilken typ som deneras i BPMNCell. Den graska representation som skapats av ödesobjekten lagras sedan i en DefaultGraphCell från jGraph biblioteket. Hur de ser ut i programmet syns i gur 4.2.

Figur 4.2: Flödesobjekt modellerade i programmet

De olika ödesbanorna implementerades med hjälp av klassen Default- GraphEdge från jGraph biblioteket. För att erhålla de två olika sorterna av ödesbanorna (sekvensöde och meddelandeöde) används typen AR- ROW_CLASSIC som ritas som en pil. För ett skilja på de två olika ödena, sekvensöden som går mellan ödsobjekt i en pool, och meddelandeöden som går mellan pooler, delades meddelandeödets pil upp i mindre segment enligt ett mönster. För att erhålla referenser till det specika ödet pilen behandlar lades själva ödet in i den DefaultGraphEdge som skaps. I gur 4.3 illustreras dels ett sekvensöde mellan ett start- och ett slutevent, och dels ett meddelandeöde mellan ett kastande meddelandeevent och ett gripande meddelandeevent.

För de olika ödesobjekten skapades bilder som läggs till i diagramvyn.

De olika graska objekt som skapas innehåller en referens till den ödesobjekt-

(16)

Figur 4.3: Flödesbanor modellerade i programmet

klass som den är knyten till. De olika öden som läggs till innehåller det

ödesobjekt som skapas då två ödesobjekt knyts samman i Pool klassen.

4.3 Simulering

En simulator som använder de modellerade ödesobjekten för att skicka en stafettpinne mellan dem och beräkna mervärdet av aärsprocessen implementerades. Simulatorn implementerades enligt systemet diskret händelses- tyrd simulering där de olika händelserna kan generera framtida händelser som läggs i en kö[1]. För denna kö skapades klassen History. För History klassen skapades två viktiga metoder; add och next. Add tar in ett objekt av typen Post och next plockar fram den händelse med närmast tid ur en sorterad lista. Klassen Post innehåller olika parametrar för den specika händelse den hanterar. Dessa parametrar är vilken tid händelsen inträar, vilken typ av händelse det är (antingen move (sv. ytta) eller execute (sv.

exekvera)) och identikationsnumret för den stafettpinne händelsen berör.

De två typerna av händelser berättar för simulatorn vilken typ av händelse som ska exekveras. Om en Post med typen Move hittas yttas stafettpinnen till ett ödesobjekt sammanlänkat med det objekt stafettpinnen benner sig i och om typen är Execute, exekveras det objekt stafettpinnen benner sig i och genererar en ny Post som läggs in i History objektet. De olika objekten simuleras olika genom att simulatorn använder de olika ödesobjektens metoder för att generera nya händelser och i vissa fall nya stafettpinnar.

4.4 Graskt gränssnitt

Det graska gränssnittet byggdes upp med hjälp av komponenter från biblioteket javax.swing. Genom att använda konventionella program som mall för hur programmets design skulle se ut implementerades ett överskådligt gränssnitt. Ett verktygsfält innehållande de ödesobjekt programmet kan hantera skapades. De olika knapparna på verktygsfältet skapades så att man kan dra de till olika platser på diagrammet och släppa dem där och då skapas ett objekt i grafen och ett ödesobjekt läggs till i diagrammet. För att illustrera vad som händer byttes muspekaren ut till en bild på det ödes-

(17)

objekt som ska läggas till i diagrammet, för att få ett Drag och Släpp-be- teende. Gränssnittet interagerar både mot DefaultGraphModel-objektet och Diagramobjektet. Detta för att skilja dem åt implementationsmässigt.

För det graska gränssnittet implementerades även en vy där de olika parametrarna från utvidgningen presenterad i kapitel 2.2 visas för de arbetare och aktiviteter som läggs till i den pool som används. Då ett BPMN-diagram kan innehålla mer än en pool användes en rullgardinsmeny för att bestämma vilken pool som är den aktiva. Rullgardinsmenyn reagerar på händelser som t.ex. när en annan pool väljs och byter då ut vyn för arbetare och aktiviteter till den vy som rör den valda poolen. För att förstärka visualiseringen av att diagramet är uppdelat i olika pooler inaktiveras de objekt som inte hör till den aktiva poolen så att användaren ej kan interagera med dem. Det går dock att koppla ihop händelse objekt som är kastande eller gripande mellan två pooler via meddelandeöden.

För att programmet ska kunna köras utan ett graskt gränssnitt skapades ett sätt att använda programmet via en terminal. Terminalläget implementerades så att ett diagram skapat i det graska gränssnittet kan laddas och simuleras. Via terminalläget kan också de tillgängliga optimeringarna användas för att kunna dra slutsatser av simuleringen.

4.5 Att spara diagram

För att kunna spara diagram som är tillverkade med hjälp av det graska gränssnittet som man senare vill simulera i terminalläget användes Javas inbyggda stöd för att spara objekt i minnet till disk. Alla de objekt som skapades under modelleringen deklarerades som Serializable. För att kunna vara bakåtkompatibelt denierades ett permanent id (serialVersionUID) för objektet. Denna form av sparande implementerades endast för diagramobjekt för att de ska kunna laddas och köras i en simulator utan GUI.

För att spara och ladda det graska diagrammet i editorn skapades två metoder, loadXPDL och saveXPDL. Dessa metoder använder sig, som namnen antyder, av XPDL-standarden för aärsprocesser. Metoderna implementerades mycket snarlikt varandra. För att förenkla skrivandet och sparan- det till ler formaterade enligt XML användes klasser från javas medföljande paket javax.xml.

Sparningen implementerades genom att alla objekt i diagrammet häm- tades från den DefaultGraphModel som används. Dessa objekt, som är av typen DefaultGraphCell eller DefaultGraphEdge, innehåller parametrar för objektets storlek och position i diagrammet. För att sedan kunna ta fram de specika objekt som cellerna behandlar, tas BPMNCell-objekten som är lagrade i DefaultGraphCell fram. Med hjälp av XML paketet skapades ett antal noder i det XML dokument som ska skrivas till l. Dessa noder nns i denierade i gur 4.4.

(18)

<Model>

<Pools>

<Pool>

<Agent>

</Agents>

</Pool>

</Pools>

</Model>

</Package>

Figur 4.4: De noder som skapas vid sparande i XML-dokumentet För att vara kompatibelt med andra program vars uppgift är att designa diagram över aärsprocesser implementerades stöd för att läsa från XPDL

ler. Hur en aktivitet beskrivs i ett XPDL dokument kan ses i gur 4.5.

Programmet läser från XPDL dokumentet genom javas inbyggda XML parser och lägger till dem i den graska vyn.

För att kunna exportera bilder över det designade diagrammet implementerades funktionen export image. Vilket exporterar det graska diagrammet över aärsprocessen till en bild.

(19)

</Implementation>

</NodeGraphicsInfo>

</NodeGraphicsInfos>

<IsForCompensationSpecified>false</IsForCompensationSpecified>

</Activity>

Figur 4.5: En representation av en aktivitet i XPDL genererad av BizAgi.

(20)

Kapitel 5

Resultat

Utvecklingsarbetet utmynnade i ett program där man kan modellera BPMN- diagram graskt och ge arbetare och uppgifter olika attribut som används under simulering. Bilder på programmet nns att se i bilaga A. Programmet använder sig av standarden XPDL för att spara och ladda aärssprocesser från XML-ler. Ett exempel på en sparning i XPDL nns att se i bilaga B.

5.1 Evaluering

De evalueringar som valdes för att kontrollera om programmet fungerade korrekt hämtades från Optimizing a Business Process Model by Using Sim- ulation [6] och Estimating performance of a business process model [5], där två olika modeller och optimeringsalgoritmer presenteras.

5.1.1 Evaluering 1

Den första evalueringen hämtades från Estimating performance of a business process model, avsnitt 5 där en aärsprocess kallad Operational Plan- ning Concept Development modellerad i BPMN presenteras. Diagrammet innefattar fem olika aktiviteter, fem arbetare och tre chansbaserade vägskäl.

Dess attribut nns i tabell 5.1. Diagrammet modellerades i programmet (resultatet nns i gur 5.1) och simulerades sedan med simulatorn.

Det resultat som erhölls från simuleringen kan ses i körningsresultat 1 där det slutgiltiga resultatet blev ett maximum på 39.53 och ett minimum på på 32.05. Resultatet för simuleringen som gjordes i Estimating performance of a business process model, avsnitt 5.3 var ett maximum på 39.61 och ett minimum på 32.07. Den skillnad som uppvisas mellan resultatet beror på slumpgeneratorn.

(21)

Figur 5.1: Operational Planning Concept Development

Tabell 5.1: Parametrar för Operational Planning Concept Development Creativity Experience Cognitive Ability Knowledge Aktivitet

Development 2.5 0.5 0.5 0.5

Analysis 0.5 1.5 1.0 1.0

Comparsion 0.5 1.0 1.5 1.0

Commander 1.0 1.0 1.0 1.0

Approval 1.0 1.0 1.0 1.0

Agent

Commander 1.0 1.0 1.5 1.5

Agent A 1.0 2.0 1.0 2.0

Agent B 2.0 2.0 2.0 2.0

Agent C 1.0 0.5 1.0 0.5

Agent D 2.0 0.5 2.0 0.5

(22)

Körningsresultat 1 Simulering av Operational Planning Concept Devel- opment

+---

| BPMN Model Designer and Simulator

| Johan Pettersson & Erik Eldh

| Bachelorthesis KTH 2010

+---

Running simulation on case2009.bpmn for 1000 Loading model from file: case2009.bpmn

Loaded model: Model

nr = 0: min = 36.20801 (0, 1, 2, 3, 4) nr = 0: max = 36.20801 (0, 1, 2, 3, 4) nr = 1: max = 36.755205 (0, 1, 2, 4, 3) nr = 2: min = 35.653465 (0, 1, 3, 2, 4) nr = 3: min = 34.79012 (0, 1, 3, 4, 2) nr = 12: min = 34.002965 (0, 3, 1, 2, 4) nr = 13: min = 33.1746775 (0, 3, 1, 4, 2) nr = 16: min = 33.0591525 (0, 3, 4, 1, 2) nr = 19: min = 32.976595 (0, 4, 1, 3, 2) nr = 22: min = 32.567825 (0, 4, 3, 1, 2) nr = 40: min = 32.52936 (1, 3, 4, 0, 2) nr = 46: min = 32.05973 (1, 4, 3, 0, 2) nr = 54: max = 37.420455 (2, 1, 0, 3, 4) nr = 55: max = 37.94426 (2, 1, 0, 4, 3) nr = 96: max = 38.262485 (4, 0, 1, 2, 3) nr = 98: max = 38.507755 (4, 0, 2, 1, 3) nr = 102: max = 39.53181 (4, 1, 0, 2, 3) nr = 104: max = 39.533275 (4, 1, 2, 0, 3) ---

total number = 120 min gain = 32.05973 max gain = 39.533275

(23)

Körningsresultat 2 Simulering med algoritm två +---

| BPMN Model Designer and Simulator

| Johan Pettersson & Erik Eldh

| Bachelorthesis KTH 2010

+--- Loading model from file: case2010.bpmn Loaded model: pads2010-2

number of tasks = 8

freqency = [1.46, 1.46, 1, 1, 1.21, 1.21, 1, 1]

minimum cost = 46.5

tasks : [0, 1, 2, 3, 4, 5, 6, 7]

agents: [2, 4, 7, 5, 1, 6, 3, 0]

maximum cost = 102.56

tasks : [0, 1, 2, 3, 4, 5, 6, 7]

agents: [0, 3, 6, 1, 5, 7, 4, 2]

5.1.2 Evaluering 2

I Optimizing a Business Process Model by Using Simulation[5] presenteras algoritmen Optimal Assignment of a Non-Markovian Process i tabell Algo- rithm 2, algoritmen benämns hädanefter med namnet algoritm två. För att evaluera simulatorn med algoritm två modellerades en aärsprocess enlig g- ur 2 i den tidigare nämnda rapporten. Den färdiga modellen nns att se i gur 5.2. Sedan användes de attribut för aktiviteternas uppgifter och arbetarnas färdigheter som användes för den simulering som utfördes i rapporten.

Det skapade diagrammet simulerades genom algoritm två i simulatorn och som resultatet i körningsresultat 2 visar så stämmer den överens med värdet från rapporten.

Figur 5.2: Evalueringsmodell

(24)

Kapitel 6

Slutsats

Den här rapporten presenterar utvecklingen av ett ramverk för simulering och modellering av BPMN-diagram, baserade på vår uppdragsgivares utvidgning av BPMN-specikationen. Den utvecklade prototypen kan användas för att applicera användardenierade optimeringar på diagram med hjälp av simulatorn. Användaren har möjlighet att använda existerande program som kan designa BPMN-diagram som exporteras i XPDL formatet. Laddas redan färdiga BPMN-diagram in i programmet kan användaren nu knyta olika ar- betsuppgifter och lägga till arbetare för de olika poolerna i diagrammet för att sedan kunna simulera det. Enligt evalueringen så presterar simulatorn enligt förväntan.

(25)

Kapitel 7

Diskussion

BPMN-specikationen över aärsprocesser är mycket omfattande och de funktioner som implementerats i designern och simulatorn täcker ej allt som beskrivs i den. Flera olika objekt kan implementeras allt eftersom de behövs simuleras. Editorn skulle med enkelhet kunna bearbetas till att innehålla alla de objekt som nns i BPMN men innefattar nu bara de simulatorn klarar av. Då BPMN-standarden vid rapportens skrivande är under fortsatt utveckling kan fortsatt arbete göras genom att implementera de nya BPMN- specikationerna.

Biblioteket jGraph som användes till den diagramvy som skapades är mycket genomgående och innehåller många funktioner som ej var aktuella för den implementation som utfördes. Själva diagramvyn som skapades med hjälp av biblioteket hade kunnat implementeras utan jGraph för att uppnå samma funktionalitet men det skulle ha inneburit att mer arbete skulle ha behövts på det området.

Då den simulator som skapades är mycket nära knuten till våra uppdragsgivares utvidgning av BPMN-specicationen, presenterad i kapitel 2.2, kan programmet inte benämnas som en generell simulator för BPMN-diagram och bör inte användas som en sådan.

(26)

Litteraturförteckning

[1] Jerry Banks, John S. Carson, Barry L. Nelson, and David M. Nicol.

Discrete-Event System Simulation (3rd Edition). Prentice Hall, 3 edition, 2000.

[2] David Benson. Jgraph and jgraph layout pro user manual.

June 2009. www.jgraph.com/downloads/jgraph/archive/jgraph-5.13.0.0- jgraphmanual.pdf Besökt 21 Maj 2010.

[3] BizAgi. BizAgi BPMN by example. 2009.

http://www.bizagi.com/docs/BPMNbyExample%20ENG.pdf, Besökt 1 Juni 2010.

[4] Intalio. Intalio overview. 2010. http://www.intalio.com/bpm/, Besökt 1 Juni 2010.

[5] Farzad Kamrani, Rassul Ayani, and Anvar Karimson. Optimizing a business process model by using simulation. In Proceedings of the 2010 Work- shop on Principles of Advanced and Distributed Simulation, pages 4047, Atlanta, GA, May 2010.

[6] Farzad Kamrani, Rassul Ayani, Farshad Moradi, and Gunnar Holm. Es- timating performance of a business process model. In M. D. Rossetti, B. Hill, R. R.and Johansson, A. Dunkin, and R. G. Ingalls, editors, Pro- ceedings of the 2009 Winter Simulation Conference, Austin, TX, Decem- ber 2009.

[7] MagicDraw. MagicDraw technical manual. 2010.

http://www.magicdraw.com/les/brochures/a4/MagicDraw_technical.pdf, Besökt 1 Juni 2010.

[8] S.A. White. Introduction to BPMN. 2004.

http://www.bpmn.org/Documents/Introduction_to_BPMN.pdf, Besökt 20 Maj 2010.

(27)

Bilaga A

Programmet

Denna bilaga visar det färdiga användargränssnittet. I gur A.1 visas hur programmet används för att rita upp ett BPMN-diagram. Ett antal ödes- objekt har lagts till i ett diagram bestående av två pooler. Flödesobjekten har blivit sammanlänkade med sekvensöden och poolerna har blivit sam- manlänkade med meddelandeöden mellan två händelser.

I gur A.2 visas hur användaren kan lägga till uppgifter och färdigheter till arbetarna och aktiviteterna i diagrammet. Färgkodningen visar hur de olika arbetarna och aktiviterna har sammanlänkats.

Figur A.1: Exempel på ett BPMN-diagram modellerat i programmet.

(28)

Figur A.2: Exempel på hur arbetarnas färdigheter och aktiviteternas uppgifter denieras i programmet.

(29)

Bilaga B

Exempel på sparning av diagram i XPDL

Modellen i gur 5.1 sparade i XPDL.

<Pools>

</Route>

</ A c t i v i t y>

<Task/>

<Tasks Cognetive_Ability=" 0 . 5 " C r e a t i v i t y=" 2 . 5 " Experience=" 0 . 5 "

Knowledge=" 0 . 5 "/>

</ A c t i v i t y>

<Task/>

</ A c t i v i t y>

<Event>

</Event>

</ A c t i v i t y>

</Route>

(30)

</ A c t i v i t y>

<Task/>

Knowledge="1"/>

</ A c t i v i t y>

</Route>

</ A c t i v i t y>

<Event>

</Event>

</ A c t i v i t y>

<Task/>

</ A c t i v i t y>

<Task/>

<Tasks Cognetive_Ability=" 10.0 " C r e a t i v i t y=" 10.0 " Experience=" 10.0 "

Knowledge=" 10.0 "/>

</ A c t i v i t y>

</ A c t i v i t e s>

<S k i l l s Cognitive_Ability=" 1 . 5 " C r e a t i v i t y=" 1 . 0 " Experience=" 1 . 0 "

</Agent>

</Agent>

</Agent>

</Agent>

</Agent>

(31)

</ Agents>

</ T r a n s i t i o n>

(32)

</ T r a n s i s t i o n s>

</ Pool>

</ Pools>

</Model>

</Package>

(33)

Bilaga C

BPMN Objekten

BPMN-specikationen består av ett antal olika objekt med olika egenskaper. Dessa objekt är de som används då ett BPMN-diagram designas. De olika objekten är indelade i fyra olika grupper; ödesobjekt, kopplingsobjekt, simbanor och artefakter. Denna bilaga ger en överblick över de olika grupperna och dess objekt.

Flödesobjekt Beskrivning Grask representation

Händelse

(Event) Händelseobjektet har formen av en cirkel. Dessa objekt genererar olika händelser i diagrammet beroende på vilken typ av händelse de tillhör. Det

nns tre huvudtyper av hän- delser; start-, mellanliggande-

och sluthändelser. Start, Mellanliggande och Slut Activity

(Aktivitet) En aktivitet har formen av en rektangel med rundade hörn.

En aktivitet är antingen en arbetsuppgift eller en samling

ödesobjekt samlade i en process (subprocess).

Arbetsuppgift och Samlade ödes- objekt

Vägskäl

(Gateway) Ett vägskäl har formen av en kantställd rektangel. Den används för att manipulera

ödet i schemat. Ett vägskäl kan ha era sekvensöden knutna till sig och skicka

ödet på olika utgångar.

(34)

Kopplingsobjekt Beskrivning Grask representation Sekvensöde

(Sequenceow) Ett sekvensöde har formen av en pil som sammanlänkar de olika ödesobjekten i diagrammet.

Meddelandeöde

(Messageow) Ett meddelandeöde har formen av en pil som är uppdelad i mindre segment, streckad pil.

Meddelandeödet binder samman ödesobjekt som ligger i olika pooler. Via meddelande-

ödet kan processerna utbyta information under körning.

Association

(Association) En association har formen av en pil som består av punk- ter. En association generar inte, till skillnad från de två andra kopplingsobjekten, ett

öde utan används för att as- sociera ut- och ingångsdata, text eller andra objekt till det

ödesobjekt den är kopplad till.

Samlingsobjekt Beskrivning Grask representation Pool En pool samlar de olika ödes-

objekten till en aärsprocess.

Flödesobjekten i poolen kom- municerar via sekvensöden och ödesobjekt i olika pooler kan kommunicera via medde- landeöden

Bana(Swimlane) En bana är en indelning av en pool för att ge en bättre grask representation av hur processens aktiviteter är indelade i olika moment.

(35)

Artifakter Beskrivning Grask representation Dataobjekt (Data

Object) Ett dataobjekt är knytet till en aktivitet via en association och symboliserar antingen att data produceras i aktiviteten eller att data behövs

Grupp

(Group) En grupp är ett graskt

hjälpmedel och påverkar ej

ödet i diagrammet. Grup- per används i ödesdiagram- met för att samla ödesobjekt i olika moment som är tänkt att underlätta för den som läs- er schemat hur de olika processerna hänger samman.

Notering

(Annotation) En notering används för att knyta förklarande text till de olika ödesobjekten.