Realisation of a framework for the analysis of business processes

(1)

Degree project

Realisation of a framework for the analysis of business

processes

Author: Norbert Spiess Supervisor: Welf Löwe

External Supervisor: Thomas Prinz, Friedrich Schiller University Jena Date: 2013-11-21

Course Code: 4DV01E, 15 credits Level: Master

(2)

Abstract

Companies structure their work to be done using business processes. A widely used modeling language is BPMN which provides a standardized graphical notation and execution semantics [14]. But studies show that many business processes contain logical errors [13]. The detection of these errors priorly to the execution can save money and effort.

A wide range of structural analysis methods for business processes exist that transform business processes into Petri nets or workflow graphs. But the analyses are either very slow or lack in the detection of all errors and their details. At the Friedrich Schiller University, a new workflow graph based approach is under development that promises a fast analysis, the detection of all errors and specific details to these errors.

The aim of this thesis was to realise a framework that combines the modelling and analysis of business processes in BPMN. The framework should transform business processes into workflow graphs and analyse them dynamically while they are modelled. Analyses are supposed to be easily introduca- ble. Another aspect was the enrichment of the BPMN diagram with process data that can be included into analyses too.

The designed framework provides a simple interface to add new analyses or transformations. Analyses can share data independent of workflow graphs, define execution conditions and therefore define dependencies to other analyses. The transformation transforms BPMN diagrams always into analysable workflow graphs through several correction patterns that follow the BPMN semantics.

Keywords: framework, analysis, business process, BPMN, workflow graph, Activiti Designer

Disclaimer: This work is done under supervision by researchers at Friedrich Schiller University (Jena, Germany) and LNU, and is therefore presented at both places.

(3)

List of Figures

2.1 Schematic white box framework . . . 5

2.2 Schematic black box framework . . . 5

2.3 Schematic grey box framework . . . 6

2.4 Exemplary business process of releasing a new product in BPMN 7 2.5 An empty pool called Sales . . . 10

2.6 A pool with two empty lanes Team A and Team B . . . 11

2.7 An undirected graph with three vertices and three edges . . . 12

2.8 Exempary workflow graph . . . 15

2.9 Activiti Designer view with exemplary BPMN process . . . 16

2.10 Layer model of responsibilities of the Activiti Designer . . . . 17

2.11 Eclipse plugin concept of resource sharing . . . 18

2.12 Eclipse plugin concept of extension points . . . 19

3.1 Basic structure of the framework with loosely coupled plugins 20 3.2 Extended layer model of the involved technologies . . . 21

3.3 Overview over the components and their relations . . . 22

3.4 AbstractProcessValidator with selected method definitions . . 24

3.5 Usage of diagram change listener on the diagram model . . . . 25

3.6 Class diagram of the transformed workflow graphs. . . 26

3.7 AbstractAnalyser for the Analysis extension point. . . 27

3.8 Source feature for the Activiti Designer . . . 29

4.1 Inter and intra pool communication after BPMN . . . 35

4.2 Inter and intra pool communication modelled with Activiti Designer . . . 36

4.3 Corresponding workflow graph for inter and intra pool communication . . . 37

4.4 Correction of a direct loop . . . 39

4.5 Correction of duplicate edges . . . 40

4.6 Correction of a free standing start node . . . 40

4.7 Correction of a free standing end node . . . 40

4.8 Correction of an isolated node . . . 41

4.9 Combination of multiple explicit and implicit start nodes . . . 41

4.10 Combination of multiple explicit and implicit start nodes with pools . . . 42

4.11 Correction of a start node with multiple outgoing flows . . . . 43

4.12 Correction of a start node with incoming flows . . . 43

4.13 Correction of a forking/joining node with one incoming and outgoing flow . . . 43

(6)

4.14 Correction of a forking/joining node with multiple incoming and outgoing flows . . . 44 4.15 Correction of an activity with multiple outgoing flows . . . 44 4.16 Correction of an activity with multiple incoming flows . . . 45 4.17 Correction of an end node with multiple incoming flows . . . . 45 4.18 Semantically correct joining of multiple end nodes . . . 46 4.19 Worst case scenario for the start and end node combination . 49 5.1 Source code editor for the code attachable per node . . . 52 5.2 A simple program with a corresponding control flow and pro-

cess data . . . 54 5.3 Example for a data-flow analysis on variable definitions . . . . 57 6.1 Class model for the analysis feedback collection through a store 59 6.2 Usage of the Marker Registry of Eclipse to report analysis

feedback . . . 60 6.3 Decoration of BPMN elements for displaying errors and warnings 61 6.4 Example for the selective feedback mode to display error details 62

(7)

List of Tables

2.1 Graphical notation for the supported BPMN elements . . . 8

2.2 Graphical notation for the workflow graph elements . . . 13

3.1 Operators available for the execution conditions . . . 28

5.1 Grammar for the language of attachable source code . . . 51

7.1 Measure results for the transformation evaluation . . . 64

7.2 Distribution of node types in the BPMN processes . . . 65

7.3 Element distribution in the workflow graphs . . . 65

7.4 Measured edge node relations . . . 66

(8)

List of Algorithms

3.1 Simplified logic of the validator plugin . . . 26 4.1 Algorithmic logic to transform BPMN processes to workflow

graphs . . . 33 4.2 Algorithmic schema for calculating the connected components 38 4.3 Algorithm for the combination of multiple end nodes . . . 47 5.1 Algorithm for computing the available variables . . . 56

(9)

List of Definitions

2.1 Definition (Framework) . . . 4

2.2 Definition (Business process) . . . 5

2.3 Definition (Graph) . . . 11

2.4 Definition (Workflow Graph) . . . 12

5.1 Definition (Data-flow analysis) . . . 54

(10)

Listings

3.1 Extract of themanifest file of the validator plugin . . . 30 3.2 Exemplary plugin.xml of the validator plugin . . . 31 5.1 Exemplary class for compiling the source code displayed in the

editor . . . 53

(11)

1 Introduction

Work of companies is structured using processes in practice. These processes define who is involved and what needs to be done to reach a business goal.

Such processes are called business processes [11]. The discipline to manage these business processes is described as workflow management. Business processes can get large and complex since there can be many internal or external organisations or people involved and the processes can consist of many sub processes. The execution of such business processes can take days or weeks. With that it becomes harder and harder to fully understand and analyse these processes manually.

To design business processes the Business Process Model and Notation (BPMN) can be used [14]. Developed by the Object Management Group (OMG) this notation offers a standardized graphical representation and execution semantics for business processes. There exists multiple software to support the modelling using BPMN. Research showed that most of the existing business processes contain control flow errors [13]. Finding and fixing these errors on runtime is very costly and time consuming.

Existing analyses for business processes transform the processes either directly into Petri nets or into workflow graphs. On Petri nets, the correctness of the control flow is analysed using the rank theorem [1] or state space exploration via tools like Woflan [22] or LoLA [24]. These analyses provide the information if the graph is without control flow errors or not. Some additionally provide details about the first found error but not more. On workflow graphs one of the best known methods is the SESE decomposition ([21]) which transforms the graph into sub graphs. However, not all errors can be found since only one error per sub graph is detected. Other analyses are either very slow ([6]) or restrict the analysed workflow graphs for example into being acyclic ([8, 16]).

1.1 Motivation

At the Friedrich Schiller University Jena a new workflow graph based analysis approach is under development, that can handle complex workflow graphs, detects more structural errors and delivers detailed information about these [17, 18]. To test and develop this approach further, an analysis framework would help, that allows the modelling of business processes and their analysis. A framework because the new analysis only handles the structural correctness. Further analyses may follow as, for example, for the analysis of the semantics or the evaluation of operability. Operability targets the non termination of multiple business processes collaborating together over com-

(12)

mon interfaces [11]. Another possible analysis could be an analysis of process data, that is attached to processes. Process data could be source code, that is addressed when elements are processed during the execution. Through that, not only an abstract logical control flow can be modelled, but also specific computations of any kind. Besides the variety of possible analyses, transformations into other representations than workflow graphs are possible as well.

There exists a wide range of software that allows to model business processes and to execute them in Business Process Model Systems. However, these tools mostly do only allow the modelling and execution. These tools do not offer an analysis of the modelled business processes on errors while they are designed. Through that, they do not give immediate feedback to the user about structural, semantically or further errors that might occur during the execution.

1.2 Goals and goal criteria

The main goal of this thesis is to design and implement an analysis framework on the basis of a BPMN modelling tool that analyses the modelled business processes using workflow graphs. This is including the following sub-goals:

1. BPMN diagrams should automatically be transformed into analysable workflow graphs.

2. BPMN diagram nodes should be expandable by process data.

3. The analysis on structural correctness, provided by Thomas Prinz ([18]), as well as an analysis on inherited variables in the attached process data should be introduced to the framework.

4. Meta-modelling of dependencies between analyses should be possible.

5. Additional UI, as for attaching process data, as well as analysis feedback should be integrated with the existing BPMN tool.

6. Feedback from the various analyses should be visualized in the BPMN diagrams by, for example, highlighting erroneous nodes.

To measure the goal achievement, the following goal criteria are taken:

The framework should provide an easy to use possibility to add an analysis in as few work steps as possible.

The transformation and analysis of the BPMN diagram should be done dynamically while the (incomplete) diagram is modelled.

(13)

The transformation should be highly performing and transform BPMN diagrams in few milliseconds. This will be measured using benchmarks.

1.3 Thesis structure

The thesis is structured as described in the following. Chapter 2 introduces important technologies and terms used in this thesis, as for example business processes, BPMN and workflow graphs. Chapter 3 discusses the design of the realised analysis framework with its components and the analysis provision interface. The transformation from BPMN diagrams to analysable workflow graphs is adressed in Chapter 4. Details to the attachable process data and its regarding data-flow analysis are given in Chapter 5. Chapter 6 shortly describes how analysis feedback is collected and displayed in the diagram.

The realised framework is evaluated regarding the set goal criteria in Chapter 7. Chapter 8 and 9 conclude the thesis and take a glance at possible future work.

(14)

2 Technologies and terms

This chapter describes the practical and theoretical technologies involved in this thesis.

2.1 Frameworks

To be able to design a framework, it is important to know what a framework is. The following definition is inspired by Wikipedia [23].

Definition 2.1 (Framework). A framework is a software component or system that provides functionality for a wide range of applications. It can be seen as application scaffold that can be adapted and extended for specific use cases.

Frameworks provide a generic software architecture. This architecture can be used to create specific applications through injection of problem specific implementations into the framework. Hereby, the framework defines how implementations can be injected and under what restrictions. An application based on a framework does not use provided resources, as with libraries, but lets the framework take over the control over the execution logic while specifying the result.

Because of the generic property, frameworks do not focus on one specific functionality, but provide a wide range of logic for different task fields. A single framework for example can provide functionality for the user interface, data storage and user management. Therefore, frameworks are used to either quickly build up a part of an application or even a whole system. The specific details are configured or contributed by the specific application.

One of the main advantages of this approach is, that every new application does not have to define common logic, but can rely on the framework. This reduces code duplication and development time, since specific algorithms or technologies only have to be handled by the framework. If new logic is introduced to a framework, all applications based on the framework benefit from it. This is one of the weak spots of frameworks at the same time, since mistakes in the framework affect all applications developed upon it. The usage of frameworks helps to keep logic separated, as the framework handles the basic tasks (for example database communication) and the specific logic (for example complex mathematical computations) remains in the specific application and can be tested separately.

Riehle [19] distinguishes between two types of frameworks, the white box and the black box framework. A white box framework gives the user the op- portunity, to extend specific elements, which are then used by the framework.

(15)

^ƉĞĐŝĨŝĐ

ůŽŐŝĐ

ďƐƚƌĂĐƚ

ůŽŐŝĐ ĚĞĨŝŶŝƚŝŽŶ

'ĞŶĞƌĂů

&ƌĂŵĞǁŽƌŬ

>ŽŐŝĐ

^ƉĞĐŝĨŝĐ

ĞŚĂǀŝŽƵƌ

Figure 2.1: A schematic white box framework. The logic of the framework is visible and the framework provides an abstract logic definition that can be specified by using applications. The specific logic provides the possibility to adapt the framework to create a very specific behaviour.

&ƌĂŵĞǁŽƌŬ

>ŽŐŝĐ

ŽŶĨŝŐƵƌĂƚŝŽŶ

WƌĞĚĞĨŝŶĞĚ

ĞŚĂǀŝŽƵƌ

Figure 2.2: A schematic black box framework that can be configured to some extend and provides a specific behaviour. The logic of the framework itself is not visible and the basic behaviour is defined statically with only minor configuration possibilities. A specialisation is only possible as far as the configuration allows.

That way the framework abstracts a problem, which is specialized by the extending application, see Figure 2.1. When using a black box framework, no extension is doable. The framework can only be used or configured, which makes it a domain specific software system already and not a real framework anymore, after the definition given above. Figure 2.2 depicts the black box framework principle. In practice, a combination of both principles is found, called grey box framework. Here, the framework provides a non-accessible part and an extendable part at the same time, see Figure 2.3.

2.2 Business processes

Business processes are widely used by companies and organisations nowadays.

The following definition is taken from Martens [11].

Definition 2.2 (Business process). A business process is a sequence of activities that share a logical context, are content wise complete and executed to reach a company driven goal by the usage of resources and information of humans or machines.

Business processes describe a specific process in the everyday business.

They define, how the process is initiated with clear starting points, as well as

(16)

^ƉĞĐŝĨŝĐ

ůŽŐŝĐ

ďƐƚƌĂĐƚ

ůŽŐŝĐ ĚĞĨŝŶŝƚŝŽŶ

tŚŝƚĞŽǆ

>ŽŐŝĐ

^ƉĞĐŝĨŝĐ

ĞŚĂǀŝŽƵƌ

ůĂĐŬŽǆ>ŽŐŝĐ

ŽŶĨŝŐƵƌĂƚŝŽŶ

Figure 2.3: A schematic grey box framework combining black and white box principles. Either all or only a part of the framework logic is visible to the outside. The framework is configurable for the unchangeable logic where some logic can be specified with concrete logic following an abstract definition. The result is, similar to white box frameworks, a highly specific behaviour.

how the process ends. Business processes can involve multiple entities, like humans, departments, companies or general roles, that are seen as responsible for at least parts of the process. The technical realisation of a business process is called workflow.

An example of a business process could be the development and produc- tion of a new product. The head of the product development department decides to introduce a new product and starts the business process. The market has to be inspected on competing products and what possible customers would want, which is done by someone else. As a next step, the design team specifies the product, which has to be produced, advertised and sold afterwards. The examplary business process ends with the product being sold over retailers for the broad market. As one would expect, the process chain involves many intermediate states and tasks, who are done by many different people with different resources and possible partner companies.

Figure 2.4 shows a possible version of the process modelled in Business Process Model and Notation (BPMN), a graphical notation for business processes. It shows the different responsible departments with their different tasks. The process starts on the upper left corner with the empty circle and ends on the lower right corner in the thick drawn circle. BPMN as modelling notation will be explained more in detail in Section 2.3.

The introduced business process can be divided into several sub processes, for example one per task or team. With that, the business process can be abstracted in different scopes and might get complex and large. A company can manage multiple of such business processes with Workflow Management Systems where the processes have different levels of detail and regard different aspects. Workflow Management Systems are software tools that allow the

(17)

ZĞůĞĂƐĞĂŶĞǁƉƌŽĚƵĐƚ DĂƌŬĞƚ ZĞƐĞĂƌĐŚWƌŽĚƵĐƚ ĞǀĞůŽƉŵĞŶƚĞƐŝŐŶDĂƌŬĞƚŝŶŐΘ^ĂůĞƐŶŐŝŶĞĞƌŝŶŐ

'ĞƚŝĚĞĂĨŽƌŶĞǁ

ƉƌŽĚƵĐƚ

/ŶǀĞƐƚŝŐĂƚĞƚŚĞ

ŵĂƌŬĞƚŽŶ

ĐŽŵƉĞƚŝƚŽƌƐ

&ŝŶĚŽƵƚǁŚĂƚ

ĐƵƐƚŽŵĞƌƐǁĂŶƚ

ĞƐŝŐŶƚŚĞƉƌŽĚƵĐƚ

ĚǀĞƌƚŝƐĞ

ŶŐŝŶĞĞƌ ƵŝůĚ

^ĞůůƚŚĞŶĞǁ

ƉƌŽĚƵĐƚ

Figure 2.4: The exemplary business process of releasing a new product modelled in BPMN.

(18)

Element Notation Sequence Flow

Start Event End Event

Task

Exclusive Gateway or Parallel Gateway

Inclusive Gateway

Table 2.1: Graphical notation for the supported BPMN elements that can be used to model a BPMN process.

definition, execution and surveillance of business processes.

2.3 Business Process Model and Notation (BPMN)

To model business processes, a wide range of notations and tools exists.

One example is the graphical notation Business Process Model and Notation (BPMN) which was developed by the Object Management Group (OMG) (http://www.omg.org/). The latest revision is the version 2.0. The specifi- cation [14] is freely available under http://www.omg.org/spec/BPMN/2.0/

and explains all elements and semantics.

Not all elements of BPMN are supported in this work. The focus lies on necessary elements, that can be used to create business processes. The graphical notation for these elements is shown in Table 2.1. Every element type is briefly discussed in this subchapter.

2.3.1 Sequence flows

Sequence flows represent the connections between elements and model the logical flow of a process. Sequence flows are always unidirectional and are supposed to have exactly one source and one target element. The graphical notation is a directed arrow, where the arrow points to the target element.

BPMN does not prohibit, that multiple sequence flows are pointing from the same source to the same target. Therefore, duplicated edges are possible.

although they do not provide further logic to the control flow.

(19)

2.3.2 Events

Events depict any kind of change that happens in a process. For BPMN this are all events that ”... will affect the sequence or timing of Activities of a Process.” [14, p. 83]

Start events: A start event symbolises a possible starting point of a process and is represented by an empty circle with a solid line. It must have no incoming sequence flow and is allowed to have multiple outgoing flows.

Each outgoing flow is seen as an independent parallel stream. There can be none or several start events in a process. However, BPMN defines, that if there exists an end event, there has to be at least one start event [14, p. 247].

End events: An end event marks an ending point of a process and is represented in a similar way as start events. The difference is the thickness of the line. An end event can have multiple incoming sequence flows and must have no outgoing flows [14, p. 249]. There can be none or several end events, similar to start events. But, if there exists a start event, at least one end event must exist [14, p. 239].

2.3.3 Gateways

Gateways are elements, that are used to control the logical flow of a process and are represented by a diamond shape. They are supposed to be used for splitting up a flow into several outgoing flows or merging several incoming flows into one. Gateways are supposed to have either multiple incoming and one outgoing or one incoming and multiple outgoing flows. But, they are allowed to have no incoming or no outgoing flows as well. Then, they have a special semantics, which is discussed in Section 4.5.5. BPMN supports a variety of gateways with different semantics. The following are selected ones that allow the modelling of a complete logical flow.

Parallel: A parallel gateway is represented by a diamond shape with a plus sign within. It represents a logical AND. That means, that all outgoing flows are activated as parallel flows. Multiple incoming flows are combined using the AND semantics, which means that the gateway triggers if and only if all incoming flows are active.

Exclusive: An exclusive gateway is either represented by an empty diamond or by a diamond with a cross in it. It represents the logical XOR.

That means, that only one of multiple outgoing flows is activated. On the combination semantics, it is only allowed that one incoming flow is active.

Inclusive: An inclusive gateway is represented by a diamond shape with a circle inside. It represents a logical OR with at least one outgoing flow getting activated. It can combine multiple parallel streams as well as handle

(20)

Sales

Figure 2.5: An empty pool called Sales.

one exclusive flow.

2.3.4 Tasks

Tasks are seen as atomic activities, respective to the abstraction level of the process. Therefore, they describe work, that has to be done by someone or something and is not split up into more detail. They are represented by a rectangle with rounded corners. BPMN allows a variety of tasks. For a complete list see [14, p. 156ff]. Tasks can have multiple incoming and multiple outgoing flows. The semantics for that is provided by BPMN and is discussed in the Sections 4.5.11 and 4.5.12. If tasks have no incoming or no outgoing flow, they are seen as implicit start or end points of processes, see Section 4.5.5.

2.3.5 Pools and lanes

Two further supported BPMN 2.0 elements are pools and lanes. Pools are used as indicator for participants, entities or roles involved in a process.

Every pool represents its own process, that can be independent of other processes, if it does not interact with other pools in, so called, Collaborations.

“A Pool is the graphical representation of a Participant in a Collaboration. A Participant ... can be a specific PartnerEntity (e.g., a company) or can be a more general PartnerRole (e.g., a buyer, seller, or manufacturer).” [14, p. 112].

The Figure 2.5 shows an exemplary pool called Sales. Pools are drawn as rectangles with a solid line and a small rectangle on the left or upper side, holding a label. That means, that pools can be oriented either vertically or horizontally in BPMN.

Pools are supposed to stretch over the whole width or height of the diagram. That means, that, if there exists a pool, no element is supposed to be outside of a pool. Several pools can exist in one diagram with the restriction,

(21)

that there exists a connection between the two pools in terms of communication between the involved BPMN elements. Otherwise the modelled process would not be connected and seen as two independent processes.

Every pool holds at least one lane. An empty pool, as shown in Figure 2.5, holds one unspecified lane. A pool with multiple lanes is shown in Figure 2.6. Lanes are used to allow a more detailed grouping mechanism. They are drawn like pools, but can not exist without an enclosing pool. Lanes can be filled with further lanes and allow a theoretically indefinite hierarchy depth.

“Lanes are used to organize and categorize Activities within a Pool. The meaning of the Lanes is up to the modeler. ... Lanes can be nested ... or defined in a matrix.” [14, p. 306].

2.4 Workflow graphs

For the analysis on structural correctness, the business processes will have to be transformed to workflow graphs. Workflow graphs have some similarities with business processes modelled in BPMN, which makes it easy to transform the processes.

2.4.1 Definition

The used workflow graphs are special forms of graphs [20].

Definition 2.3 (Graph). An undirected graph G = (V, E) is a tuple of vertices V and edges E, where an edge e is a two elemental subset of V , e = (v1, v2) ∈ E, v1, v2 ∈ V .

An edge is related to two elements of V , who can be the same. An exemplary graph is shown in the Figure 2.7 and defined as G = {V, E}

with V = {1, 2, 3} and E = {(1, 2) , (2, 2) , (1, 3)}. The graph consists of the vertices 1, 2 and 3, that are connected by three edges: One between the vertices 1 and 2, one related twice with vertice 2 and one connecting vertices 1 and 3. The two vertices 1 and 3, that are included in an edge e = (1, 3), are seen as adjacent to one another. Since the graph is undirected, there is

Sales Team BTeam A

Figure 2.6: A pool with two empty lanes Team A and Team B.

(22)

Figure 2.7: An undirected graph with three vertices 1, 2, 3 and three edges.

no further logical semantics for the edges. They can be traversed in both directions, which is restricted on digraphs through given edge directions.

A workflow graph is an enhanced graph with different types of vertices or nodes and a defined flow semantics through directed edges. The used workflow graph is an enhanced version of the definition by Sadiq et al. [20], where each node can hold process data in the form of a set of instructions.

Definition 2.4 (Workflow Graph). A workflow graph W F G = (N, E) is a digraph with a set of nodes N and edges E. N consists of the finite subsets N_start, N_end, N_activities, N_{f orks}, N_joins, N_splits, N_merges, Nf ull-f orks and N_or-joins. An edge e = (n_s, n_t) ∈ E, n_s, n_t∈ N is a tuple of the nodes n_s and n_t where the edge is pointing from n_s as source to n_t as target node.

The different subsets of N represent the different node types. N_start holds the start nodes, N_end the end nodes and N_activities all nodes of the type activity. N_{f orks} contains all fork nodes, N_joins every join node, N_splits the split nodes, N_merges each merge, Nf ull-f orks any full-fork and N_or-joins all nodes of the type or-join. The different node types have different connection rules and semantics, which will be explained in Section 2.4.2. General graph rules are the following:

The subsets of N have no element in common. A node n ∈ N is part of exactly one subset of N .

The sets Nstart and N_end contain exactly one element each, one start node and one end node: |N_start| = |N_end| = 1.

An edge (nsource, n_target) ∈ E creates a successor predecessor relation- ship between the involved nodes. The node n_target is seen as successor of n_source and n_source as predecessor of n_target. With that the connected nodes get a sequential order.

Edges must be distinct. That means that only one edge can exist that points from one specific node to another.

A path is a sequence of nodes n1, n₂, . . . , n_m−1, n_m ∈ N with ∀i ∈ {1, . . . , m − 1} : (n_i, n_i+1) ∈ E.

(23)

Element Notation Edge

Start End Activity

Split Merge Fork or Join

Full-Fork Or-Join

Table 2.2: Graphical notation for the workflow graph elements.

Each node n ∈ N\ (Nstart∪ N_end) has to lie on a path from the start node nstart ∈ Nstart to the end node nend ∈ Nend: nstart → · · · → n →

· · · → n_end.

The graph may contain loops as n1 → n₂ → · · · → n₁ where n₁, n₂ ∈ N ∧ n1 6= n2, so that a node can be reached from itself over at least one other node. Direct loops as n → n, n ∈ N are disallowed.

The BPMN diagrams are supposed to be expandable with process data, that is attached to nodes. The workflow graph model has to be able to represent this property as well. Therefore, the workflow graph is enhanced, so that every node n ∈ N can hold a set of instructions instr. The attached instructions instr are per default an empty set, instr = {} since not all BPMN elements will have attached process data and the transformation into workflow graphs can introduce new nodes, that do not have direct relations to modelled BPMN elements. Rules for the instructions are discussed in Section 5.1.

2.4.2 Semantics and graphical notation

Workflow graphs contain different types of nodes. Each type serves a different purpose and has specific semantics. Table 2.2 shows the graphical notation for the elements, that are introduced more in detail in the following.

(24)

Start: A start node symbolises the starting point of a workflow graph. It must not have any incoming edge and must have exactly one outgoing edge.

A start node is represented by an empty circle.

End: End nodes represent the end of a workflow graph. End nodes must have one incoming edge and no outgoing edges. End nodes are drawn similar to start nodes, but with an inner filled circle.

Fork: Forks are nodes that split up the control flow into several parallel ones. Because of that, forks must have one incoming edge and at least two outgoing edges. The graphical notation is a flat vertical rectangle.

Join: Join nodes are the opposite of forks. They combine multiple parallel streams into one, using the logical AND semantics. Therefore, they must have at least two incoming edges and one outgoing edge. Similar to forks are joins symbolised with flat vertical rectangles.

Split: A split node takes an exclusive decision between several possible outgoing flows. It must have one incoming edge and at least two outgoing edges. It is drawn with an empty diamond.

Merge: To combine exclusive flows into one, the merge node exists. It uses the logical XOR semantics and is the corresponding merging node for splits. It must have at least two incoming edges and one outgoing edge. The graphical notation is a triangle lying on the right side.

Full-Fork: Full-forks are similar to forks and splits, but different in their semantics. They can split into either parallel or exclusive streams. Therefore, they use the logical OR semantics and must have one incoming edge and at least two outgoing edges. A graphical notation for full-forks does not exist in the literature, as far as the author can tell. Because of that, the notation of a split containing a filled circle is used in this thesis.

Or-Join: Or-joins combine streams, that are either parallel or exclusive.

They must have at least two incoming edges and one outgoing edge and represent the logical OR semantics. Similar to full-forks, no graphical notation does exist and therefore, the notation of a merge containing a filled circle is used.

Activity: Activities represent atomic logic and must have one incoming and one outgoing edge. The graphical notation is an empty square.

An exemplary workflow graph, using the notation, is shown in Figure 2.8. The traversal semantics is similar to Petri nets, where tokens are used.

Tokens are transported through the graph and mark, which node is active at a specific time. The traversal of workflow graphs always starts at the start node, who creates a token and delivers it to the next node. The split node in the case of Figure 2.8. The split decides which path, from the two possible ones, it activates, by shoving the token either to the fork or the or-join. The fork creates parallel streams and puts a token on each outgoing edge, which

(25)

a1

a2

a3 start

node

split edge

fork activity join

merge end

node

full-fork or-join

Figure 2.8: An example of a workflow graph, taken from Prinz [18] and slightly changed.

are passed to the activities and combined again to one token by the join node. On the lower path, the or-join takes the token successfully, since it is the only token reaching it. It passes it on to the activity and the full-fork afterwards. The full-fork can now either send the token back to the prior or-join which would result in a loop, pass it on to the next merge in front of the end node or activate both edges. The merge now either gets a token from the join or the split and sends it further to the end node. End nodes consume any tokens that reach them.

2.5 BPMN modeller

There exists a wide range of tools, that allow the modelling of business processes in BPMN. For an official list of the OMG see http://www.bpmn.

org/#tabs-implementers. However, there were some specific criteria for the selection of a tool to use in this thesis, that are listed in the following.

The modeller should be

1. free to use in the educational environment of an university, 2. easily adaptable, and

3. allow the modelling of BPMN 2.0.

As a result, the Activiti Designer in the latest version 5.12 was chosen.

The Activiti Designer is a compilation of plugins for the Eclipse platform and part of the Activiti project, http://activiti.org/index.html. It is free to use, open source and free to be adapted. The Eclipse platform is a framework, that is mainly known as integrated development environment, that is extendable and adaptable through its plugin system, http://www.

eclipse.org/.

(26)

Figure 2.9: The Activiti Designer view containing a BPMN diagram. On the right side is the element palette with possible diagram elements. The upper user task is surrounded with further modelling features that are available when hovering over an element with the mouse.

2.5.1 Activiti Designer

The Activiti Designer was chosen because of prior work by the Chair of Soft- ware Technology at the Friedrich Schiller University Jena as well. A former prototype for the analysis of BPMN via workflow graphs was developed on an older version of the Designer. But it was not meant as general analysis framework and had therefore some restrictions.

Figure 2.9 shows the Activiti Designer view, holding a BPMN diagram.

The view is integrated in the Eclipse IDE, which was left out in this picture.

The Designer view consists out of two areas: the modelling pane on the left and the element palette on the right. When positioning the mouse over an element, additional buttons are displayed as on the upper user task. They provide further element wise modelling logic like deletion, changing of the element type or creation of a new node after it, including the connecting sequence flow. New elements can be positioned on the drawing pane with a click, if they are selected in the element palette.

Since the Activiti Designer is based on the Eclipse framework, it uses the extension mechanisms of Eclipse, which are addressed in Section 2.5.2. The Designer provides an extension point for validations of modelled diagrams.

New extensions and extension points can be added if necessary, which makes the Activiti Designer highly adaptable.

Figure 2.10 shows a rough representation of the responsibilities of the Ac-

(27)

:ĂǀĂsŝƌƚƵĂůDĂĐŚŝŶĞ

ĐůŝƉƐĞ

h/ ZĞƐŽƵƌĐĞƐ

DĂŶĂŐĞŵĞŶƚ ͘͘͘

ĐƚŝǀŝƚŝĞƐŝŐŶĞƌ

'ƌĂƉŚ

ƌĂǁŝŶŐh/

WDE

DŽĚĞů ^ĂǀĞͬůŽĂĚ ͘͘͘

WDE&ŝůĞƐ 'ƌĂƉŚ

DŽĚĞůŝŶŐ

>ŽŐŝĐ

WůƵŐŝŶ

DĂŶĂŐĞŵĞŶƚ WůĂƚĨŽƌŵ

Figure 2.10: Layer model of responsibilities of the Activiti Designer and the underlying Eclipse.

tiviti Designer and the underlying technologies. The Designer provides the logic and specific UI elements for the BPMN modelling. It saves the diagram in a specific model, to internally represent the BPMN process. Furthermore, it manages the file handling for saving and opening diagram files. The Activ- iti Designer does not define that logic on its own, it uses logic provided by the underlying Eclipse framework. Eclipse furthermore provides the basic UI, as well as the general resources handling. Eclipse also provides the framework for the definition, coordination and execution of plugins. Eclipse itself runs on the Java Virtual Machine as underlying runtime environment.

2.5.2 Eclipse and plugins

The Eclipse platform is based on an implementation of OSGi, a module system for Java [15]. That means, that an application based on Eclipse can be developed in a modular way with plugins. There is no central place where these plugins have to be declared, they are started and used dynamically.

Eclipse itself consists, except for the core, out of several plugins as well that use the same mechanism as every other existing plugin [12].

Every plugin can be seen as an application with its own source code and class loader. Plugins are self-describable, meaning that their definition is given in the plugin itself. But, plugins are not executable on their own, they have to be activated by other plugins or the OSGi implementation of Eclipse. Therefore, the Eclipse OSGi core initiates the plugin system and then activates plugins running explicitly on the core. These plugins then activate all other plugins, that are directly linked to them and so on. The result is a chain of plugin activations, that results in the application as it is

(28)

Figure 2.11: The Eclipse plugin concept of using resources of other plugins.

The resources can be source code or other resources like images, text files or similar. The using plugin can use or call the resources in its own logic.

with every plugin providing a piece of logic.

Plugins can be linked together in different ways. One possibility is, that a plugin uses or calls resources defined in another plugin, as shown in Figure 2.11. The plugin using or calling resources has no content wise influence on the resources it uses and the relation between the plugins is explicit. This plugin pattern could, for example, be used for helper logic that can be reused on various places by various plugins. Plugins then only have to define, that they depend on the resource plugin and can then use the resources provided as they wish.

The other possibility is, that plugins provide an extension point, where an unlimited number of plugins can contribute to. Extension points are interfaces, where other plugins can contribute specific implementations to generic definitions as interface or abstract classes. Plugins offering an extension point can use the specific implementations, without having a dependency definition to the other plugins. The concept is scheduled in Figure 2.12.

(29)

Figure 2.12: The Eclipse plugin concept of extension point collaboration.

A plugin provides generic logic that is specified by extending plugins. The defining plugin controls the specific implementations and instantiates and executes it on demand.

(30)

3 The framework

This chapter handles the designed analysis framework. It outlines the properties and schematic mechanisms behind it, gives an overview over the different components and how they are connected. It furthermore describes the interfaces between the different components more in detail.

3.1 Properties

Since the Activiti Designer is based on the Eclipse framework, the basic framework idea of Eclipse, introduced in section 2.5.2, was reused. That means, that the realised framework is a loosely coupled set of plugins, that communicate over defined interfaces or share data between each other. The plugins build up their connections to other plugins without a central logic.

Every plugin is independent and holds its own data and responsibilities. The plugins call each other on demand and share the data they want. Every module is individually maintainable or even replaceable, as long as the existing interfaces are met. Through the loose coupling, the framework is highly adaptable. New plugins can contribute to existing extension points and new extension points can be added to enhance the provided logic.

Figure 3.1 shows the involved plugins of the Activiti Designer, named with org.activiti.designer.* and the newly introduced plugins starting

ŶĂůǇƐŝƐ&ƌĂŵĞǁŽƌŬWůƵŐŝŶƐ

ĐƚŝǀŝƚŝĞƐŝŐŶĞƌWůƵŐŝŶƐ

ŽƌŐ͘ĂĐƚŝǀŝƚŝ͘ĚĞƐŝŐŶĞƌ͘

ŵŽĚĞů

ŝŶƚĞŐƌĂƚŝŽŶ

ǀĂůŝĚĂƚŝŽŶ͘ďƉŵŶϮϬ ŽƌŐ͘ĂĐƚŝǀŝƚŝ͘ĚĞƐŝŐŶĞƌ͘

Ƶƚŝů

ĞǆƉŽƌƚ͘ďƉŵŶϮϬ

ŐƵŝ

ĞĐůŝƉƐĞ

ŽƌŐ͘ĨƐƵ͘Ɛǁƚ͘ĂĐƚŝǀŝƚŝ͘ǁŽƌŬĨůŽǁ͘ǀĂůŝĚĂƚŽƌ ŽƌŐ͘ĨƐƵ͘Ɛǁƚ͘ĂĐƚŝǀŝƚŝ͘

ǁŽƌŬĨůŽǁ͘ĐŽĚĞŽƌƌĞĐƚŶĞƐƐ

ŽƌŐ͘ĨƐƵ͘Ɛǁƚ͘ĂĐƚŝǀŝƚŝ͘ǁŽƌŬĨůŽǁ͘

ĐŽƌƌĞĐƚŶĞƐƐ

ĐůŝƉƐĞWůƵŐŝŶƐ

Figure 3.1: The basic structure of the framework with loosely coupled plugins. Every plugin is independent and holds its own private data.

(31)

Figure 3.2: The extended technology layer model of Figure 2.10. On top of the Activiti Designer is a new layer that provides the transformation to workflow graphs and their analysis.

with org.fsu.swt.activiti.workflow.*. The various plugins provided by Eclipse are stated as cloud and not further detailed.

Summarising, the framework has the following properties:

Loosely coupled independent plugins.

Plugins organise the collaboration themselves.

Plugins communicate and share data over defined interfaces, called extension points.

Clear separation of responsibilities possible.

Highly scalable and maintainable through the loose coupling.

The earlier introduced layer model of the infrastructure (Figure 2.10) is extended with a new layer for the process analysis, see Figure 3.2. The new layer Workflow graph validation on top of the Activiti Designer is responsible for the transformation of BPMN into workflow graphs, the various analyses and the error reporting back to the Activiti Designer.

(32)

Figure 3.3: Overview over the components and their relations.

Judging by the earlier introduced differentiation into black, white and grey box frameworks, the designed framework can be seen as grey box framework. The underlying Eclipse platform can be and is extended through the Activiti Designer. The Designer again provides further extension possibilities, that are partly used by the validation. The validation provides the analysis possibility, that lets the framework be specifiable for the analyses desired.

3.2 Structure

The framework can be separated into three main components: the Activ- iti Designer plugins, the transformation to workflow graphs and analyser coordination in the plugin org.fsu.swt.activiti.workflow.validator and the analysers themselves (org.fsu.swt.activiti.workflow.correctnessand org.fsu.swt.activiti.workflow.codeCorrectness). Figure 3.3 sketches the specific relations between these components.

The biggest component is the Activiti Designer. It is responsible for the integration into Eclipse and therefore provides the logic and graphical user interface for modelling BPMN diagrams as well as the file management for saving and opening these diagrams. The various plugins depend on each other and form a complex subsystem. Of further interest is the plugin org.- activiti.designer.eclipse. It provides an extension point for validating modelled BPMN processes, called Validation in the figure. This extension point was already defined by the Activiti Designer but disabled. It was reactivated, to call the validator on significant diagram changes. A second extension point, SourceFeature, was introduced to this plugin. It gives the possibility to extend the element wise modelling functionality of the Activiti Designer and is used by the codeCorrectness plugin, see Section 3.4.

The pluginorg.fsu.swt.activiti.workflow.validator is the core of the

(33)

analysis framework. First of all, it delivers a validator for the Activiti De- signer, that can be called using the Validation extension point. The validator transforms the BPMN process into workflow graphs, coordinates the execution of the analyser plugins and reports the results back to the Designer. To be able to call external analysers, it defines the Analysis extension point, which is the basis for each analysis plugin. The validator plugin is addressed more in detail in Section 3.3.

The last component is the set of analyser plugins, two at the moment. The correctness plugin is provided by Thomas Prinz and analyses the structural correctness of the BPMN process via the corresponding workflow graphs.

Through this, it analyses the flow on deadlocks and lack of synchronization errors. A deadlock happens, if the control flow is blocked at some point and a lack of synchronization happens, when a part of a diagram is executed twice without intention [20]. The codeCorrectness plugin provides a possibility to add process data to the BPMN elements via the SourceFeature extension point and an analyser for it, see Section 3.4.

The separation into these components was done because of various rea- sons. The first and most important is the clear separation of responsibilities between the different parts. The designer handles the modelling and resource management. The other plugins are responsible for the analysis of the modelled diagram. The Activiti Designer plugins were changed the least as possible to stay close to the original state. This was done to avoid prob- lems and effort when migrating to a newer version of the Designer. The validator plugin, as the entry point for the analysis, contains the transformation to workflow graphs as well, since every scheduled analysis requires the workflow graph representation of the BPMN diagram. Because of that, it is only convenient to have the transformation and the analyses coordination in one place. To keep the analysis framework adaptable and the analyser logic separately, the analysis extension point was defined. The two analyser plugins correctness and codeCorrectness have been created to separate the analysis responsibilities. The codeCorrectness plugin contributes to the SourceFeature extension point as well, to have the process data attachement logic in one place.

3.3 Validator plugin

The Activiti Designer provides multiple extension points to work with the modelled BPMN processes. One of these is the Validation extension point.

It was used with the pluginorg.fsu.swt.activiti.workflow.validatoras a contributor.

The plugin provides the class BpmnAsWorkflowValidator, which extends

(34)

ďƐƚƌĂĐƚWƌŽĐĞƐƐsĂůŝĚĂƚŽƌ

нŐĞƚsĂůŝĚĂƚŽƌ/Ě;Ϳ нŐĞƚsĂůŝĚĂƚŽƌEĂŵĞ;Ϳ нŐĞƚ&ŽƌŵĂƚEĂŵĞ;Ϳ

нǀĂůŝĚĂƚĞŝĂŐƌĂŵ;ĚŝĂŐƌĂŵ͕ŵŽŶŝƚŽƌͿ ηĂĚĚDĂƌŬĞƌdŽŝĂŐƌĂŵ;ĚŝĂŐƌĂŵ͕

ŵĞƐƐĂŐĞ͕͘͘͘Ϳ

͘͘͘

Figure 3.4: AbstractProcessValidator with selected method definitions.

the class AbstractProcessValidator. Figure 3.4 shows a class diagram with selected methods of the abstract validator class. The important method is the validateDiagram(...) method, as it delivers the important model of the BPMN diagram to the validator. An error reporting is possible over various methods, concerning the addition of markers, as for example addMarkerTo- Diagram(...). Markers are used to report errors, warnings or information in Eclipse and therefore important to give the user detailed feedback. The use of markers will be described later in Section 6.1.

3.3.1 Calling the validation

The validator plugin is called only, when the diagram changes significantly.

That means, that it is called under three conditions:

when elements are added or deleted,

when a sequence flow is reconnected to a different element,

when the attached process data is changed.

The movement of an element or the alternation of the look of a sequence flow do not lead to an analysis, since these actions do neither change the structure of diagrams nor the semantics. Unnecessary analysis calls are avoided through that. This selective calling of the validator is realised, using the observer design pattern. In this pattern, a listener is linked with an element, where the element notifies the listener on specific events. The listener then decides, if it should execute event specific logic or not [9, chapter 4]. Figure 3.5 depicts the class structure how it is realised in the Designer. In the Ac- tivitiDiagramEditor a DiagramChangeListener is defined, that is registered to the internal diagram model. The model calls the listener when a change happens and the logic stored in the listener is executed. The listener uses meta data about the change, to decide on the importance of the change and

(35)

ŝĂŐƌĂŵZĞƐŽƵƌĐĞ

ͲůŝƐƚĞŶĞƌ

нŶŽƚŝĨǇŝĂŐƌĂŵŚĂŶŐĞ>ŝƐƚĞŶĞƌ;Ϳ

ĐƚŝǀŝƚŝŝĂŐƌĂŵĚŝƚŽƌ

ηƌĞŐŝƐƚĞƌŝĂŐƌĂŵŚĂŶŐĞ>ŝƐƚĞŶĞƌ;͘͘͘Ϳ ηƵŶƌĞŐŝƐƚĞƌŝĂŐƌĂŵŚĂŶŐĞ>ŝƐƚĞŶĞƌ;͘͘͘Ϳ ͲĐĂůůsĂůŝĚĂƚŽƌ;Ϳ

ŝĂŐƌĂŵŚĂŶŐĞ>ŝƐƚĞŶĞƌ

нƌĞƐŽƵƌĐĞŚĂŶŐĞĚ;Ϳ

WDEDŽĚĞů

ƉŵŶƐtŽƌŬĨůŽǁsĂůŝĚĂƚŽƌ

Figure 3.5: The observer pattern used for a diagram change listener. The listener is registered via the diagram editor of the Designer to the diagram model. The model notifies the listener, when the diagram changed. The listener then decides whether to call the validator plugin or not.

calls the validator if needed. To call the validator, it uses the logic provided by the editor class through the callValidator() method, that transfers the corresponding BPMN model to the validation plugin.

3.3.2 Logic of the plugin

As it was mentioned before, the plugin is responsible for managing the markers for a diagram, transform the BPMN diagram into workflow graphs and call the analysers. The general logic of the plugin is shown in Algorithm 3.1.

First of all, it clears the markers of the provided diagram. Afterwards, it extracts the BPMN elements out of the diagram and transforms them into workflow graphs. The class model for a workflow graph can be seen in Fig- ure 3.6. A workflow graph consists basically of nodes, where the start and end node are stored separately to the rest of the nodes. Through that, it is easy to access the starting or ending point of the graph and traverse it.

A workflow graph node consists of a distinct integer id, a field for its type, provided by an enumeration, and references to direct predecessors and successors. Through that, a bidirectional graph is build up, that makes it easy to traverse the graph from any node. Furthermore, nodes have a field, where attached process data in the form of source code can be stored, a set of corresponding BPMN elements and a field for any additional information. The transformation into workflow graphs is addressed more in detail in Section 4.

(36)

Algorithm 3.1 The simplified logic of the validator plugin.

clear the markers of the diagram d get the BPMN elements of d

transform the BPMN elements to workflow graphs for all workflow graphs wg do

get all available analysers analyserCalled ← true

while analyserCalled == true do analyserCalled ← f alse for all analyser a do

if a not executed yet then

if execute condition of a is true then call analyser a with wg

analyserCalled ← true mark a as executed end if

end if end for end while end for

report warnings and errors as markers for the diagram

t'EŽĚĞ

ͲŝĚ͗ŝŶƚ ͲĐŽĚĞ͗^ƚƌŝŶŐ ͲĞǆƚƌĂ/ŶĨŽƌŵĂƚŝŽŶ͗KďũĞĐƚ ƐƚĂƌƚ

Ϭ͘͘Ύ ŶŽĚĞƐ

ĞŶĚ

Ϭ͘͘Ύ ƐƵĐĐĞƐƐŽƌƐ

Ϭ͘͘Ύ ƉƌĞĚĞĐĞƐƐŽƌƐ

ффŶƵŵĞƌĂƚŝŽŶхх dǇƉĞ

н^dZd нE

нd/s/dz н^W>/d нDZ'

н&KZ<

н:K/E нKZͲ&KZ<

нKZͲ:K/E нhE&/E

ŽƌŐ͘ĂĐƚŝǀŝƚŝ͘ĚĞƐŝŐŶĞƌ͘ďƉŵŶϮ͘ŵŽĚĞů͘

&ůŽǁůĞŵĞŶƚ

Ϭ͘͘Ύ

WDEƌĞĨĞƌĞŶĐĞƐ tŽƌŬĨůŽǁ'ƌĂƉŚ

Figure 3.6: Class diagram of the transformed workflow graphs.

(37)

Figure 3.7: AbstractAnalyser for the Analysis extension point.

After the transformation completes, the coordination of the available analysers starts. The analysers are iterated as long as one is found, that can be executed. Every analyser is called maximal once. To determine, what analysers are possible to execute, the execute conditions defined in the analysers are evaluated. If a condition of an analyser could not be evaluated because of syntax errors, this is reported and the analyser is ignored in all future iterations. For more information on execution conditions, see Section 3.3.3.

If there is no analyser to execute any more, the plugin reports the collected errors and warnings from its own transformation and the analyses back to the Designer and therefore back to the diagram.

3.3.3 Analysis extension point

The analysis extension point demands the extension of the AbstractAnalyser class, as shown in Figure 3.7. An analyser has to provide an id, a name, that serves as description at the same time, and an implementation of the analyseGraph(...) method. The id and name do not serve a specific purpose so far, except for the logging of information and error reports.

The methods getCondition() and getVariables() do not have to be imple- mented, as the abstract class provides a default implementation. However, if an analysis wants to provide an execution condition that has to be re- garded before its execution, it can do so. The conditions are used to model dependencies between different analyses. To define a condition, variables are used. The variables serve the purpose to share data independent of workflow graphs in between the analyses and are valid per graph analysis. If a plugin wants to define any variables, it has to provide a name for each variable in the getVariables() method. All variables defined that way are included into the evaluation system and are available for the condition evaluation. For example, if a plugin defines the variable structuralCorrectness, another plugin can use this variable in a condition such as structuralCorrectness == true. The type correctness has to be handled excplicitely, since the type for variables

(38)

Operation Interpretation

A < B true if A is smaller than B A > B true if A is bigger than B

A <= B true if A is smaller or equal than B A >= B true if A is bigger or equal than B A == B true if A is equal to B

A ! = B true if A is not equal to B A && B true if A is true and B is true A k B true if A is true or B is true

!A true if A is not true

Table 3.1: Operators supported by the condition evaluation system used for the analyses. A and B are expressions, that are values, variables or an expression of two variables or values with an operator. Variables that are not primitive types like objects or strings can not be checked on their content but only on null.

is assumed to be an object by default.

To define conditional statements, different operators can be used, which are shown in Table 3.1. As grouping elements round parentheses can be used.

3.4 Process data plugin

The codeCorrectness plugin provides the possibility to attach source code to the BPMN elements and to analyse this code. It contributes to two extension points, to achieve these tasks, the SourceFeature and the Analysis extension point.

The contribution to the SourceFeature extension point is shown exemplary in Figure 3.8. An additional button src shows up on the operation palette around BPMN elements (starts, ends, gateways and tasks). It opens a source code editor for the specific element with line numbering, syntax highlighting and error reporting. This makes it easy to attach source code to the BPMN elements and provides an elegant way to edit it. The source code is validated per element, to check on structural and semantic correctness.

The errors are reported both into the diagram and into the problem view of Eclipse via the marker framework. The source code, the editor and its validation will be explained more in detail in Section 5.1.

As analysis, the plugin performs a data-flow analysis to determine the availability of variables throughout the graph. This is due to the feature, that variable definitions can be globally defined for successors of an element.

(39)

Figure 3.8: The Activiti Designer with an additional feature to attach source code via the src field. The text editor supports syntax highlighting and error reporting. Errors are furthermore reported to the Eclipse Problem view.

The data-flow analysis will be explained in Section 5.2.1.

To be able to perform the data-flow analysis, the graph has to be structured correctly. This is due to the fact, that the source code is seen as executional logic. If the process is not correctly modelled and therefore not runnable, the executional logic can never be executed properly and therefore is not needed to be analysed. That means, that this analysis has the condition of structural correctness, analysed by the correctness plugin, returns positively for the current workflow graph: structuralCorrectness == true. 3.5 Building the plugin structure

Since the framework is a set of loosely coupled plugins, they have to provide information on what they require, how they are activated and how they contribute or communicate with other plugins. As mentioned in Section 2.5.2, every plugin is self-describable. To describe properties of a plugin, two files must be provided. One is a manifest file, in which the general plugin details are described. As an example, Listing 3.1 shows an extract of the manifest file of the validator plugin. It is a formatted text file, where the structure is defined by the Eclipse platform. Through the manifest files, every plugin describes itself with its relationships to other plugins, which is the base for the architecture of loosely coupled plugins.

(40)

1 M a n i f e s t −V e r s i o n : 1 . 0

2 Bundle−M a n i f e s t V e r s i o n : 2

3 Bundle−Name : BPMN a s w o r k f l o w graph v a l i d a t o r

4 Bundle−SymbolicName : o r g . f s u . swt . a c t i v i t i . w o r k f l o w . v a l i d a t o r ; s i n g l e t o n := t r u e

5 Bundle−V e r s i o n : 1 . 0 . 0 . p r o t o

6 Bundle−A c t i v a t o r : o r g . f s u . swt . a c t i v i t i . w o r k f l o w . A c t i v a t o r

7 R e q u i r e −Bundle : o r g . a c t i v i t i . d e s i g n e r . e c l i p s e ; bundle−v e r s i o n

= ” 5 . 1 0 . 0 ” ,

8 o r g . a c t i v i t i . d e s i g n e r . model ; bundle−v e r s i o n = ” 5 . 1 0 . 0 ” ,

9 o r g . a c t i v i t i . d e s i g n e r . u t i l ; bundle−v e r s i o n = ” 5 . 1 0 . 0 ” ,

10 . . .

11 Bundle−A c t i v a t i o n P o l i c y : l a z y

12 Bundle−R e q u i r e d E x e c u t i o n E n v i r o n m e n t : JavaSE −1.7

13 Export−Package : o r g . f s u . swt . a c t i v i t i . w o r k f l o w . e x t e n s i o n ,

14 o r g . f s u . swt . a c t i v i t i . w o r k f l o w . marker ,

15 o r g . f s u . swt . a c t i v i t i . w o r k f l o w . model ,

16 . . .

Listing 3.1: Extract from the manifestfile of the validator plugin. It defines properties like name, version, how it can be activated, required plugins, exported packages and other information about the plugin. The file is used to build up the architecture of loosely coupled plugins without having a central management unit.

The file describes general information about the plugin, like the name, its version and what class is responsible for the activation of the plugin.

Furthermore, it lists all plugins which the plugin requires. The plugin can furthermore mark packages as visible for other plugins through the Export- Package section. Other plugins can use classes contained in these exported packages in their own code. A plugin does not have to export packages, it is however necessary if it provides extension points, at least for the package holding required classes or interfaces.

Another file, plugins must provide, is the plugin.xml, which is responsible for the extension point relationships to other plugins. As with the manifest file, it is a structured text file using a predefined XML syntax.

The XML syntax is defined by the Eclipse platform and consists of the basic elements extension-point and extension point. The plugin.xml of the validator plugin is shown in Listing 3.2, as an example. The validator plugin provides one extension point itself for other plugins and contributes to one existing extension point. Provided extension points are defined through the extension-point element and must have an id, a name and a schema definition. In the shown case this is the Analyser extension point with the

(41)

1 <?xml v e r s i o n =”1.0” e n c o d i n g=”UTF−8”?>

2 <? e c l i p s e v e r s i o n =”3.4”? >

3 <p l u g i n >

4 <e x t e n s i o n −p o i n t i d =”o r g . f s u . swt . a c t i v i t i . w o r k f l o w . a n a l y s e r . A n a l y s e r ” name=”Workflow graph a n a l y s e r ” schema=”schema / o r g . f s u . swt . a c t i v i t i . w o r k f l o w . a n a l y s e r . A n a l y s e r . e x s d ”/>

5 <e x t e n s i o n p o i n t =”o r g . a c t i v i t i . d e s i g n e r . e c l i p s e . e x t e n s i o n . v a l i d a t i o n . P r o c e s s V a l i d a t o r ”>

6 <P r o c e s s V a l i d a t o r

7 c l a s s =”o r g . f s u . swt . a c t i v i t i . w o r k f l o w . e x t e n s i o n . a c t i v i t i . BpmnAsWorkflowValidator”>

8 </ P r o c e s s V a l i d a t o r >

9 </ e x t e n s i o n >

10 </ p l u g i n >

Listing 3.2: The plugin.xml of the validator plugin as an example of the definition of extension point relationships. Provided extension points are defined using the extension-point notation. Contributed extensions are described with the extension point element.

correspondingexsdschema file. The schema is describing the concrete details about what information how and how often have to be provided by a con- tributing plugin. The extension pointelement is used for extension points, where the plugin contributes to, in this case the Activiti Designer validation extension point. The validator plugin has to provide a ProcessValidator, which is done with the BpmnAsWorkflowValidator class.

Realisation of a framework for the analysis of business processes

Degree project