Conference PaperPDF Available

A Simple Algorithm for Automatic Layout of BPMN Processes


Abstract and Figures

Badly and inconsistently layouted business processes are hard to read for humans and therefore lack comprehensibility. Furthermore, processes generated by software have no layout at all. If stakeholders cannot comprehend the process descriptions, they are unable to validate them and find mistakes. By offering a fully automatic layout algorithm for BPMN, it is possible to layout business processes in a consistent and clear way so that stakeholders can better and quicker comprehend the contents. This leads to better comprehensiblity and thus to better communication in BPM/SOA projects and allows for consistent process layouts throughout projects and enterprises - independent from the model source. In addition, this permits using generated models without manual layouting.
Content may be subject to copyright.
A Simple Algorithm for Automatic Layout of BPMN Processes
Ingo Kitzmann, Christoph K¨
Leibniz Universit¨
at Hannover
Software Engineering Group
Welfengarten 1, D-30167 Hannover, Germany
{ingo.kitzmann, christoph.koenig}
Daniel L¨
ubke, Leif Singer
Leibniz Universit¨
at Hannover
Software Engineering Group
Welfengarten 1, D-30167 Hannover, Germany
{daniel.luebke, leif.singer}
Badly and inconsistently layouted business processes are
hard to read for humans and therefore lack comprehensibil-
ity. Furthermore, processes generated by software have no
layout at all.
If stakeholders cannot comprehend the process descrip-
tions, they are unable to validate them and find mistakes.
By offering a fully automatic layout algorithm for
BPMN, it is possible to layout business processes in a con-
sistent and clear way so that stakeholders can better and
quicker comprehend the contents.
This leads to better comprehensiblity and thus to better
communication in BPM / SOA projects and allows for con-
sistent process layouts throughout projects and enterprises
– independent from the model source. In addition, this per-
mits using generated models without manual layouting.
1 Introduction
Nowadays, the Business Process Modeling Notation
(BPMN, [11]) gets more and more established as the stan-
dard graphical notation for business processes. This suc-
cess is partly based on offering simplicity to the user, while
still providing rich expressiveness. Additionally, BPMN is
strongly linked with BPEL, the Business Process Execution
Language. Different conversions between BPMN, BPEL
and other formats exist (e.g., [8] and [7]), serving several
needs for interoperability.
Even though the conversions to and the generation of
BPMN models required in this context produce semanti-
cally sound process models, a clear visual layout would be
beneficial. This is all the more important if the produced
BPMN models are to be used as tools in discussions about
the actual processes, e.g., in requirements engineering or
BPM activities. Automating this layouting process to pro-
duce BPMN diagrams that can be easily understood should
ideally be just another step of the conversion / generation of
the BPMN models.
Similarly, manually created models benefit from auto-
matic layout, which reduces the required effort and guar-
antees a consistent layout for different models created by
different people.
This paper presents a layout algorithm which takes a
BPMN model in eRDF-format as input and layouts it.
eRDF is used by the Oryx Editor1, a web-based modeling
tool supporting business process modeling in BPMN, cre-
ated by researchers of the Hasso-Plattner-Institut in Pots-
dam, Germany. The algorithm was developed as a contribu-
tion for the InformatiCup 20082, a student competition by
the Gesellschaft f¨
ur Informatik e.V. The Oryx Editor and its
format were chosen since it is freely available and needs no
installation on the client.
The main focus is the positioning of the elements, having
the greatest impact on the final layout. Reduced effort was
put into positioning the edges.
2 Related Work
There are many different graph layout algorithms in use
today. The characteristics of the generated layouts of the al-
2009 IEEE Conference on Commerce and Enterprise Computing
978-0-7695-3755-9/09 $25.00 © 2009 IEEE
DOI 10.1109/CEC.2009.28
© 2009 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or
future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for
resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works.
gorithms differ strongly, as most algorithms target a special
application of the created diagrams – e.g., organizational
charts or circuit design. Most of the general graph layout
algorithms are not suitable for BPMN since they do not
take into account the special constraints that can improve
the readability of BPMN diagrams.
Force-based layouts (e.g., [4]) and spectral layouts (see
[6]) produce rather organic diagrams and target dynamic,
often changing graphs. These are not suitable for visualiz-
ing business processes. Also, their results may differ signif-
icantly between different runs, lacking the consistency the
approach presented in this provides.
Orthogonal layouts – e.g., [1] – produce results less or-
ganic, but may not really be focused on clarity. Instead,
common goals of these algorithms are, e.g., minimizing the
area taken up by a graph. This may ignore or even contra-
dict the clarity required from BPMN diagrams to make them
effective tools for communication. Specialized orthogonal
layout algorithms may nonetheless be able to produce satis-
fying results for BPMN.
Hierarchical layouts, as in [2], are even better suited for
BPMN. As the hierarchies given by splits and joins, pools,
lanes, and subprocesses may be taken into account, the pro-
cess can be understood much better when layouted by such
an algorithm. Although general hierarchical layout algo-
rithms will still lack in some aspects concering BPMN lay-
outs, they can be improved with constraints tailored for the
requirements BPMN. As the algorithm presented in this pa-
per respects and utilizes all these hierarchies, it is consid-
ered to fall into this class of algorithms.
[3] introduces the concept of divisions to distribute a dia-
gram across multiple pages. While this approach addresses
the lack of overview inherent in large diagrams, it does not
aim to improve existing layout algorithms significantly –
any such improvements seem to be considered side effects
of the divisions. The actual layouting is done using existing
algorithms, namely an orthogonal one for an initial layout
and a sketch-driven orthogonal one in a second run after the
division. The report does not go into much detail concern-
ing the runtime properties of the approach. Considering the
algorithm layouts the whole process once, and, then again
each division created in the intermediate step, a more de-
tailed description of its runtime behaviour would be desir-
Graphviz [5] is a framework for graph layout, supporting
several different layout algorithms. Due to its open license,
it is used in many applications dealing with process visual-
ization – e.g., ProM [10]. Preliminary trials using the ex-
ample process from section 4 as input resulted in the graph
shown in figure 1. While the produced layout is certainly
good enough to provide some understanding of the process,
the algorithm presented in this paper further improved com-
prehensibility. Especially the vertical association of open-
ing and their corresponding closing gateways is a huge ad-
vantage in the subjective opinions of the authors of this pa-
per. Still, a more thorough examination of Graphviz might
lead to more satisfactory results.
 
Figure 1. The layout produced by the dot tool
from Graphviz.
3 Algorithm Description
In conceiving the algorithm presented in this paper, the
authors started by deciding that it would be favourable for a
graph layout algorithm to have no need for an understanding
of the whole process described by a BPMN model.
The approach therefore operates mainly locally and
avoids having to analyse too much of the process. This sec-
tion presents the algorithm. It begins with the prerequisites,
explains the basic idea and then goes into the details of some
3.1 Prerequisites
BPMN models must conform to some rules in order to
being processed by the algorithm. Most rules are related to
how processes are syntactically modeled. The only techni-
cal rule is that all elements (except for pools, lanes, edges
and uncollapsed subprocesses) must have set a size.
This was delegated to the generation of the model be-
cause this way the algorithm does not have to distinguish
between generated and manually created models. In the lat-
ter, elements are typically sized according to their content,
e.g., the length of the text. To preserve the effort that may
have gone into this, the sizes are not being overridden with
standard values. For generated models, the generation step
can set standard sizes for all elements.
Syntactical modeling rules are:
The model must have at least one start event or at least
one element without any incoming links.
Each edge must be connected (no open ends).
A subprocess must not be empty and must be isolated,
i.e., there are no edges between the subprocess and the
parent process.
Each element is connected with another one by only
one edge and must have no link to itself.
Groups are not supported by the algorithm because the
eRDF does not save a logical connection between the
group and the elements which are grouped together.
Most of these rules ensure the syntactic correctness of the
input models. Because of their simplicity, they should be
easily satisfiable.
3.2 Layout Goals
Some requirements from the competition are concerned
with the layout and are supposed to ensure consistency. The
following paragraphs will explain why these requirements
are useful.
First, the process flow should be from left to right. This
matches with the horizontal progression of text in western
Exception handling of tasks should be below the task, to
not desturb the process flow.
Elements after a split-gateway (which has more than one
outgoing edge) should be right of it (not directly under or
above). The inverse applies for elements before a join-
gateway (which has more than one incoming edge), i.e.,
the preceding elements should be left of it. Additionally,
joins should be at the same height as the correspondent split.
Both requirements help in identifying corresponding gate-
3.3 Basic Idea
Only a few simple ideas lead to the algorithm. The first
one gives a more general look at the BPMN process: ele-
ments were first classified by those attributes important to
the layout. The result of this classification are the types
shown in table 1. An element can have different types, e.g.,
a gateway can be a split and a join at the same time.
Table 1. Types for a more general look at the
Type Description
Edge Sequence flow, message flow, data flow
Element Every element of the process which is
not an edge
Start Event All types of start events
End Event All types of end events
Join An element with more than one incom-
ing edge
Split An element with more than one outgo-
ing edge
Docked Event An intermediate catching event, which
is docked at a task
The first problem to address is the global effect of lo-
cal changes. A displacement of one element has effects on
the elements connected with it, and so on. A solution was
needed that allowed doing local changes while automati-
cally maintaining the relative alignment of other elements –
i.e., whether an element is above, below, to the left or to the
right of another. That solution, called the Grid, is presented
in section 3.4.
The processing order was chosen to be along the progres-
sion of the process. Therefore, a topological sort seemed
helpful. Unfortunately, BPMN allows cycles, making it im-
possible to use an ordinary topological algorithm. In section
3.5, a slight modification is shown which gives the desired
With these preparations, the process can be layouted
from left to right, and each element is positioned relative
to its predecessors. This is described in section 3.6. After
that, section 3.8, describes some heuristics enhancing this
general approach. Once each element has its position in the
Grid assigned, the coordinates for the elements are calcu-
Finally, the edges are set. Based on the type of the edge,
the types of the source and target element, and their relative
position, one type of edge is chosen. Amongst others, there
are a 90 degree corner, a step, and a direct connection. Each
edge is layouted independent of all others, i.e., other edges
have no effect on the layout of one edge.
3.4 The Grid
One part of the solution presented in this paper, the Grid,
is inspired by spreadsheets. Spreadsheets provide functions
to insert rows or columns (i.e., local changes) and move the
other cells away (a global effect). But their relative posi-
tions are maintained.
Figure 2. Sketch of the Grid with newly added
This idea was adapted to the Grid. It starts off with one
cell, while rows and columns are added as needed. With
the Grid it is possible to add branches without influencing
the relative positions of elements which were already set.
Figure 2 shows a simple example, in which the lower task
added a row and pushed the upper gateways and task out-
wards. But they are still above and between the lower gate-
ways. As the algorithm layouts from left to right, each split
leads to more rows.
For calculating the real coordinates of the elements from
the Grid, for each row and column the maximal height and
width is determined. These are set for the according row
and column. Then each element is placed in the center of its
cell. This way, direct connections to succeeding elements
with different dimensions will still be straight.
3.5 Modified Topological Sort
To be able to layout the BPMN from left to right, an or-
dering of its elements is required. The ordering must ensure
that all predecessors of an element are layouted before that
element (i.e., those left of it). To accomplish this, a mod-
ified topological sort was developed. The modification is
based on the variant of the topological sort which uses an
incoming link counter in the nodes.
Listing 1. Pseudocode for the modified topo-
logical sort
1G Set of nodes to sort
2L Empty list for the sorted elem.
3S Empty Set for nodes with no incoming edges
4B Set of backwards edges
5while G is non-empty do
6// search free nodes
7foreach node n
8if incoming link counter of n = 0 then
9insert m into S
10 if S is non-empty then
11 // ordinary top-sort
12 remove a node n from S and G
13 insert n into L
14 foreach node m with an edge e
15 from n to m do
16 remove e
17 decrement incoming link counter from m
18 else // cycle found
19 // find loop entry
20 foreach join j in G do
21 if incoming link counter of j
22 < initial incoming link counter of j then
23 J j and break
24 // process loop entry
25 foreach remaining incoming edge e of J do
26 replace l with backwards edge b
27 add b into B
29 output: L,B
As opposed to the standard topological sort, the version
presented here (listing 1) is able to handle cycles like those
appearing in BPMN diagrams. The standard algorithm is
used until it has detected a cycle and cannot go on. In
this case, the algorithm seeks an entry point into the cycle,
which is an element that has an already processed incoming
edge. This is based on the idea of dominant nodes (see [9]).
Now all remaining unprocessed incoming edges are flipped
virtually (they become outgoing edges) to break the cycle
as shown in figure 3. The standard topological sorting can
go on to the next cycle, and so on.
After this process, the graph is acyclic and a topologi-
cal ordering of the graph has been achieved, ensuring the
criteria from above.
Figure 3. The process before and after the
first topological sort. The cycle was re-
moved. The virtual reversed edge is shown
Since elements like the task element in figure 3 now only
have incoming edges, they will be ranged and layouted after
the second gateway. As this is undesirable, to achieve a
layout as in figure 3, the reversed edges are being traced
back to the next split or join gateway and flip the edges on
the way as well. In figure 3, the lower right edge would
also be reversed. This works best with cycles with a single
exit. Cycles with multiple exits (in general all cycles with
additional splits or joins on a backwards path) tend to look
a bit odd because backtracking stops at the splitting node,
which may lead to a long backwards edge.
In some cases, this may lead to new cycles. If the gate-
ways in figure 3 were merged into one (see figure 4) this
would be such a case. But these types of cycles (splits with-
out joins) should be avoided anyway, as they are not as clear
as the one in figure 3.
Nevertheless such situations have to be dealt with, which
is why the modified topological sort will be run again on
the resulting graph – only this time without backtracing the
reversed edges.
Figure 4. One type of cycle, where backpatch-
ing of reversed edges leads to a new cycle.
3.6 Positioning of elements
With the Grid and the topologically ordered elements, all
preparations for positioning the elements are in place. The
ordering ensures that at each step all preceding elements of
the current element are already in the grid. For the current
element, one of the following three options is chosen:
In the simplest case, the current element has only one
incoming edge and the preceding element is a basic
element (i.e. no split or join etc.). Then the current
element is put into the cell right of the preceding ele-
If the current element is a join, it is put into the column
right to the rightmost one of the preceding elements.
When the corresponding split is found, the current el-
ement is put into its row. Else, the middle row of the
preceding elements is used (comp. fig. 5).
Figure 5. On the left, the join is centered. On
the right, the row of the split is preferred.
The succeeding elements of a split are distributed
equally right of the split, centering them vertically rel-
ative to the split. For this, new rows are inserted into
the Grid. Because the current element – one of the
succeeding elements of the split – does not know its
siblings (and they have possibly not been positioned
yet) the positions of the elements after a split have to
be prepared by the split. It marks the cells it deems
reasonable for its successors (see section 3.8.2). Then
the current element either uses this mark or rejects it if
there is a rule with higher priority – e.g., joins trying
to align with a different split.
3.7 Pools, Lanes and Subprocesses
Because subprocesses are isolated, they can be processed
easily. For each subprocess, the layout algorithm runs once.
The complete process is being processed from the most in-
ner to the most outer subprocesses, so the algorithm can
calculate the size of the subprocess for each parent process.
After that, the parent process is layouted without any atten-
tion given to the content of the subprocess. This works since
in eRDF, elements of a subprocess have coordinates relative
to the parent element.
Collapsed pools also do not need much special handling,
because they do not contain other elements. They are just
placed at the top of the diagram, get a common height and
are spanned across the whole width of the diagram. Tech-
nically, they get their own row in the grid and are removed
from the regular processing order.
But more special handling is needed for uncollapsed
pools and lanes, because they are partly isolated, as ele-
ments of one lane must not be placed in the area of an-
other lane, and partly unisolated, as elements of lanes and
the global process can be connected with message and se-
quence flows nearly without restrictions.
The chosen solution for this problem is to sort the ele-
ments of the global process and the elements of lanes and
pools together (as described in section 3.5). Then the ele-
ments are placed in seperate grids: one grid for each pool
or lane and the global process. In this way, the relations
between process parts are preserved while elements cannot
float into areas they do not belong into.
But for this solution the seperate grids need a sort of syn-
chronisation, e.g., the grids must have the same width at
all times. This is achieved by a supervising datastructure
named the SuperGrid.
Also, positioning of elements (see section 3.6) needs
some modifications in cases where the predecessor of the
current element belongs to another lane. E.g., for the sim-
ple case, the current element is placed into the row that is
nearest to the lane of its predecessor.
If the lane of the predecessor is above the element’s lane,
it is placed in the topmost row of the target lane. If it is
beneath, the bottommost row is chosen.
To conclude, the order from top to bottom is: collapsed
pools, pools and lanes, and the global process.
3.8 Heuristics
Some simple heuristics were added to the algorithm
which improve the layouts for some cases.
3.8.1 Interleaving
As discussed in section 3.6, a split may insert new rows into
the grid, pushing back older rows. While this works great
for nested split / join pairs, it leads to an inconvenient and
space-consuming layout for sequential split / join pairs. As
shown in figure 6, the rows of the later split / join pair push
apart the rows of the first split / join pair.
Figure 6. The process before the Interleaving.
Task 1 and 2 have been moved outwards by
the rows of Task 3 and 4.
To conquer this, the Interleaving heuristic was devel-
oped. It simply checks whether there are any rows in the
grid that can be interleaved after all elements have been
placed. Two rows can be interleaved if and only if they are
adjacent and for each used cell (a cell where an element is
placed) in one row, the adjacent cell in the other row is free.
If two rows can be interleaved, all used cells of one row
are moved to the other row. The row that is now empty is
being deleted. This process continues as long as there are
any rows which can be interleaved. This leads to a more
compact grid and mitigates the problem mentioned above
in many cases (see figure 7).
Figure 7. The process after the Interleaving
3.8.2 Prelayout
As written in section 3.6, a split prepares the layout for its
following elements. This helps to arrange them equally.
A simple heuristic is used to improve the ordering of the
following elements: text annotations at the top, data objects
below, and finally sequence flows at the bottom. If one of
the sequence flows is a direct connection to a join, this con-
nection is centered. This should avoid text annotations be-
tween data and sequence flows. Also, directly connected
joins have a straight egde between them.
3.8.3 Using the Grid for Edge Layout
It was tried to use the information in the Grid to enhance
the layout of the edges. To show the Grid may be used for
edge layout as well, a simple proof of concept was imple-
mented. The algorithm looks for a direct horizontal edge
if there are elements in the row between the source and the
target of the edge. If there are any, the algorithm chooses
a different layout for the edge. This could be adapted for
other layout types of the edges. But as the focus of the al-
gorithm primarily lies on the positions of the elements, this
was not pursued further.
4 Example
Figure 8. The BPMN-model before the layout-
To establish further understanding of the algorithm, an
example will now be given. It begins with a manually mod-
eled process as shown in figure 8. It describes an online
service into which the user may log in, get shown their new
messages and tasks and then may accept a task or read any
number of messages and finally log out. The login has a
timeout, which leads to a cancellation of the process.
Figure 9. The BPMN-model after the topolog-
ical sort
At first, the elements were topologically sorted as shown
in section 3.5. In this step, backwards edges are detected
and virtually reversed. In the example, the dashed edge
in figure 9 is the only virtually reversed egde. As a possi-
ble topological sort, the following order is the result: Start
Event, Login, And, Cancel, End Event, Show new Messages,
Show new Tasks, And, Xor, Accept Task, Xor, Read Message,
Xor, Xor, Logout, End Event (the docked event is fixed to the
Figure 10. The BPMN-model during the inser-
tion of elements into the Grid
Now, the elements are put into the grid. Figure 10 shows
the situation after insertion of the second And-Gateway, fig-
ure 11 shows the situation after all elements have been put
into the grid. It must be pointed out that the edges are not set
yet, they are only shown for better overview. It is plain to
see how the tasks Show new Messages and Show new Tasks
are pushed outwards by the later branches.
The Interleaving (see fig. 12) works against this effect:
both tasks and the cancel-branch are pulled more to the mid-
dle. Nearly all elements have their final positions in the grid
now; only the docked event is missing. The real coordinates
Figure 11. The BPMN-model after the inser-
tion of all elements into the Grid
are now being calculated from the grid. Finally, the docked
event is being aligned with its task.
All preconditions for calculating the edges are now ful-
filled. The result is the layout shown in figure 13.
Figure 12. The BPMN-model after the Inter-
Figure 13. The final layout of the BPMN-
5 Implementation
The algorithm was implemented as a small Java tool. It
has a simple GUI, which allows to specify the input and
output files. But it can also be used via the command line.
This permits using it on a server or as part of a tool chain.
To further assist the user, the GUI has special support for
the Oryx Online Repository3. It allows the user to drop pub-
lic models from the repository into the tool without needing
to export, download and open them. This can save a lot of
6 Runtime Properties
As the runtime of the algorithm depends much on the
type of the input model (e.g., whether it contains subpro-
cesses) it is nearly impossible to give formal runtime prop-
erties. To get a rough estimation of the runtime, mod-
els which fulfilled certain criteria (e.g. a constant ratio of
connections to elements) were randomly generated. Then,
the algorithm layouted these models, running in the Java
SE Runtime Environment version 6 on a computer with an
AMD Athlon 64 X2 Dual Core 3800+ CPU, 2 GB of RAM,
and Microsoft Windows XP as its operating system.
Models with 100 elements and a total of 150 connections
between them were layouted in an average time of 370ms.
Models with 500 elements and a total of 750 connections
between them needed an average time of 5680ms. Each av-
erage time was calculated based on 25 test runs in which
5 different random models were layouted. Thus, the algo-
rithm should be fast enough for reasonably complex mod-
7 Conclusions & Outlook
Quite good layouts were achieved for BPMN processes
with a very simple approach. It was shown that it is pos-
sible to layout a BPMN model with a focus on the syntax
and not on the semantics of the model elements. Also, it
is possible to operate mainly locally on the graph, avoiding
much global analysis and complex algorithms. Satisfying
solutions to the main challenges of BPMN layouting were
found, namely cycles, pools, and lanes.
There are some points where the algorithm could be im-
proved. First, there should be a much more intelligent lay-
out algorithm for the edges. It could avoid calculating edges
which run through elements. For this, the Grid could be
used as in section 3.8.3 or combined with exisiting algo-
rithms for edge layout.
Also, there could be more differentiation between the
different types of edges (sequence flows, message flows,
data flows). The non-differentiating approach works fine if
there is mainly one type. Sometimes, it gives strange results
if the types are intensively mixed. One possible variation
could be to privilege the most frequent type to dominate the
Lastly, it could be feasible to calculate different variants
of a model and have the algorithm choose the best one. Pos-
sible variants might differ in the arrangement of pools and
lanes and the positions of branches after splits. The biggest
challenge here is finding a metric to rate each variant. The
number of crossed edges could be a starting point for such a
metric. While the algorithm doesn’t even consider edges yet
and thus treats planar graphs the same as non-planar graphs,
the application of such metrics might improve the compre-
hensibility of the latter significantly.
The next step is integrating the algorithm with the afore-
mentioned Oryx Editor in cooperation with the Hasso-
Plattner-Institut. This will allow everyone to evaluate the
algorithm or download its source code as part of the Oryx
[1] T. Biedl and G. Kant. Algorithms ESA ’94, chapter A better
heuristic for orthogonal graph drawings. Springer Berlin /
Heidelberg, 1994.
[2] P. Eades, X. Lin, and R. Tamassia. An algorithm for draw-
ing a hierarchical graph. International Journal of Computa-
tional Geometry and Applications, 1996.
[3] P. Effinger, M. Siebenhaller, and M. Kaufmann. Improving
business process visualizations. Technical report, Eberhard-
at, T¨
ubingen, 2009.
[4] T. M. J. Fruchterman and E. M. Reingold. Graph drawing by
force-directed placement. Software - Practice & Experience,
21(11):1129–1164, 1991.
[5] E. R. Gansner and S. C. North. An open graph visualiza-
tion system and its applications to software engineering. In
Software-Practice and Experience, 2000.
[6] Y. Koren. Computing and Combinatorics. Springer Berlin /
Heidelberg, 2003.
[7] D. L ¨
ubke, K. Schneider, and M. Weidlich. Visualizing Use
Case Sets as BPMN Processes. In Proceedings of REV
Workshop, co-located at RE 2008, Barcelona, Spain, 2008.
[8] C. Ouyang, M. Dumas, S. Breutel, and A. H. ter Hofstede.
Translating standard process models to bpel. In CAiSE 2006,
[9] R. T. Prosser. Applications of boolean matrices to the anal-
ysis of flow diagrams. In IRE-AIEE-ACM ’59 (Eastern):
Papers presented at the December 1-3, 1959, eastern joint
IRE-AIEE-ACM computer conference, pages 133–138, New
York, NY, USA, 1959. ACM.
[10] M. Song and W. van der Aalst. Towards comprehensive sup-
port for organizational mining. In Decision Support Systems,
[11] S. A. White. Business Process Modeling Notation (BPMN)
Version 1.0. Business Process Management Initiative,, 2004.
... Kitzman et al. developed a grid-based layout algorithm for BPMN models [5]. The generator specifies the ordering of BPMN elements relative to each other (e.g., next to, below, . . . ...
... As such, we wanted to incorporate our findings into a generator tool. As the basis we chose the algorithm of Kitzmann et al. [5] because it generates diagrams that look more like human-modeled BPMN. The algorithm by Effinger [3] tries to excel on objective metrics but does not necessarily place consequitive activities in a row in order to avoid edge crossings. ...
Full-text available
BPMN Process Models are the basis for implementing and optimizing business processes in the era of digitization. Good layouts of BPMN diagrams help readers to better understand them. In order to improve the quality of automatic layouting, we need to identify subjective and objective characteristics of diagram layouts. While research into objective criteria has been ongoing, we want to evaluate subjective layout preferences by model readers. Therefore, we conducted an experiment, which let participants select the preferred layout out of two layout variants. The experiment yields significant findings for subjective layout preferences, e.g., with regards to spacing of elements, layout options after gateways, and the routing of message flows. The findings help modelers to produce better process models and we incorporated them in an automatic layout tool.
... For this purpose, the question arises how careless reconciliation can be identified, as the reconciliation behavior of modelers is influenced by their personal preferences [183]. Literature on the layout of process models, e.g., [93,129,201,238], and trees, e.g., [256], derives desirable properties of process models. For instance, [201,238] report that not only edge crossings but also the number of bend points should be minimized. ...
... Unfortunately, such guidelines might work in opposite directions as edge bend points can be used to reduce the number of edge crossings. Similarly, [201,238] argue that edges should be drawn in the direction of the process' flow, while [129] argue that the process model should consume as less space as possible. By making the process model as compact as possible, edges against the direction of the process' flow might be necessary. ...
Full-text available
Business process models have gained significant importance due to their critical role for managing business processes. In particular, process models support the common understanding of a company’s business processes, enable the discovery of improvement opportunities, and serve as drivers for the implementation of business processes. Still, a wide range of quality problems have been observed. For example, literature reports on error rates between 10% and 20% in industrial process model collections. Most research in the context of quality issues of process models puts a strong emphasis on the outcome of the process modeling act by analyzing the resulting model. However, it is rarely considered that process model quality is presumably dependent on the process followed to create the process model. This thesis strives for addressing this gap by specifically investigating the process of creating process models. In this context, different actions on several levels of abstraction might be considered, including elicitation and formalization of process models. During elicitation information is gathered, which is used in formalization phases for actually creating the formal process model. This thesis focuses on the formalization of process models, which can be considered a process by itself—the Process of Process Modeling (PPM). Due to the lack of an established theory, we follow a mixed method approach to exploratively investigate the PPM. This way, different perspectives are combined to develop a comprehensive understanding. In this context, we attempt to address the following research objectives. First, means for recording and performing a detailed analysis of the PPM are required. For this, a specialized modeling environment— Cheetah Experimental Platform (CEP)—is developed, allowing a systematic investigation of the PPM. Further, a visualization for the PPM, i.e., Modeling Phase Diagrams (MPDs), is presented to support data exploration and hypotheses generation. Second, we attempt to observe and categorize reoccurring behavior of modelers to develop an understanding on how process models are created. Finally, we investigate factors that influence the PPM to understand why certain behavior can be observed. The findings are condensed to form a model on the factors that influence the PPM. Summarized, this thesis proposes means for analyzing the PPM and presents initial findings to form an understanding on how the formalization of process models is conducted and why certain behavior can be observed. While the results cannot be considered an established theory, this work constitutes a first building block toward a comprehensive understanding of the PPM. This will ultimately improve process model quality by facilitating the development of specialized modeling environments, which address potential pitfalls during the creation of process models.
... For these purposes, the quality of the process model is of importance. Model quality has been classified to syntactic ("correctness" of a model), semantic (the extent to which the model captures the behavior of the domain), and pragmatic (usefulness) quality [14]. When focusing on pragmatic quality, i.e., the correspondence between a model and people's interpretation of it, important aspects considered are the understandability and the readability of the model by a human user. ...
... In [9,10], both studies present algorithms which are based on a set of constraints targeting a readable layout of a process model (unified flow direction, minimal edge crossing, minimal bending points, usage of Manhattan layout). Automatic layout of BPMN models is presented in [14] and is focused on edge positioning. The study in [29] presents a comprehensive framework which allows for a personalized process model visualization, meaning that the model's visual appearance can be tailored to the specific needs of different user groups. ...
Full-text available
Business process models abstract complex business processes by representing them as graphical models. Their layout, solely determined by the modeler, affects their understandability. To support the construction of understandable models it would be beneficial to systematically study this effect. However, this requires a basic set of measurable key visual features, depicting the layout properties that are meaningful to the human user. The aim of this research is thus twofold. First, to empirically identify key visual features of business process models which are perceived as meaningful to the user. Second, to show how such features can be quantified into computational metrics, which are applicable to business process models. We focus on one particular feature, consistency of flow direction, and show the challenges that arise when transforming it into a precise metric. We propose three different metrics addressing these challenges, each following a different view of flow consistency. We then report the results of an empirical evaluation, which indicates which metric is more effective in predicting the human perception of this feature. Moreover, two other automatic evaluations describing the performance and the computational capabilities of our metrics are reported as well.
... For example, Silver and Richard [54] and Swiss eGovernment standards [5] require left-to-right layout in their guidelines. Layout algorithms have also been implemented that way: Both Effinger and Decker [14,15], Kitzmann et al. [25], and Scholz and Lübke [50] layout horizontally. ...
Full-text available
Business process modeling is an important activity for developing software systems—especially within digitization projects and when realizing digital business models. Specifying requirements and building executable workflows is often done by using BPMN 2.0 process models. Although there are several style guides available for BPMN, e.g., by Silver and Richard (BPMN method and style, vol 2, Cody-Cassidy Press, Aptos, 2009), there has not been much empirical research done into the consequences of the diagram layout. In particular, layouts that require scrolling have not been investigated yet. The aim of this research is to establish layout guidelines for business process modeling that help business process modelers to create more understandable business process diagrams. For establishing benefits and penalties of different layouts, a controlled eye tracking experiment was conducted, in which data of 21 professional software developers was used. Our results show that horizontal layouts are less demanding and that as many diagram elements as possible should be put on the initially visible screen area because such diagram elements are viewed more often and longer. Additionally, diagram elements related to the reader’s task are read more often than those not relevant to the task. BPMN modelers should favor a horizontal layout and use a more complex snake or multi-line layout whenever the diagrams are too large to fit on one page in order to support BPMN model comprehension.
... Since the process modeled did not have branches, the position of elements was assigned in a sequential order from left to right. For more complex business process models, specific algorithms determine the position of elements [26], [27]. ...
Full-text available
The transformation towards the Industry 4.0 paradigm requires companies to manage large amounts of data. This poses serious challenges with regard to how effectively to handle data and extract value from it. The state-of-the-art research of Enterprise Architecture (EA) provides limited knowledge on addressing this challenge. In this article, the Automated Modeling with Abstraction for Enterprise Architecture (AMA4EA) method is proposed and demonstrated. An abstraction hierarchy is introduced by AMA4EA to support companies to automatically abstract data from enterprise systems to concepts, then to automatically create an EA model. AMA4EA was demonstrated at an Industry 4.0 laboratory. The demonstration showed that AMA4EA could abstract detailed data from the Enterprise Resource Planning (ERP) system and Manufacturing Execution System (MES) to be relevant for a business process model that provided a useful and simplified visualization of production process data. The model communicated the detailed business data in an easily understandable way to stakeholders. AMA4EA is an innovative and novel method that contributes new knowledge to EA research. The demonstration provides sufficient evidence that AMA4EA is useful and applicable in the Industry 4.0 environment.
... In [ 4,5] both studies present algorithms which are based on a set of constraints targeting a readable layout of a process model (unified flow direction, minimal edge crossing, minimal bendpoints, usage of Manhattan layout). Automatic layout of BPMN is presented in [ 8] and is focused on edge positioning. The study in [ 23] presents a comprehensive framework which allows for a personalized process model visualizations, meaning that the model's visual appearance can be tailored to the specific needs of different user groups. ...
Conference Paper
Full-text available
Business process models abstract complex business processes by representing them as graphical models. Their layout, solely determined by the modeler, affects their understandability. It would be beneficial to systematically study this effect and support the construction of understandable models. However, this requires a basic set of measureable key visual features, depicting the layout properties that are meaningful to the human user. The aim of this research is thus twofold. First, to empirically identify key visual features of business process models which are perceived as meaningful to the user. Second, to quantify the features into metrics, which are applicable to business process models. The paper reports an exploratory study which resulted in a set of key visual layout features. The metrics derived from these features are presented and demonstrated by applying them to example models.
... ○ Well-structured models are easier to layout [28,69,121]. Well-structured behavioral models are captured by planar graphs and can hence be drawn on the plane in such a way that no edges cross each other, which is one of the most important aesthetics when drawing behavioral models. ...
Full-text available
One can fairly adopt the ideas of Donald E. Knuth to conclude that process modeling is both a science and an art. Process modeling does have an aesthetic sense. Similar to composing an opera or writing a novel, process modeling is carried out by humans who undergo creative practices when engineering a process model. Therefore, the very same process can be modeled in a myriad number of ways. Once modeled, processes can be analyzed by employing scientific methods. Usually, process models are formalized as directed graphs, with nodes representing tasks and decisions, and directed arcs describing temporal constraints between the nodes. Common process definition languages, such as Business Process Model and Notation (BPMN) and Event-driven Process Chain (EPC) allow process analysts to define models with arbitrary complex topologies. The absence of structural constraints supports creativity and productivity, as there is no need to force ideas into a limited amount of available structural patterns. Nevertheless, it is often preferable that models follow certain structural rules. A well-known structural property of process models is (well-)structuredness. A process model is (well-)structured if and only if every node with multiple outgoing arcs (a split) has a corresponding node with multiple incoming arcs (a join), and vice versa, such that the set of nodes between the split and the join induces a single-entry-single-exit (SESE) region; otherwise the process model is unstructured. The motivations for well-structured process models are manifold: (i) Well-structured process models are easier to layout for visual representation as their formalizations are planar graphs. (ii) Well-structured process models are easier to comprehend by humans. (iii) Well-structured process models tend to have fewer errors than unstructured ones and it is less probable to introduce new errors when modifying a well-structured process model. (iv) Well-structured process models are better suited for analysis with many existing formal techniques applicable only for well-structured process models. (v) Well-structured process models are better suited for efficient execution and optimization, e.g., when discovering independent regions of a process model that can be executed concurrently. Consequently, there are process modeling languages that encourage well-structured modeling, e.g., Business Process Execution Language (BPEL) and ADEPT. However, the well-structured process modeling implies some limitations: (i) There exist processes that cannot be formalized as well-structured process models. (ii) There exist processes that when formalized as well-structured process models require a considerable duplication of modeling constructs. Rather than expecting well-structured modeling from start, we advocate for the absence of structural constraints when modeling. Afterwards, automated methods can suggest, upon request and whenever possible, alternative formalizations that are "better" structured, preferably well-structured. In this thesis, we study the problem of automatically transforming process models into equivalent well-structured models. The developed transformations are performed under a strong notion of behavioral equivalence which preserves concurrency. The findings are implemented in a tool, which is publicly available.
This book includes a selection of articles from The 2019 World Conference on Information Systems and Technologies (WorldCIST’19), held from April 16 to 19, at La Toja, Spain. WorldCIST is a global forum for researchers and practitioners to present and discuss recent results and innovations, current trends, professional experiences and challenges in modern information systems and technologies research, together with their technological development and applications. The book covers a number of topics, including A) Information and Knowledge Management; B) Organizational Models and Information Systems; C) Software and Systems Modeling; D) Software Systems, Architectures, Applications and Tools; E) Multimedia Systems and Applications; F) Computer Networks, Mobility and Pervasive Systems; G) Intelligent and Decision Support Systems; H) Big Data Analytics and Applications; I) Human–Computer Interaction; J) Ethics, Computers & Security; K) Health Informatics; L) Information Technologies in Education; M) Information Technologies in Radiocommunications; and N) Technologies for Biomedical Applications.
Conference Paper
Full-text available
The goal of many software projects is the support of business processes. A typical business process spans multiple Use Cases. This poses the difficulty of making the set of encompassing Use Cases consistent with each other and functionality-wise complete with regards to the overall business process. Manual arrangements and reviews of Use Cases are burdensome and time-intensive. Therefore, an automatic approach is needed that restores an overview of the Use Cases and visualizes the control-flow of the resulting business process. Our approach uses pre-conditions, post-conditions, and triggers of Use Cases to automatically assemble business processes in BPMN notation in order to solve this problem.
Conference Paper
Full-text available
Standardisation of languages in the field of business process management has long been an elusive goal. Recently though, consensus has built around one process implementation language, namely BPEL, and two fundamentally similar process modelling notations, namely UML Activity Diagram (UML AD) and BPMN. This paper presents a technique for generating BPEL code from process models expressed in a core subset of BPMN and UML AD. This model-to-code translation is a necessary ingredient to the emergence of model-driven business process development environments based on these standards. The proposed translation has been implemented as an open source tool.
Full-text available
We describe a package of practical tools and libraries for manipulating graphs and their drawings. Our design, which is aimed at facilitating the combination of the package components with other tools, includes stream and event interfaces for graph operations, high-quality static and dynamic layout algorithms, and the ability to handle sizeable graphs. We conclude with a description of the applications of this package to a variety of software engineering tools. Copyright © 2000 John Wiley & Sons, Ltd.
Any serious attempt at automatic programming of large-scale digital computing machines must provide for some sort of analysis of program structure. Questions concerning order of operations, location and disposition of transfers, identification of subroutines, internal consistency, redundancy and equivalence, all involve a knowledge of the structure of the program under study, and must be handled effectively by any automatic programming system.
Process mining has emerged as a way to analyze processes based on the event logs of the systems that support them. Today's information systems (e.g., ERP systems) log all kinds of events. Moreover, also embedded systems (e.g., medical equipment, copiers, and other high-tech systems) start producing detailed event logs. The omnipresence of event logs is an important enabler for process mining. The primary goal of process mining is to extract knowledge from these logs and use it for a detailed analysis of reality. Lion's share of the efforts in this domain has been devoted to control-flow discovery. Many algorithms have been proposed to construct a process model based on an analysis of the event sequences observed in the log. As a result, other aspects have been neglected, e.g., the organizational setting and interactions among coworkers. Therefore, we focus on organizational mining. We will present techniques to discover organizational models and social networks and show how these models can assist in improving the underlying processes. To do this, we present new process mining techniques but also use existing techniques in an innovative manner. The approach has been implemented in the context of the ProM framework and has been applied in various case studies. In this paper, we demonstrate the applicability of our techniques by analyzing the logs of a municipality in the Netherlands.
SUMMARY We present a modification of the spring-embedder model of Eades ( Congresses Numerantium, 42, 149-160, (1984)) for drawing undirected graphs with straight edges. Our heuristic strives for uniform edge lengths, and we develop it in analogy to forces in natural systems, for a simple, elegant, conceptually- intuitive, and efficient algorithm. Normally, graphs are depicted with their vertices as points in a plane and their edges as line or curve segments connecting those points. There are different styles of representation, suited to different types of graphs or different purposes of presentation. We concentrate on the most general class of graphs: undirected graphs, drawn with straight edges. In this paper, we introduce an algor- ithm that attempts to produce aesthetically-pleasing, two-dimensional pictures of graphs by doing simplified simulations of physical systems. We are concerned with drawing undirected graphs according to some generally accepted aesthetic criteria: 2
An orthogonal drawing of a graph is an embedding in the plane such that all edges are drawn as sequences of horizontal and vertical segments. We present a linear time and space algorithm to draw any connected graph orthogonally on a grid of size n×n with at most 2n+2 bends. Each edge is bent at most twice. In particular for non-planar and non-biconnected planar graphs, this is a big improvement. The algorithm is very simple, easy to implement, and it handles both planar and non-planar graphs at the same time.
Hierarchical graphs appear in several graph drawing applications, where nodes are assigned layers for semantic reasons. More importantly, general methods for drawing directed graphs usually begin by transforming the input digraph into a hierarchical graph, then applying a hierarchical graph drawing algorithm. This paper introduces the Degree Weighted Barycentre (DWB) algorithm for drawing hierarchical graphs. We show that drawings output by DWB satisfy several important aesthetic criteria: under certain connectivity conditions, they are planar, convex, and symmetric whenever such drawings are possible. The algorithm can be implemented as a simple Gauss — Seidel iteration.