SaaStr Workshop Wednesday w/ Lucas Price, Yardstick
Conversion and visualization of business processes in dsm format s. nicastro
1. Università degli Studi di Trieste
Dipartimento di Architettura e Ingegneria
Corso di Studi in Ingegneria Informatica
Conversion and visualization of business
processes in DSM format
Tesi di Laurea Magistrale
Laureanda:
Sara Nicastro
Relatore:
prof. Francesco Fabris
Correlatore:
prof. Carlos Kavka
ANNO ACCADEMICO 2018-2019
6. List of Figures
1.1 Finite undirected graph (left) and its adjacency matrix (rigth) 2
1.2 Finite directed graph (left) and its adjacency matrix (right) . 3
1.3 Three ways to point at the nodes of a graph: with letters
(left), numbers (center), or arbitrary symbols (right). The
first and the second imply an ordering, the third doesn’t. . . 4
1.4 A binary DSM to explain Input in Rows and Input in Columns
(IR/IC) conventions . . . . . . . . . . . . . . . . . . . . . . . 6
1.5 Example of a binary DSM (organization architecture), taken
from [5], adapted . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.6 Example of a numeric DSM (product architecture), taken
from [5], adapted . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.7 An electronic device and its product architecture DSM (taken
from [5], adapted) . . . . . . . . . . . . . . . . . . . . . . . . 8
1.8 Organization architecture DSM (taken from [5], adapted) . . 9
1.9 Process architecture DSM (taken from [5], adapted) . . . . . 10
1.10 Activities relationships (taken from [5], adapted) . . . . . . . 10
1.11 A Domain Mapping Matrix (DMM) . . . . . . . . . . . . . . 11
1.12 A Multiple Domains Matrix (MDM) . . . . . . . . . . . . . . 11
1.13 A DSM with external inputs and outputs . . . . . . . . . . . 12
1.14 An example of BPMN diagram including an intermediate
event (orange double circle) . . . . . . . . . . . . . . . . . . . 18
1.15 Labels in BPMN diagrams are not mandatory but strongly
recommended. . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.1 The A.1.0 BPMN diagram from [26] . . . . . . . . . . . . . . 24
2.2 The DSM conversion of the BPMN process A.1.0 (spread-
sheet) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.3 The A.2.0 BPMN diagram from [26] . . . . . . . . . . . . . . 25
2.4 The DSM conversion of the BPMN process A.2.0 (spread-
sheet) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.5 The A.2.1 BPMN diagram from [26] . . . . . . . . . . . . . . 26
2.6 The DSM conversion of the BPMN process A.2.1 (spread-
sheet) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.7 The A.3.0 BPMN diagram from [26] . . . . . . . . . . . . . . 28
v
7. 2.8 The DSM conversion of the BPMN process A.3.0 (spread-
sheet) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.9 A BPMN diagram with an iteration loop adapted from [27] . 30
2.10 The DSM conversion of BPMN diagram in Figure 2.9 (spread-
sheet) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.11 The C.1.0 BPMN diagram from [26] . . . . . . . . . . . . . . 32
2.12 The DSM conversion of the BPMN process C.1.0 (spread-
sheet) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.13 A BPMN diagram with data objects adapted from [27] . . . 35
2.14 The DSM conversion of BPMN diagram in Figure 2.13 (spread-
sheet) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.15 BPMN 2.0 events, part one . . . . . . . . . . . . . . . . . . . 38
2.16 BPMN 2.0 events, part two . . . . . . . . . . . . . . . . . . . 38
3.1 The single-page web application user interface . . . . . . . . 41
3.2 A simple BPMN diagram . . . . . . . . . . . . . . . . . . . . 42
3.3 Depth-first search indexing (image author: [34]) . . . . . . . 45
3.4 Breadth-first search indexing (image author: [35]) . . . . . . 45
3.5 The single-page web application architecture . . . . . . . . . 47
3.6 A DSM fragment produced by Angular’s Structural Directive
*ngFor applied to the DSM resembling JSON object . . . . . 54
4.1 DSM conversion of BPMN process A.1.0 in Figure 2.1, com-
parison between spreadsheet and web application versions . . 57
4.2 DSM conversion of BPMN process A.2.0 in Figure 2.3, com-
parison between spreadsheet and web application versions . . 58
4.3 DSM conversion of BPMN process A.2.1 in Figure 2.5, com-
parison between spreadsheet and web application versions . . 59
4.4 DSM conversion of BPMN process A.3.0 in Figure 2.7, com-
parison between spreadsheet and web application versions . . 60
4.5 DSM conversion of BPMN diagram in Figure 2.9 (Iteration
Process), comparison between spreadsheet and web applica-
tion versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.6 DSM conversion of Figure 2.11 BPMN diagram (C.1.0 from
[26]), breadth-first search, web application . . . . . . . . . . 62
4.7 Detail of Figure 4.6 . . . . . . . . . . . . . . . . . . . . . . . 63
4.8 DSM conversion of BPMN process in Figure 2.13, comparison
between spreadsheet and web application versions . . . . . . . 64
4.9 A BPMN diagram adapted from [27] and its DSM conversion 65
4.10 The C.1.1 BPMN diagram from [26] and its DSM conversion 66
4.11 The C.3.0 BPMN diagram from [26] . . . . . . . . . . . . . . 67
4.12 The DSM conversion of BPMN process C.3.0 . . . . . . . . . 68
4.13 A BPMN diagram from Cardanit [28] templates (Pizza De-
livery Process) . . . . . . . . . . . . . . . . . . . . . . . . . . 69
vi
8. 4.14 The DSM conversion of the BPMN diagram in Figure 4.13
(Pizza Delivery Process) . . . . . . . . . . . . . . . . . . . . 70
4.15 A BPMN diagram from Cardanit [28] templates (Library Pro-
cess) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.16 The DSM conversion of the BPMN diagram in Figure 4.15
(Library Process) . . . . . . . . . . . . . . . . . . . . . . . . 72
4.17 A BPMN diagram created with [28] and its DSM conversion . 73
4.18 A BPMN diagram created with Cardanit [28] . . . . . . . . . 74
4.19 The DSM conversion of the BPMN diagram in Figure 4.18 . 75
vii
9. List of Tables
2.1 BPMN 2.0 Descriptive conformance subclass elements and
attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.2 BPMN 2.0 Analytic conformance subclass elements and at-
tributes, part one . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.3 BPMN 2.0 Analytic conformance subclass elements and at-
tributes, part two . . . . . . . . . . . . . . . . . . . . . . . . . 40
viii
10.
11. Abstract
In the ’90s researchers from Massachussets Institute of Technology (MIT)
grew interest in Design Structure Matrices (DSM) as a medium to model
complex systems and the interaction between their elements. A DSM is a
square NxN matrix where columns are the replica of rows, each one rep-
resenting one of the N elements of the system. The intersection between
a row and a column, that is a single square inside the matrix, displays in-
formation about the interaction, if present, about the row’s element and
the column’s element. On-diagonal squares represent self-interaction of an
element with itself and are therefore blackened since this information is usu-
ally not of interest. Off-diagonal squares’ content key to understanding is
neither univocal nor predefined, and depends as well on the described ar-
chitecture: in literature and industrial applications it can be found DSMs
reproducing product, organizational and process architectures. Moreover,
DSM models have to be read differently depending on the temporal nature
of the depicted system (static or dynamic) and on the symbols it contains
(numeric or non-numeric).
DSM great flexibility contributed to its spread outside academic circles
toward different industrial environments, first of all aerospace and automo-
tive ones. DSM strength with respect to other techniques used in the field of
engineering management (Gantt charts, PERT, CPM) is the focus on infor-
mation flow instead of the system temporal aspect or its workflow. Another
success feature of DSM is the easy applicability of optimization algorithms
(clustering and sequencing).
Domain Mapping Matrices (DMM) are rectangular matrices used to link
DSM of different domains (product, organization, process). DMM compo-
sition is analogous to DSM one, with the exception that rows and columns
elements are different. A Multiple Domain Matrix (MDM) is composed by
both DSMs and DMMs.
This thesis takes inspiration from and develops independently the idea
illustrated in Leveraging DSM to analyze BPMN 2.0 Models (D. Campagna
et Al.) [1], presented at the 21st International DSM Conference and al-
ready hinted at, although in a less directed way, in a previous work [2]. The
work here presented is an attempt to exploit DSM’s own features (graphi-
cal compactness above all) to offer an alternative visualization of a BPMN
i
12. 2.0 diagram (Business Process Modeling and Notation), which is a business
processes modeling technique, comprising a graphical notation, born in 2004
and actually maintained by the Object Management Group (OMG) consor-
tium. BPMN stands out from traditional flowcharts for being based upon a
formal specification which specifies its metamodel, rules of use and seman-
tics. Taking the examples offered by OMG’s wiki [26] as a starting point, a
partially semantically modified process DSM will be constructed; this DSM,
wrapped in an MDM when needed, will be the alternative representation of
the starting BPMN diagram. The purpose is to cover the range of symbols
included in BPMN’s Descriptive and Analytics compliance subclasses.
The work presented in this thesis develops in two phases. As a first step,
a DSM conversion of various BPMN diagrams is incrementally built. The
objective is to join BPMN’s expressivity with DSM’s structure, which has its
own semantics. The second step consists in the automation of the proposed
translation by means of a RESTful design pattern based web application.
The ordering algorithm of BPMN’s nodes will be studied with particular
attention.
The final chapter concerns the results obtained in previous Chapters and
suggests the involvement of BPMN and DSM in a much broader context,
where to a single system multiple views can be associated, each one uniquely
enlightening one of its particular aspects.
It is the intention to submit this thesis results for consideration for pub-
lication in a conference in the DSM sector.
ii
13. Sommario
Le Design Structure Matrix (DSM) divennero oggetto di studio presso il
Massachussets Institute of Technology (MIT) durante gli anni ’90 come
modello della struttura di un sistema complesso e delle interazioni tra i suoi
elementi. Una DSM si presenta come una matrice NxN in cui ogni riga rapp-
resenta uno degli N elementi del sistema e in cui ad ogni riga corrisponde una
colonna. L’intersezione riga-colonna, ovvero un singolo quadrato all’interno
della matrice, riporta l’informazione riguardante l’interazione, se presente,
tra l’elemento della riga e quello della colonna. I blocchi sulla diagonale
della matrice rappresentano quindi l’interazione di un elemento con se stesso
e sono di colore nero, essendo questa informazione tipicamente priva di in-
teresse. La chiave di lettura dei blocchi fuori diagonale non è né univoca né
predefinita e dipende anche dal dominio dell’architettura descritta: i tre tipi
di DSM presenti in letteratura rappresentano l’architettura di prodotto, di
organizzazione e di processo. Diversa semantica è inoltre da attribuire alle
DSM a seconda che siano statiche o temporali, numeriche o non numeriche.
La grande versatilità delle DSM ha contribuito al loro diffondersi in
breve tempo al di fuori dell’ambito accademico e in diversi tipi di industria
(aerospaziale ed automobilistica in particolare). Rispetto ad altre soluzioni
adottate nel contesto dell’ingegneria gestionale (diagrammi di Gantt, PERT,
CPM) l’accento in una DSM è posto sul flusso di informazione tra i vari
elementi del sistema piuttosto che sugli aspetti temporali di quest’ultimo o
sul suo diagramma di flusso. Fortunata per le DSM fu inoltre la possibilità
di applicare facilmente algoritmi di ottimizzazione (sequencing e clustering).
Una Domain Mapping Matrix (DMM) è una matrice rettangolare uti-
lizzata per rappresentare legami tra elementi di DSM di diverso dominio
(prodotto, organizzazione, processo). La costruzione è analoga a quella di
una Design Structure Matrix, fatta eccezione che gli elementi delle righe e
delle colonne sono diversi. Una Multiple Domain Matrix (MDM) si ottiene
dalla rappresentazione congiunta di DSM e DMM.
In questa tesi si riprende e si sviluppa in modo indipendente l’idea illus-
trata in Leveraging DSM to analyze BPMN 2.0 models (D. Campagna et Al.)
[1], presentata in occasione della 21st International DSM Conference e già
anticipata, seppur in modo meno finalizzato, da un’altra fonte in anni prece-
denti [2]. Nel lavoro qui presentato si cercherà di sfruttare le caratteristiche
iii
14. proprie di una DSM (compattezza di rappresentazione in particolare) per
offrire una visualizzazione alternativa di un diagramma BPMN 2.0 (Busi-
ness Process Modeling and Notation), che è una tecnica di modellizzazione
di processi aziendali nata nel 2004, corredata di una notazione grafica, ed
attualmente mantenuta dal consorzio Object Management Group (OMG). Il
BPMN si distingue dai diagrammi di flusso tradizionali per il fatto di appog-
giarsi su una specifica formale che ne regola il metamodello, le regole d’uso
e la semantica. Partendo dagli esempi di BPMN forniti dall’OMG nella pro-
pria wiki [26] si costruirà una DSM di processo parzialmente modificata nella
semantica che, inglobata in una MDM dove necessario, costituirà la rappre-
sentazione alternativa del diagramma BPMN di partenza. L’obiettivo è di
coprire i simboli BPMN 2.0 inclusi nelle sottoclassi di conformità Descrittiva
ed Analitica.
Il lavoro presentato in questa tesi si divide in due fasi. Nella prima si
costruirà in modo incrementale la conversione BPMN-DSM. L’obiettivo è
di coniugare l’espressività di un BPMN con la struttura di una DSM, che
racchiude anch’essa una propria semantica.
Nella seconda fase si affronterà l’automatizzazione della soluzione pro-
posta tramite la realizzazione di una applicazione web basata sul RESTful
design pattern. Particolare attenzione verrà dedicata all’algoritmo di ordi-
namento dei nodi di un diagramma BPMN.
Si discuterà infine dei risultati ottenuti e di come BPMN e DSM si col-
lochino in un contesto più ampio, in cui ad un unico sistema possono essere
associate più rappresentazioni distinte, ognuna in grado di evidenziarne in
modo unico un aspetto particolare.
È intenzione portare i risultati di questa tesi all’attenzione delle con-
ferenze del settore DSM per un’eventuale pubblicazione.
iv
15. Chapter 1
Design Structure Matrix,
Domain Mapping Matrix and
Multiple Domains Matrix
1.1 Foundations
The works [3] and [4] draw MIT researchers’ attention toward Design Struc-
ture Matrices and their potential. Among them, T. Browning and S. Ep-
pinger laid the foundations for DSM to become a modeling tool used both
by academics and by industrialists. Their book Design Structure Matrix -
Methods and Applications [5] is a collection of the works done by them or by
other MIT students. The great number of examples illustrated in the book,
going from jet engines to bioscience facilities and space stations, should con-
vince the most skeptical reader that Design Structure Matrices are indeed
a versatile tool, as a simple flowchart could be.
Eppinger and Browning are still nowadays active promoters of DSM. One
of Browning’s area of expertise and research are DSM as architecture mod-
eling and analysis tool in and across domains [6], while one of Eppinger’s
projects focuses on the use of multi-dimensional DSM analysis applied to
system integration [7]. Both of them are members of the Organizing Com-
mittee of the International DSM Conference [8], established in 1999, whose
mission is
to enhance understanding and managing complex interdepen-
dent relationships within and across product/process/people ar-
chitectures.
A complete DSM historical background and explanation is beyond the
scope of this presentation, as well as an exhaustive list of the companies
(e.g., Ford, Intel, Boeing, Mozilla, Kodak, NASA...) that adopted DSM
1
16. to gain more insight into their processes and their organization. We will
instead provide a survival guide to DSM comprehension.
1.1.1 Graph theory origins
In 1981 Donald Steward, a professor from California State University (Sacra-
mento), published a book [3] and a paper [4] in which DSM models were first
used to represent complex systems and their networks. While the meaning
attributed to DSMs was revolutionary, their basic concepts were known from
the past and based on the solid mathematical foundations of graph theory.
A Design Structure Matrix can be seen as an evolution of an adjacency
matrix, which is an alternative to a finite graph representation.
Finite graphs and adjacency matrices basics
We give in Figure 1.1 an example of a finite undirected graph (left) and its
adjacency matrix (right).
Figure 1.1: Finite undirected graph (left) and its adjacency matrix (rigth)
The graph in Figure 1.1 (left) has a limited number of nodes and its
links are not directed; it’s then classified as an undirected simple graph. The
adjacency matrix is built by assigning to every node a row and a column
with the same index. The squares obtained by the intersection between
rows and columns contain information about the link between rows’ nodes
and columns’ nodes. A blank square, which can be seen as filled with a
zero, represents an absent link. The number one indicates the presence of a
link, while the on-diagonal dash has no meaning. Because of the undirected
nature of the graph, the adjacency matrix is symmetrical: element A is
connected to element B, and vice versa element B is connected to element
A, and so on and so forth.
2
17. A simple evolution can be undertaken by giving graph’s links a direction,
symbolized as an arrowhead (Figure 1.2, left).
Figure 1.2: Finite directed graph (left) and its adjacency matrix (right)
The graph’s adjacency matrix asymmetry (Figure 1.2 right) is due to
links orientation.
Notice that both in Figure 1.1 and in Figure 1.2 neither the nodes or-
dering nor the reading direction (row to column or column to row) matter.
1.1.2 From graphs to Design Structure Matrices
Substituting nodes with complex system elements
It has been said that a DSM is a modified version of an adjacency matrix.
To fully understand the implication of the term modified, we need to take a
step back and ponder on Steward’s idea.
A graph is a mathematical abstraction. Nodes and links don’t have a
direct counterpart in reality, as it happens with a large number of math-
ematical models. It is up to the model’s user to assign a meaning to the
abstraction and to verify that the connection made brings to sensible results.
In his article [4], Steward filled rows and columns of the adjacency ma-
trix with "the variables which define the design of the product", meaning
the activities involved in the product development, for example: "passenger
capacity specification", "speed and acceleration performance versus power",
or "cost" in the case of an electric car’s design. The origin of these tasks is
of particular importance. DSM models were first proposed as an alternative
to the traditional PERT (Program Evaluation and Review Technique) and
CPM (Critical Path Method) techniques, which are complementary. About
PERT and CPM it is sufficient for us to know that notions as activities,
events and time and a relationship relation of the kind "event A is a prede-
cessor (successor) of event B" (implying a temporal ordering) are included.
3
18. Let’s now go back to the graph represented in Figure 1.2. Since we
choose A, B, C, D, E to point to nodes, we are inclined to look at the
graphs element following A, B, C, D, E as it would be if instead of letters
we had used 1, 2, 3, 4, 5. But what about the graph in Figure 1.3 (right)?
Figure 1.3: Three ways to point at the nodes of a graph: with letters (left),
numbers (center), or arbitrary symbols (right). The first and the second
imply an ordering, the third doesn’t.
We want to highlight that a graph is a model that contains neither time
nor order. There is no starting point. There is no start at all, as well there is
not an end or a duration. In the same way, the segment which represents a
link has no nature. We are used, because of flow charts, to associate arrows
with time flow, but in a graph the direction is not associated with time
passing by. Since an adjacency matrix is an alternative representation of a
graph, it does not contain anything more than a graph does.
Steward did not simply substitute graph nodes with the elements of a
complex system, he also implicitly defined:
• the complex system to be a process, which has a temporal nature, and
in particular a product development process;
• the graph nodes to be process activities, which have a natural time
ordering (e.g., activity A has to be done before activity B);
• the links to represent information flow, e.g.: if activity H is linked
to activity C, it means that H produces some kind of information
(a document; the estimation of a parameter; a market analysis; ...)
which C needs to know to be completed. The time precedence of C
with respect to H is not trivial, and more importantly, a DSM can
contain, but does not explicitly render, time ordering of its elements.
Steward then enriched a "simple" adjacency matrix by filling it with
elements coming from a semantically richer contest than a graph (PERT
charts), a semantic which is inherited by DSM format. This inheritance was
encouraged by the fact that DSMs were not thought of as an alternative to
4
19. PERT, but as a complementary tool to represent other information. The de-
parture point (process modeling) is the same, while the nuances highlighted
are different.
Notice at least that Steward proposed his idea in the area of product
development, but the association "complex system to product development
process" is not mandatory. Steward just made the first step: a system is an
abstraction as a graph is, and the exact nature of it or of its elements is still
not defined, meaning that any system and any kind of relationship can be
represented by DSMs. This is what makes DSM such a flexible tool.
DSM history reference : concurrent engineering boosting
Eppinger ([9], [10]) gives an overview of the background in which DSMs
found their roots. Starting from the ’90s, a practice called Concurrent En-
gineering established as a standard approach to product design and devel-
opment. Its motto reads the fastest to the market, the better and its recipe
recommends tasks parallelization. Process stages which were before accom-
plished sequentially became integrated to reduce time cost: at the same time
there is more than one activity carried on. Parallelization is possible if the
tasks involved are independent one from the other. The problem that rapidly
came to light was that often tasks interdependency was not recognized. As
Eppinger highlights [9], it is easier to identify activity outputs than inputs:
an employee has a clear mind about the results he or she has to achieve, but
is less able to identify the resources needed. A programmer, for example,
knows that the objective is to write functioning pieces of software. When
asked what he or she needs to get to this result, there are some information
which are trivial (a computer and an IDE, for example) and some others that
are not: the internet connection to get the build automation tool working, a
precise operative system, the libraries, frameworks, dependencies, reference
manuals and guides, and so on and so forth.
DSMs taken as an as is description of processes clarify information inputs
and outputs, and identify sources and destinations of these flows, even when
sources and destinations are not aware of their role. In this way, the risk
of rework (which implies cost increasing) decreases and a deeper insight of
the process infrastructure is gained. Concurrent engineering found then in
DSM a powerful ally.
1.1.3 DSM classification and types
After mentioning Input in Rows and Input in Columns conventions (IR/IC
conventions), DSM classification (static, temporal) and types (product, or-
ganization, process) are presented.
5
20. DSM basics: Input in Rows and Input in Columns (IR/IC) con-
ventions
We introduce here a basic notion about DSM with the aid of Figure 1.4.
Figure 1.4: A binary DSM to explain Input in Rows and Input in Columns
(IR/IC) conventions
The point in the matrix can be read as a row to column (IR) or a column
to row (IC) link:
• IR: input in rows, output in columns. In this case, reading by rows, the
point represents an input which is provided by Task C and is intended
to Task B. Reading by columns, Task C provides an output which is
an input to Task B.
• IC: input in columns, output in rows. In this case, reading by rows, the
point represents an input which is provided by Task B and is intended
to Task C. Reading by columns, Task C depends on an input provided
by Task B.
The IR/IC convention is the only feature common to all DSM formats.
Every other symbol and interpretation have to be contextualized depend-
ing on the architecture behind the matrix, as explained in the following
paragraphs.
Bynary and numerical DSM
A binary DSM allows only one symbol which indicates the presence or ab-
sence of an interaction. The symbol is arbitrary and is usually chosen be-
tween a circle or a cross. Figure 1.5 (taken from [5], adapted) displays an
example of a binary DSM (organization architecture). Its reading will be
explained in successive paragraphs.
A numerical DSM contains more symbols, even inside the same square.
Figure 1.6 (taken from [5], adapted) displays an example of a numeric DSM
(product architecture). Its reading will be explained in successive para-
graphs.
6
21. Figure 1.5: Example of a binary DSM (organization architecture), taken
from [5], adapted
Figure 1.6: Example of a numeric DSM (product architecture), taken from
[5], adapted
Static and temporal DSM
In a static DSM, the inner diagonal and the element’s ordering have no se-
mantic denotation. The only convention to be taken into account is IC or
IR (Input in Rows or Input in Columns as previously explained (Section
1.1.3). A temporal DSM, on the other hand, contains much more informa-
tion. Rows content follows activities time ordering (e.g., "salting the water"
row and column come before "stirring in the pasta" row and column). IR or
IC convention evolve in IR/FAD and IC/FBD, that is:
• IR/FAD - Input in Rows, Feedback Above Diagonal: inner points in
the matrix maintain their original meaning, but since the activities
are sorted following execution order, a point above the diagonal has
more weight. The point indicates that the row activity produces some
information needed by the task pointed at by the intersection with
the corresponding column. Because of the missing information, which
didn’t exist at the time it was needed, the former task has to estimate
it. If the latter task does not validate the estimation, a rework cycle
from the latter to the former task could be triggered. To grasp the
cost of an error, think about an airplane production. This kind of
product takes months to be completed and the product specification
7
22. has to follow constraints which are not under the constructor control.
A rework cycle from one of the last tasks to one of the beginning stages
cannot be considered. A similar situation is to be avoided in the case
of smaller and simpler products with much higher production volumes
in a shorter time (consumer electronics as an example). A point above
and detached from the diagonal is the symptom of an infrastructure
that needs optimization. In general, it is better for points to be below
the diagonal and to be its nearest neighbors.
• IC/FBD - Input in Columns, Feedback Below Diagonal: the mean-
ing associated to points below the diagonal is the one explained for
IR/FAD.
1.1.4 Product and organization architecture DSM
Product DSM
A product DSM is a binary or numeric static DSM. The matrix rows and
columns are filled with the product’s components. The squares represent
information about the interactions between components interfaces.
We take the DSM of Figure 1.6 (taken from [5], adapted) as an example.
It can be a possible representation of an electronic device composed by
four main elements (Radiator, Control Unit, Sensors, Engine). The squares
inside the matrix inform about four types of flows between the component’s
interfaces: spatial (S), energy (E), information (I) and materials (M). The
numbers inside the block quantify the interaction on a 5-point scale (from
-2 for detrimental to +2 for required). Figure 1.7 represents the DSM of
Figure 1.6 with the missing key (right), and a sketch of the hypothetical
electronic device described by the DSM (left).
Figure 1.7: An electronic device and its product architecture DSM (taken
from [5], adapted)
Taking the square that links the Control Unit to Sensors as an example,
under the IR convention, the block informs that:
• Control Unit provides detrimental spatial input to Sensors;
8
23. • Control Unit provides less required energy input to Sensors;
• Control Unit provides less detrimental information input to Sensors;
• Control Unit provides less required materials input to Sensors.
Organization architecture DSM
An organization architecture DSM is a binary or numeric static DSM. Rows
and columns are filled with the organization’s teams (or departments, or
individuals). Squares inform about team communications.
Figure 1.8 displays a numeric DSM example taken from [5] (adapted).
Figure 1.8: Organization architecture DSM (taken from [5], adapted)
Taking the last row as an example, the reader is informed that the E.C.M
team:
• has monthly interactions with the Engine Block Team;
• has daily interactions with the Cylinder Heads Team;
• has monthly interactions with the Flywheel Team;
• has weekly interactions with the Exhaust Team.
1.1.5 Process architecture DSM
A process DSM is a temporal numeric DSM. Rows and columns are filled
with the process activities. Squares display information flows between ac-
tivities.
Among the architectures, the process one is the most varied. It is not
possible in this brief dissertation to give an overall view of all DSM formats
adapted to its description. We will restrict ourselves to provide a fundamen-
tal glossary of common engineering design and development terms and the
most simple process architecture DSM (Figure 1.9), along with a graphical
representation of rows and columns relationships (Figure 1.10) (taken from
[5], adapted) which connects to what outlined in Section 1.1.1.
9
24. Glossary
• Sequential activities task B is sequential to task A if A’s output en-
ables B’s execution. Partially overlapping (B starts before A’s ending)
is possible by careful evaluation of the type of dependency;
• Parallel activities tasks A and B can be executed simultaneously if
there is no input-output interaction between the activities;
• Coupled activities tasks A needs input from task B to produce its
output, and vice versa task B needs input from task A to produce its
output. Convergence to a shared solution assures tasks conclusion;
• Conditional activities tasks B and C are conditional to an upstream
activity depending on a condition belonging to the upstream task.
Figure 1.9: Process architecture DSM (taken from [5], adapted)
Figure 1.10: Activities relationships (taken from [5], adapted)
We inform that Figure 1.10 will be the starting point of section 1.3.
The interpretation of Figure 1.9 reveals that:
• tasks B and C depend on a condition occurring in task A;
• tasks B provides inputs to tasks C and D, executed in parallel;
• tasks C and D are coupled together;
• tasks E is sequential to task D.
10
25. 1.1.6 Domain Mapping Matrix and Multiple Domains Ma-
trix
A Domain Mapping Matrix (DMM) is not a DSM, although it shares some
aspects of its structure. A DMM is used to link together two DSM of different
domains. The invoices of the first DSM fill the rows, while the invoices of
the second DSM fill the columns. This construction is easily extended to
more than two DSMs. Figure 1.11 depicts a DMM example. The points are
to be read following the IR or IC convention.
Figure 1.11: A Domain Mapping Matrix (DMM)
A Multiple Domains Matrix (MDM) contains both DSM and DMM (Fig-
ure 1.12).
Figure 1.12: A Multiple Domains Matrix (MDM)
DMM can even display resources not belonging to the described archi-
tecture (Figure 1.13), as external inputs or outputs.
1.2 Applications
Two examples of recent DSM applications in medical and industrial domains
are presented below.
11
26. Figure 1.13: A DSM with external inputs and outputs
Healthcare process modularization
Zhang [11] introduces DSM as a technique for healthcare process modular-
ization. Rows are filled with healthcare services, while squares represent
information flows between them. The authors apply sequencing and GA
(Generic Algorithms) algorithms to their DSM to enhance services modu-
larization. The authors conclude
The findings from this study suggest that the DSM-based modu-
larization and sequencing algorithm are able to provide effective
decision support in modular clinical pathway design.
Eco-Design initiatives in the pulp and paper industry
Buzuku [12] exploits Design Structure Matrix format to identify and eval-
uate the barriers related to the implementation of eco-design initiatives in
the pulp and paper industry. Rows and columns are filled with the barriers
affecting the implementation of eco-design initiatives in the supply chain
of manufacturing companies (e.g. "Lack of support from institutions for
commercialization of cleaner production technology"). Squares represent
multidisciplinary interactions or barriers interdependencies. A clustering al-
gorithm is applied in order to create groups of barriers strongly interrelated.
The authors conclude
The proposed method provides insights into the process struc-
ture, identifies problem areas in processes and enables process
re-designing. A systematic analysis of three case studies in this
paper has significant managerial implications.
1.2.1 Algorithms: sequencing and clustering
Eppinger’s work Innovation at the speed of Information [9] was published by
Harvard Business Review in 2001. After the explanation of feedback impli-
cations in product development processes, the author focuses on sequencing
and clustering algorithms.
12
27. Scope of sequencing is to minimize the number of points representing
possible rework cycles. This is done by a rearrangement in tasks ordering:
rows (and corresponding columns) are swapped to make the DSM as more
similar to a triangular matrix as possible. The practical meaning behind
this operation is to change activities chronological order.
Scope of clustering is to gather in the same unit coupled activities. The
willpower of the behind line of reasoning consists in move closer (physically)
or put closer (logically) tasks that often need to communicate with each
other. This algorithm also aims to avoid rework cycles.
It is possible to further optimize the process by means that are however
detached from DSM manipulation (e.g., increasing the number of tasks) and
are therefore not included here.
1.3 Limits
The following objections are tied to our outsider view of Design Structure
Matrices. It can be said that the power of a language, whichever medium it
uses, depends not only on its technical capabilities but even on its learning
curve and its portability beyond borders, that is the capacity of being a
meeting point for different schools of thought and education.
1.3.1 A too tight contextualization
DSM gift and curse are Concurrent Engineering practices. Their need of a
different project managing tool contributed to DSM diffusion, but the latter
took hold only among the ones who were involved in certain branches of
engineering management. It took many years to DSM to leave its birthplace
([11], [12]).
The bigger learning roadblock, in addition to DSM nature of hostile
mathematical resembling objects, is the value associated to inner points and
the technique used to explain their meaning to new users. As mentioned in
Section 1.1.5, Figure 1.10 can be taken as a thinking starting point. That
kind of diagram is nothing newer than an already seen flowchart, but in a
flowchart arrows have the meaning of time flow, while in Figure 1.10 they
don’t. There is no way to be aware of this feature from the drawing itself (as
well there is no way to know if a DSM follows the IR or the IC convention
from the DSM itself). It can be argued that there is a mismatch between the
drawing that should enhance the new user comprehension and the message
that must be sent.
A too tight contextualization?
A simple solution to the problem beforehand presented could consist in
leaving the DSM explanation to plain text, if it were not that in a process
13
28. architecture DSM there is the inclination to include pieces of information
of different kinds. In Figure 1.10, for example, the OR condition is not an
information flow but is in any case contained in the DSM. The fact that
DSM format does not have standard building rules allows the user to attach
into it any information he or she thinks has to be taken into account (we
leave the proof to [5] variegated examples). It seems then that DSM models
were at first useful because of their focus on information flow, but were then
asked to display process aspects which are already excellently described by
other tools.
Technical jargon
Another misleading source is Concurrent Engineering’s related language.
In the common sense, sequential has a different meaning with respect to
what written in Section 1.1.5 Glossary, in particular the information aspect
doesn’t have a stake. Conversely, it is possible that the explanation of what
are coupled activities means anything to people who don’t have a scientific
background and still need to deal and understand DSM’s exact semantic,
e.g. managers or supervisors.
1.3.2 Expressiveness flaw
Given a DSM, it is not possible to know at a first glance what system it
describes. This information can maybe be inferred by an experienced DSM
reader who already has knowledge about the system. It should be possible
for a less prepared reader to grasp the domain of the DSM by looking at rows
labels, arguing that the elements of a product architecture (product physical
components) are different from those of an organization architecture (teams,
individuals) or from those of a process architecture (activities). Although
theoretically convincing, this consideration doesn’t hold on. Often labels are
recycled from a DSM of a different domain that describes the same process,
or from another model displaying the same process (e.g., a PENT chart, or
IDEF (Integration DEFinition) model).
An example is worth a thousand words: the invoices of an organization
(team-based) architecture DSM taken from [5] are: Engine Block, Pistons,
Flywheel, etcetera. These labels are shared with the product DSM associated
to the same system, from which they were probably taken. It would be
different if the labels were, for example: Engine Block designers, Pistons
team, Flywheel technicians and engineers.
Worst labeling cases in [5] are found in organization architecture DSMs.
Luckily, rows label are generally more representative of their content: for
product architecture (component based) they are composed mainly by nouns
(Engine Block, Pistons, Flywheel), while for process (task based) architec-
ture the formulas are: noun (Requirements, Prognosis), verb-noun (Estimate
14
29. efforts, Run tests), noun-verb (Tool manufacturing, S/W development); all
examples taken from [5]. The lack of uniformity, however, leads to the
reader’s puzzlement.
Atomicity
Another concern is the granularity hidden under rows labels. It is possible
to read in the same DSM [5] tasks description as Select powertrain lineup
and Perform swing study. It is reasonable to suppose that select involves the
execution of just one action (precisely to select), while a study is an activity
composed of many other tasks. Both of these tasks, nevertheless, occupy in
a DSM the same amount of space (a row/column couple).
Information flow - by which mean?
DSM focuses on information flows. The purpose of DSM is to reduce cost,
not only that due to the rework cycle but even the one due to frequent
interactions among individuals. The nature of the interaction, anyway, is
not specified by a DSM in spite of its importance: sending an electronic mail
has a different cost with respect to sending a registered mail; the same can
be said about internal and external mails. And a meeting is a faster way to
share information than the elaboration of a written document.
The fussier the modeler, the better the DSM
As a general rule, DSM legibility is entrusted to the modeler’s fastidiousness,
precision, and accuracy. It would be better to leave such an onerous burden
to DSM format own rules.
1.3.3 Interpretation ambiguity
Apart from the misleading rows labels, there are other already mentioned
DSM grey areas:
• in a DSM there is no indication about the static or temporal system
disposition;
• in a DSM there is no clue about the reading convention (IR or IC);
• every DSM has its own key to understanding, but often the key is
missing (see [5] examples) and therefore the DSM’s meaning is fleeting.
A DSM is not self-explanatory and every modeler is free to use any
symbol he or she prefers. The same symbol can evoke another meaning to
the mind of the DSM reader.
15
30. 1.4 Formerly DSM’s extensions
Work Transformation Matrix
Smith and Eppinger [18] extend DSM to predict slow and rapid convergence
of iteration in a product development process managed with concurrent
engineering practices. The article includes the case study of an automotive
brake system design.
High Definition Design Structure Matrix (HDDSM)
Tilstra’s three detailed works [15] [16] [17] head towards product architec-
ture DSM standardization. These papers present a systematic method to
analyze product flexibility for future evolution based on selected guidelines.
Since built on common rules, the High Definition Design Structure Matrix
(HDDSM) permits quantitative analysis of similar but different products.
The author’s guidelines aim to make HDDSM repeatable.
Extended Design Structure Matrix (XDSM)
Lambe et Al. [14] use a modified DSM, called XDSM (Extended De-
sign Structure Matrix) to deal with Multidisciplinary Design Optimization
(MDO) problems. MDO’s intent is to solve design problems incorporating
a variety of different disciplines.
A boolean MDM
Kreimeyer et Al. [13] try to compensate for DSM and MDM shortage of
means to model decision points (AND, OR, XOR) by extending a Multiple
Domain Matrix with a new domain, that of booleans.
A three-dimensional Design Structure Matrix
Shoval’s contribution [19] to the 13th Global Conference on Sustainable Man-
ufacturing focuses on the systems lifecycle. A multilayered DSM is used to
build a 3D representation of the system’s elements and phases. The mod-
ified DSM is used to determine the cost effects of modules changes during
the system life process.
1.5 A new proposal
1.5.1 Leveraging DSM to analyze BPMN 2.0 models
The work [1] was presented at the 21st International DSM Conference [8].
With the aid of CAM (Cambridge Advanced Modeler, see [23]), DSM format
16
31. is exploited to display an alternative representation of a COMPOSELEC-
TOR (EU Horizon 2020 Project, [24]) workflow, previously modeled by a
BPMN diagram. Ignoring, for now, BPMN details (see Chapter 2 of this
thesis for further information), we are interested in DSM format usage: its
peculiarities are due to the source of the process model, that is the BPMN
diagram.
As formerly highlighted in 1.1.2, DSMs are an adjacency matrices evolu-
tion, because Steward enriched them with details belonging to a semantically
richer contest than graphs as pure mathematical objects. Campagna’s out-
come [1] is the result of an analogous operation. A BPMN diagram is not
a graph, but its visual impact resembles one. A recall can also be made to
Figure 1.10: the semantics of a BPMN, as it will be explained later, apart
from graphical likeness has anything to deal with Figure 1.10.
Once had the idea of using a DSM to display a BPMN (but this is the
tricky part!), DSM construction starting from BPMN is almost intuitive
and naturally lead by the likeness of the above-mentioned figures. It is any-
way appropriate to remember that the meaning associated with the links
in Figure 1.10 is information flow and not sequence flow (as it is in BPMN
diagrams). The authors of [1] assign a couple row/column to every task and
parallel gateway in a BPMN. The innovative feature of the proposed DSM is
the mixed nature of the matrix’s inner points: circles characterize informa-
tion flows, as in "original" DSMs, while squares identify sequence (temporal)
flows. DSM interpretation is then more intuitive, at least partially, because
links maintain their time nature (as in traditional flowcharts) instead of the
information flow one.
In 1.1.3 we have explained the difference between a static and a temporal
DSM. We remember that in a temporal DSM the time ordering is implicitly
defined in rows listing, and also that there is the tendency to include in
process architecture DSM elements that are not truly information flows (e.g.,
the OR condition of Figure 1.9).
Further development of [1] proposal can represent a step forward to solve
the most of, or all, the limits of Design Structure Matrices presented in 1.3,
at least for process architecture DSMs.
1.5.2 Previous literature results
Cruz et. Al contribution to the Eighth International Conference on Ax-
iomatic Design (ICAD 2014) [2] is the first attempt of a BPMN to DSM
conversion of which we are aware of. As [1], it contains an essential input to
this thesis argument. Starting from business interoperability (an enterprise
capability of cooperating with its business partners) set of problems, the
authors build a DSM which is quite similar to [1] one but exhibits one ad-
ditional feature. Cruz’s DSM distinguishes between the performers of each
one of the process activities by simply embellishing the DSM with an extra
17
32. background color and rows higher header.
This idea will be recalled and enhanced in our BPMN to DSM conversion,
exposed in Chapter 2.
1.5.3 A brief introduction to Business Process Modeling and
Notation (BPMN)
BPMN stands for Business Processing Modeling and Notation. It is a multi-
vendor standard maintained by the Object Management Group (OMG), an
international, open membership, not-for-profit technology standards con-
sortium founded in 1989. Its Task Forces develop enterprise integration
standards for different technologies (see [20] for further information).
BPMN is, in short, a diagramming language for business process flows
whose popularity is owed to its familiar aspect. Although its closeness to
traditional flowcharts, BPMN models differ from them in many ways. First
of all, BPMN is based on a formal specification which includes a metamodel
and rules of usage. BPMN thereafter is expressive enough to describe events
that can divert the default process in alternative branches. An example of
a BPMN diagram, including an event-triggered rerouting, is given in Figure
1.14.
Figure 1.14: An example of BPMN diagram including an intermediate event
(orange double circle)
A more detailed semantic overview will be given in the BPMN diagrams
contained in Chapter 2. We give here a brief explanation of Figure 1.14.
The event that triggers the process execution is represented by the green
circumference and is a BPMN Start Event. The label Start Event is optional,
as well the others: Task A, Task B, Task C, Default End Event, Alternative
End Event. A BPMN diagram doesn’t need labels to be valid (that is,
to meet the specification) but they are needed to fulfill BPMN’s existing
cause, which is process modeling. The same diagram without labels would
be pointless, as it can be seen in 1.15 (this powerful explanation on the
importance of labels is adapted from [27]).
18
33. Figure 1.15: Labels in BPMN diagrams are not mandatory but strongly
recommended.
Red circumferences represent the end of a path in a process. In this
case, there are two paths, both originating from Task A. The thunderbolt
inside the orange double circle attached to Task A rounded rectangle (which
represents a unit of work or activity) stands for an Intermediate Boundary
Interrupting Event. The latter’s meaning can be understood if well contex-
tualized within the other sequence flows. In contrast to DSM format, where
tasks parallelization is the desired goal, BPMN activities are to be executed
strictly sequentially, unless otherwise specified. Then, after the Start Event,
it follows Task A. After Task A ending, it starts Task B (no overlapping
allowed). After Task B ending, the process ends. This is the default process
path. During the execution of Task A an alternative path can be triggered
and followed instead of the default one. This event, whose happening is not
certain, is represented by the thunderbolt.
Chapter 2 of this thesis contains and explains other BPMN diagrams.
BPMN XML serialization
BPMN models are visualized as diagrams. The graphical notation is the
most appearing standard’s characteristic. At the technical level, BPMN
models are described by one or more XML (Extensible Markup Language)
files which are governed by five XSD (XML Schema Definition) schemas:
Schematic.xsd, BPMN20.xsd, DC.xsd, DI.xsd and BPMNDI.xsd, for which
we refer the reader to [21]. For our purpose, it is sufficient to know that a
BPMN diagram is serialized by an XML file that follows precise and uni-
versal rules. Every BPMN element has a set of attributes specified by the
standard specification (e.g. an identifier, a label, a source, and a target
reference identifier, etc.). BPMN editors like Cardanit [28] render the XML
files into diagrams as the one in Figure 1.14. About the latter we report as
an example a short extract, from its XML file, that serializes the process con-
tainer, the Start Event and Task A elements, together with the Intermediate
Boundary Interrupting Event:
19
34. [...]
<bpmn2:process id="_11" name="Process" isExecutable="true" isClosed="true">
<bpmn2:boundaryEvent id="errorBoundaryEvents_dfd9db6d-5532-96a3-7e0a-a202f4ce40e1"
cancelActivity="true" attachedToRef="tasks_b47fd0a1-04fe-6826-db12-611ce9033a46">
<bpmn2:outgoing>sequenceFlows_05526f32-52e2-78d6-83f7-5174939b53ac</bpmn2:outgoing>
<bpmn2:outputSet id="outputSet_5c85f736-e2cc-3c75-39e5-41aa5ab45b37"
name="default input set"/>
<bpmn2:errorEventDefinition
id="errorEventDefinition_ffb2b2a3-f0a5-d5ab-7e6f-fd482f605aa6"/>
</bpmn2:boundaryEvent>
[...]
<bpmn2:startEvent id="startEvents_a3cf2661-9e87-bf17-82fd-2c014916ee90"
name="Start Event">
<bpmn2:outgoing>sequenceFlows_dfbd352b-55be-6959-2126-e1ab7a948ba9</bpmn2:outgoing>
</bpmn2:startEvent>
<bpmn2:task id="tasks_b47fd0a1-04fe-6826-db12-611ce9033a46" name="Task A">
<bpmn2:incoming>sequenceFlows_dfbd352b-55be-6959-2126-e1ab7a948ba9</bpmn2:incoming>
<bpmn2:outgoing>sequenceFlows_88775c24-5b4c-7ae3-053d-339ba0e2ed48</bpmn2:outgoing>
</bpmn2:task>
[...]
The subject of this thesis is the conversion of BPMN diagrams to a
modified DSM format. BPMN serialization, for which we refer to [21], is
beyond our work reach and interest. In Chapter 3, Section 3.1.1, we will
give the essential details about BPMN serialization needed for the BPMN
to DSM conversion.
1.5.4 BPMN’s points of strength
BPMN advantages distribute on more than one level, the graphical notation
being the lower from an expert’s point of view. BPMN spearhead is its multi-
vendor standard nature, which assures (or should assure) its portability
between modelers and tool vendors. In practice BPMN diagrams XML files
have to be equally interpreted by all BPMN tools, for example they have to
produce the same diagram. At the same time, BPMN semantics is already
established, therefore whoever reads a BPMN model should understand the
same process description.
In addition, an interested business process modeler has at its disposi-
tion not only an open-source specification [21], but can even earn a widely-
recognized certification (OCEB) [22] or consult a guide written by the BPMN
world expert Bruce Silver [27], where beyond BPMN method, many style
rules for better process modeling are given. There is no counterpart regard-
ing Design Structure Matrices.
Another BPMN’s advantage lies in its legibility (a reader doesn’t need
to be a business process expert to understand most of a BPMN diagram)
and the great variety of nuances comprised in its expressive capabilities, as
it will be clearer in Chapter 2.
20
35. Another point of strength are style rules, not formalized by the specifi-
cation, but naturally consequent from BPMN guides (as [27]) reading. An
analogy could be camel case notation in objective programming: it is not
mandatory, but since it is widely used, it is easy to comply with (any manual
adopts it). Example of the style rules are activities labeling criterion; Silver
recommends to use (and is therefore adopted) a verb-noun structure.
Last but not least, BPMN reading (not writing) learning curve is less
steep than the one of DSM, also because its semantic is more familiar than
the one associated with Design Structure Matrices.
1.6 Blending DSM and MDM’s compactness with
BPMN symbolism and methods
The proposal, developed in Chapter 2, will merge hints from both [1] and
[2]. From [1] we will inherit the double meaning assigned to DSM’s inner
points, i.e. information or sequence flow. From [2] we will acquire the usage
of the colors to discriminate tasks’ different performers. The additions made
to these two proposals will make it possible to reach the covering of BPMN’s
Descriptive and Analytics subclasses (see Section 2.1).
To overcome DSM limitations (Section 1.3) with BPMN aid, we will start
from already existing BPMN to compose a modified Design Structure Matrix
format. The resulting modified DSM will then display the type of process
modeled by BPMN, which is business process models. The final outcome
would be more precisely classified as a Multiple Domain Matrix (MDM, see
1.1.6 ) composed by extended DSMs and Domain Mapping Matrices (DMM,
see 1.1.6). The result will furthermore join the advantages of both BPMN
and DSM formats: from the former, the great expressiveness, and from the
latter, the compactness.
21
36. Chapter 2
Step by step conversion of
BPMN diagrams to a
modified DSM-MDM format
2.1 Aiming to Descriptive and Analytics BPMN
compliance subclasses
Compliance classes
BPMN specification [21] is a complex and detailed document. Full com-
pliance to the standard is difficult to reach for a tool which is intended to
be multi-vendor and whose output should be easily interchanged between
different platforms. To overcome this limitation, the BPMN 2.0 specifica-
tion includes four conformance (partial compliance) classes. A tool ven-
dor’s product can claim Process Modeling Conformance, Process Execution
Conformance, BPEL Process Execution Conformance and/or Choreography
Modeling Conformance, depending on which features it supports.
Since our purpose is to use BPMN graphical notation, only the Process
Modeling Conformance class is of interest to us, because this is the class
which rules the graphical notation of BPMN. This set is in turn divided
into three subclasses: Descriptive Process Modeling Conformance subclass,
Analytic Process Modeling Conformance subclass and Common Executable
Process Modeling Conformance subclass. Only the first two specify the vis-
ible information of a BPMN diagram, namely the set of symbols and their
semantic. Executable BPMN is a broad subject we will not deal with hereby.
The target of our BPMN to DSM conversion attempt will be then the
Descriptive and Analytic subclasses symbols and semantic.
At the end of this Chapter, Tables 2.1, 2.2 and 2.3 display a list of
the elements and their attributes included in the Descriptive and Analytic
subclasses. BPMN diagrams in the present Chapter contain some of these
22
37. symbols. A brief explanation of their utilization will be given in Section 2.3
examples. Figures 2.15 and 2.16 contain the graphical notations of some of
the elements listed in Tables 2.1, 2.2 and 2.3.
2.2 BPMN sources and tools used
2.2.1 BPMN Model Interchange Working Group (MIWG)
MIWG was created by OMG in 2013 with the following announcement:
The purpose of BPMN MIWG is to ensure the smooth inter-
change of BPMN models between tools that implement the stan-
dard. The group is currently seeking participants to join and is
welcoming both OMG members and interested nonmember or-
ganizations. [25]
MIWG test-suite reference repository on Github [26] contains BPMN
examples (both XML files and graphical diagrams). We will use a few of
these examples to give a proof of concept of our BPMN to DSM translation.
2.2.2 Bruce Silver’s BPMN method and style
Bruce Silver is the world’s leading expert on BPMN. His second edition
of BPMN method and style [27] is a must-have for every aspiring BPMN
modeler. In Section 2.3 we will adapt and convert to DSM format a few of
his BPMN examples.
2.2.3 Cardanit templates
Cardanit [28] is ESTECO’s [29] BPMN online editing platform. We will use
two of its default BPMN templates to test the web application described
in Chapter 4 (see Figures 4.14 and 4.16). ESTECO is one of the MIWG
partecipants.
2.2.4 Tools
At this stage, it is not clear to us which algorithm better suits the BPMN to
DSM conversion. One of the aspects of particular concern is BPMN model
activities ordering automation. As it will be explained in Section 2.3.2, tasks
sorting admits more than one acceptable solution. To be free to compose the
modified DSM-MDM as needed, we are going to build the matrices by means
of a simple, multipurpose spreadsheet (LibreOffice Calc of the LibreOffice
software package). In Chapter 3 a web application will replace the handwork
done in this Chapter. The hand-made DSMs of the latter will be used in
Chapter 4 as a benchmark to validate the web application’s results.
23
38. 2.3 Assembling
2.3.1 The simplest BPMN
The BPMN diagram in Figure 2.1 is to be read as follows: Start Event
triggers the process execution by launching Task 1. After (no overlapping
allowed, as it is expected in DSM processes) Task 1 completion, it starts
Task 2. After Task 2 ending, Task 3 takes place. After Task 3 completion
the process ends in the End Event. All the diagram nodes have no specific
nature (we refer to 2.3.6 for an opposite example, i.e. the Start Event is a
Message Start Event, and so on, and so forth).
Figure 2.1: The A.1.0 BPMN diagram from [26]
Figure 2.2: The DSM conversion of the BPMN process A.1.0 (spreadsheet)
The DSM in Figure 2.2, which has a temporal nature, is composed as
follows. The first white rectangle in the upper-left corner displays the name
of the process. Inside the rectangle there is an arrow whose intent is to
resolve the ambiguity about the reading convention. In Section 1.1.3 we
described the IR and IC conventions, and later the IR/FAD and IC/FBD
conventions. In our DSM format we reserve the lower half of the matrix for
feedback reporting, following the IC/FBD convention. The arrow suggests
to read the matrix inner points as a row to column link, instead of a column
to row link: Start Event provides an input to Task 1, Task 1 gives an input
to Task 2, and so on and so forth. A couple row/column is allocated for every
node: in the BPMN diagram of Figure 2.1 there are only the Start and End
Event nodes and the activities nodes. Rows labels are inherited from the
BPMN diagram; in this case, rows are filled with placeholders. Inner circles
represent sequence flows as in [1]. The new feature with respect to [1] and
24
39. [2] is the integration of the Start Event and End Event symbols (green and
red circumferences respectively) both in rows and columns labels. The lower
half of the DSM is reserved to indicate process iteration loops, therefore is
in this case empty. Rows are sorted following the appearing ordering of the
BPMN in Figure 2.1.
2.3.2 Gateways
The BPMN process represented in Figure 2.3 introduces a new symbol, the
Exclusive Gateway, symbolized by a blank rhombus. It is used to indicate
that, depending on the satisfaction of a certain condition, one of the alter-
native paths (all drawn in the model) will be the process continuation. It
can be thought of as a XOR condition. Referring to Figure 2.3, the Gate-
way (Split flow) node enables one of the following activities: Task 2, Task
3 or Task 4. The Gateway (Merge Flows) node gathers Task 3 and Task 4
outgoings. The first ending task enables the process continuation towards
the end, symbolized by the End Event element.
Figure 2.3: The A.2.0 BPMN diagram from [26]
Figure 2.4: The DSM conversion of the BPMN process A.2.0 (spreadsheet)
Following [1] and the previous example hints, in the DSM conversion of
A.2.0 diagram we dispose a row/column couple for every activity and for the
25
40. exclusive gateways also. We add the gateway symbol, modified in an empty
golden rhombus for visibility, to interested rows and columns (numbers 3
and 7). The novelty is the rhombus mark inside the matrix. We use it
to distinguish the link between the gateway and the first nodes of exclusive
paths: Task 2, Task3 and Task 4. We use it to characterize the link between
the Gateway (merge flows) and End Event nodes also, to highlight that the
process is not strictly sequential.
Notice that in the present case the regularity of the DSM in Figure 2.2 is
broken: the process described is not as linear as the one in Figure 2.1, and
this irregularity is reflected by the disposition of points inside the matrix.
The points are no more first neighbors of the diagonal but spread instead
all over the upper half of the matrix.
After the first gateway (Gateway (Split Flow)), task ordering is no more
trivial. We decide to assign the last index (number 8) to the End Event.
Tasks index between the first gateway and the End Event is arbitrary: any
permutation of Task 2, Task 3 and Task 4 would be equally acceptable as
long as it doesn’t produce a point under the diagonal.
This case will be of interested for the choice of the automation ordering
algorithm, see Section 3.1.2.
2.3.3 A tricky case
The BPMN diagram in Figure 2.5 is a model whose ordering will be of
particular interest for the web application developed in Chapter 3 (Section
3.1.2).
Figure 2.5: The A.2.1 BPMN diagram from [26]
The interesting portion of the diagram is what follows the Gateway (Split
Flow) node. The model in Figure 2.5 is to be read as: the process starts
with the Start Event, after which Task 1 takes place. Depending on a
certain condition (not specified in the diagram), the Gateway (Split Flow)
which is, in this case, an Exclusive Gateway, enables only one of the following
26
41. activities: Task 2, Task 3 or Task 4. The default path follows Task 2. From
the first gateway on there are therefore three possibilities:
• after Task 2, the default action is to proceed with Task 3; otherwise,
depending on the satisfaction of a condition, to flow in the End Event;
• if Task 4 is chosen, the default action is to proceed with Task 3;
otherwise, depending on the satisfaction of a condition, to flow in the
Gateway (Merge Flows) and finish in the End Event;
• the last option is to execute Task 3, flow in Gateway (Merge Flows)
and then finish in the End Event.
Figure 2.6: The DSM conversion of the BPMN process A.2.1 (spreadsheet)
The Gateway (Merge Flows) node gathers Task 3 and Task 4 outgoings.
The first ending task enables the process continuation towards the end,
symbolized by the End Event element.
As previously mentioned, this model’s nodes sorting is a valuable exercise
for both the understanding of our modified DSM and the one made by the
web application: the only one peculiarity in the DSM of Figure 2.6 that we
wish to stress regards, in fact, sorting.
In A.2.0 BPMN diagram we arbitrarily assigned the index to Task 2,
Task 3 and Task 4. In A.2.1 diagram the ordering of these particular nodes
demands greater attention. Task 2 and Task 4 indeed head towards Task
3: for this reason, Task 3 has to appear after the other two activities.
Otherwise (we invite to try it out) a sequence mark would appear in the
lower half of the matrix, even if there is no iteration loop. Notice also that
the rhombus has not the same meaning of sequence flows: it represents the
connection with all the possible paths that can be taken, but only one of
them will be followed.
27
42. 2.3.4 Interrupting and Non-Interrupting Intermediate Bound-
ary Events
The third node in Figure 2.7 presents three new BPMN symbols: a Message
Non-Interrupting Boundary Intermediate Event (orange circumference with
a double dashed border), an Escalation Interrupting Boundary Intermediate
Event (orange circumference with double solid border), and the subprocess
one (the little framed cross). The first two of them are attached to an activ-
ity (in the present case, Collapsed Sub-Process) and could happen amid its
execution. An Intermediate Boundary Event has the effect of terminating
immediately the task to which is attached to, and to redirect the process
execution towards another path. The latter would not take place if the
Intermediate Boundary Interrupting Event hadn’t occurred. Referring to
the diagram in Figure 2.7, the effect of Boundary Intermediate Event In-
terrupting Escalation is to stop the Collapsed Sub-Process task, even if not
completed, and to force the overall process to continue with Task 4 and to
finish in End Event 2.
Figure 2.7: The A.3.0 BPMN diagram from [26]
On the other side, a Non-Interrupting Boundary Intermediate Event oc-
curs during the execution of another task (the one onto which it is applied)
but does not provoke its termination. On the contrary, it generates another
path that takes place simultaneously with the default one. Referring to the
diagram in Figure 2.7, the Boundary Intermediate Event Non-Interrupting
Message effect is to give rise to Task 3 and, at the same time, to let Col-
lapsed Sub-Process to complete and to continue with Task 2. The process
stops with End Event 1 when each one of the parallel branches converges in
it.
Lastly, the framed cross inside the Collapsed Sub-Process task symbol
indicates that the task is in its turn a process. Collapsed here indicates that
28
43. its details are not presented in the same diagram (although it is a possibility
taken into account in the BPMN specification, see [21]). We recall that this
example, as the others that are taken from [26], is not a real process model,
and then the labels are simple meaningless placeholders.
The Message Non-Interrupting Boundary Intermediate Event and Es-
calation Interrupting Boundary Intermediate Event elements are BPMN’s
Events examples. Bruce Silver [27] defines an event as "something that hap-
pens" in a process, e.g. the reception of a message or the occurring of an
exception. Events are one of the features which distinguish BPMN diagrams
from traditional flowcharts.
Figure 2.8: The DSM conversion of the BPMN process A.3.0 (spreadsheet)
In the DSM conversion of A.3.0 BPMN diagram (Figure 2.8) there are
no rows and columns assigned to the Boundary Intermediate Interrupting
or Non-Interrupting Events because they are not isolated nodes. Their exis-
tence is strictly related to another task. In a BPMN diagram, it is impossible
to find such a symbol detached from one of the rounded rectangles. We in-
terpret them as a sequence flow characterization. From this perspective, it is
natural to put the Intermediate Boundary Interrupting or Non-Interrupting
symbols inside the matrix, replacing the plain circle where the connection
is to be represented. In the present case, the two symbols find their place
in the intersections between the third row and the fifth and sixth columns.
Finally, the framed cross in the Collapsed Sub-Process task is transcribed
in the header of its row and column.
The lower half of the modified DSM in Figure 2.8 is empty because of
the absence of iteration loops.
2.3.5 Catching and throwing events, iterations
A BPMN Throwing or Catching Intermediate Event (generalized in Figure
2.9 by the double-circled timer) represents, in short, the trigger signal that
provokes the execution of other process’ tasks (see [27] or [21] for a detailed
29
44. explanation). The BPMN diagram in Figure 2.9 is to be interpreted as: the
reception of a message (Receive data Id) sets off the process execution, which
continues with Check for uploaded data. After this task, if the Available?
condition is satisfied, the process proceeds with Upload data and ends in
End Event 1. If the condition is not satisfied, the Check for uploaded data
is repeated because triggered by a 10 min waiting. The short circuit Check
for uploaded data, Available? and 10 min constitutes an iteration loop.
Figure 2.9: A BPMN diagram with an iteration loop adapted from [27]
Figure 2.10: The DSM conversion of BPMN diagram in Figure 2.9 (spread-
sheet)
Unlike Intermediate Boundary Interrupting or Non-Interrupting Events,
Throwing and Catching Intermediate Events stand on their own in a BPMN
diagram. We decide then to reserve them a row and a column as in the DSM
of Figure 2.10. The same Throwing Event is responsible for the iteration
loop which consists, if the no condition is satisfied at the Available? gateway,
in waiting for 10 min and then repeat the Check for uploaded data activity.
The loop is indicated in the DSM by the only point positioned in the lower
half of the matrix. It links the 10 min row to the Check for uploaded data
column.
Even in the present case, multiple nodes ordering possibilities are accept-
able. Sorting is unambiguous for the first three nodes. After the Available?
gateway, two options are eligible. We could first index the Upload data and
End Event 1 branch (with indexes 4 and 5 respectively), and then assign
30
45. the last index (number 6) to 10 min. Alternatively, as chosen in Figure 2.10,
we could first index the 10 min event and then follow the remaining branch.
2.3.6 Lanes and collaborations
With the model in Figure 2.11 we introduce some new BPMN concepts:
pools, lanes and message flows. The diagram describes two processes, the
first labeled with Team Assistant and the second labeled with Process En-
gine - Invoice Receipt, which collaborate together to accomplish the result.
Processes are wrapped in a BPMN pool, represented by a rectangle. Pools
should be labeled with the process name, as Silver’s style rules recommend
[27]. The Process Engine - Invoice Receipt pool has three additional subdivi-
sions, called lanes: Accountant, Approver and Team Assistant. The Process
Engine - Invoice Receipt process unfurls over all of its three lanes. Lanes are
used to associate tasks with their performer. From Figure 2.11 we under-
stand that Approve Invoice is an Approver’s activity, Prepare Bank Transfer
is done by the Accountant, and so on and so forth.
Apart from the dotted arrows between pools (called message flows) and
the lanes subdivisions, the diagrams, each one of its own, maintain the mean-
ing explained in previous examples. There are furthermore three new BPMN
symbols. The first, a pentagon inside a double circumference wrapped by a
rhombus, is introduced in the Team Assistant pool and represents an Event
Based Gateway. While the Exclusive Gateway evaluates a condition, the
Event Based Gateway reroutes the process towards the first event that oc-
curs. Referring to the diagram in Figure 2.11, the first event that takes
place between 7 days and Invoice Review Needed enables its own path. The
other symbols are included in activities rounded rectangles (top left corner),
and are a person’s outline and a clockwork. The former informs that the
task is to be executed by a person (a User Task in BPMN modeling), while
the latter marks the task as performed by an automated activity (a Service
Task e.g., a scheduled mail, in BPMN modeling).
Message Flows represent a possible communication between processes (in
this case, between Team Assistant and Process Engine - Invoice Receipt).
Referring to Figure 2.11, for example, we understand that there could be
an information flow between Team Assistant’s Assign Approver and Process
Engine’s Assign Approver.
Lastly, we dwell on the presence of more End Events. Since each one is
assigned to mutually exclusive paths, only one of them will be the overall
process end, and the model preserves its meaning.
Following [2] example, we deal now with the building of a Multiple Do-
main Matrix (MDM) composed by two DSMs (grey and green backgrounds
in Figure 2.12), one for each of the BPMN processes, and two Domain Map-
ping Matrix (DMM; white background in 2.12). The two DSMs can be
swapped without implications, as long as the DMMs are properly reorga-
31
47. Figure 2.12: The DSM conversion of the BPMN process C.1.0 (spreadsheet)
33
48. nized. Activities ordering in the Team Assistant pool is done as in previous
examples. Tasks sorting in the Process Engine - Invoice Receipt pool is
done, regardless of its lanes (Accountant, Approver and Team Assistant), as
in previous examples.
We assign the two DMM to represent message flows between pools. Their
reading convention is the same suggested by the violet arrow inside left-
upper white rectangle displaying the process label, that is row to column.
The right-upper DMM displays message flows from the Team Assistant pool
tasks to the Process Engine - Invoice Receipt ones, while the left-lower DMM
depicts message flows from the latter to the former’s activities. We use the
same background color, white, to differentiate DSMs from DMMs.
Lastly, we add one (Team Assistant DSM) or two (Process Engine -
Invoice Receipt DSM) headers to column invoices. In both cases, the higher
header reports the pool’s label. For the Process Engine - Invoice Receipt
DSM, the middle heading displays an abbreviation of the performer’s label,
corresponding to the pool’s lanes labels.
2.3.7 Data objects
The last BPMN model we address introduces Data Objects. A Data Object
is, in Bruce Silver’s own words [27],
[...] a programming construct. It represents a local variable in a
process level, a piece of temporary data stored inside the process
instance while it is running. [...] And when the process level
ends, the data object goes away. In other words, it works like a
variable in a computer program, not what a modeler normally
means by "data".
Data objects are associated with activities using a dotted dash. Refer-
ring to Figure 2.13, Employee’s Forward budget materials has a data input
association towards Budget Materials Data Object, while Manager’s Review
Budget has a data output association towards Budget Materials. For the pre-
cise meaning of data input and output association, we refer to the BPMN
specification [21].
To represent BPMN Data Objects (the same technique can be used for
Data Stores) we adopt an external matrix as the one presented in Figure
1.13, with the difference that our (Figure 2.14) displays documents available
to DSM elements and there is just one matrix for both inputs and outputs.
To distinguish between inputs and outputs we will simply use two differ-
ent symbols whose meaning is explained by the legend in Figure 2.14. The
reading convention is always row to column, as indicated by the violet left-
upper row in the Budget Process rectangle. The DSM informs us that the
task Forward Budget Materials, belonging to the Budget Process and per-
formed by the Employee figure, writes the Budget Materials Data Object.
34
49. Figure 2.13: A BPMN diagram with data objects adapted from [27]
35
50. Furthermore, the Manager character, while executing the Review Budget
task, needs to read the same Data Object.
Figure 2.14: The DSM conversion of BPMN diagram in Figure 2.13 (spread-
sheet)
2.3.8 Remarks
The examples included in this Chapter do not deplete all the BPMN el-
ements listed in following Tables 2.1, 2.2 and 2.3. The strategy hereby
presented, nonetheless, can be easily extended to cover all cases.
36
51. Element Attributes
participant (pool) id, name, processRef
laneSet id, lane with name, childLaneSet,
flowElementRef
sequenceFlow
(unconditional)
id, name, sourceRef, targetRef
messageFlow id, name, sourceRef, targetRef
exclusiveGateway id, name
parallelGateway id, name
task (none) id, name
userTask id, name
serviceTask id, name
subProcess (expanded) id, name, flowElement
subProcess (collapsed) id, name, flowElement
CallActivity id, name, calledElement
DataObject id, name
TextAnnotation id, text
association/dataAssocia-
tion
id, name, sourceRef, targetRef,
associationDirection
dataStoreReference id, name, dataStoreRef
startEvent (none) id, name
endEvent (none) id, name
messageStartEvent id, name, messageEventDefinition
messageEndEvent id, name, messageEventDefinition
timerStartEvent id, name, timerEventDefinition
terminateEndEvent id, name, terminateEventDefinition
documentation text
Group id, categoryRef
Table 2.1: BPMN 2.0 Descriptive conformance subclass elements and at-
tributes
37
52. Figure 2.15: BPMN 2.0 events, part one
Figure 2.16: BPMN 2.0 events, part two
38
56. 3.1 Automatization of the conversion algorithm
3.1.1 BPMN parsing
Camunda’s BPMN Model API
Camunda Company [30] builds software for workflow and decision automa-
tion. The company develops an open-source platform that supports also the
BPMN standard. They provide a Java API which includes a BPMN Model
API. From Camunda’s documentation [31]:
The BPMN model API enables easy extraction of information
from an existing process definition, editing an existing process
definition or creating a complete new one without manual XML
parsing.
We will use the BPMN Model API to read an existing model, which is
the BPMN file describing the diagram we want to convert to a DSM format.
The complete API documentation [32] is available online. In the following
paragraph, we will give a basic example of its usage.
Parsing BPMN with Camunda library: an example
Figure 3.2 displays a simple BPMN model, whose partial serialization is:
[...]
<bpmn2:process id="_11" name="Process" isExecutable="true" isClosed="true">
<bpmn2:endEvent id="endEvents_2884dc89-48ec-7342-12ae-7a4494f5565b"
name="End of Process">
</bpmn2:endEvent>
<bpmn2:startEvent id="startEvents_a4435826-6c80-d597-2742-eb1affd657da"
name="Receive Data ID">
</bpmn2:startEvent>
<bpmn2:task id="tasks_2c62e858-3974-908a-1412-29d529d4b43c" name="Task A">
</bpmn2:task>
</bpmn2:process>
[...]
Figure 3.2: A simple BPMN diagram
42
57. Through Camunda’s BPMN Model Java API we can extract some in-
formation about the Receive Data ID node (Start Event). For BPMN
to DSM conversion, we will need at least two of the element attributes,
namely "id" and "name". Another datum of relevance is the identifier (id)
of the succeeding node (Task A in the present case). Since we are deal-
ing with a Start Event there are no preceding nodes, otherwise the method
getPreceedingNode() is the counterpart of getSucceedingNode(). The
code that extracts the desired information is:
extractInformationFromBPMNelement(File xmlBPMNFile) {
BpmnModelInstance modelInstance = Bpmn.readModelFromFile(xmlBPMNFile);
Collection<Process> processes = modelInstance.getModelElementsByType(Process.class);
processes.forEach(process -> {
StartEvent startEvent = rocess.getUniqueChildElementByType(StartEvent.class);
startEvent.getId(); //gets startEvents_a4435826-6c80-d597-2742-eb1affd657da
startEvent.getName(); //gets "Receive Data ID"
startEvent.getSucceedingNode().getId();
//gets tasks_2c62e858-3974-908a-1412-29d529d4b43c
});
}
where the BpmnModelInstance interface represents the BPMN 2.0 Model
outlined in the File instance xmlBPMNFile.
3.1.2 The ordering problem
As will be explained in Section 3.3.1, BPMN diagrams XML representation
does not contain the diagram nodes sorted in the order we need them to
be. An explanation of the Application Layer Business Logic is postponed
to Section 3.3. In this Section, we give an intuitive hint of the mathemat-
ical procedures used to scan graphs, that are depth-first and breadth-first
algorithms.
Purpose of these algorithms is to visit at least once every node of a graph.
Generally, this procedure serves to assign a weight (i.e. a real number) to
each node, where the weight can represent whichever quantity is of interest.
For example, if the graph models a process, the weight could be represen-
tative of the time duration of each step, where the latter is depicted by a
node. In our case, these procedures will be used by the application engine to
sort BPMN serialized elements in the order outlined in Chapter 2 examples,
while no weight is assigned to nodes.
We anticipate that at first only the depth-first search automatized the
BPMN nodes sorting operation. Since the algorithm did not provide the ex-
pected results, we adopted lastly the breadth-first search procedure (Figure
4.2; other examples in Chapter 4).
43
58. The graph model
The graph represented in Figures 3.3 and 3.4 is classified as a finite undi-
rected acyclic graph, where undirected emphasizes the absence of links orien-
tation (in short, they are represented by plain segments and not by arrows)
and acyclic means that is not possible to visit twice a node by reaching it
from other nodes. Even if undirected, the resemblance of a finite undirected
acyclic graph with a BPMN diagram suggests that this mathematical model
is an appropriate choice to abstract the latter.
Depth-first algorithm
The depth-first search ordering pseudocode is as follows:
setBpmnIndex(mapToIndex, isVisitedMap){
idOfStartNode = mapToIndex.findStartItem();
mapToIndex.get(idOfStartNode).setBpmnIndex(index);
index++;
isVisitedMap.put(idOfStartNode,true);
followChildren(idOfStartNode,mapToIndex,isVisitedMap);
}
followChildren(idOfNodeToFollow, mapToIndex, isVisitedMap){
currentNode = mapToIndex.get(idOfNodeToFollow);
childrenIdsOfCurrentNode = currentNode.getChildrendIds();
for(childId : childrenIdsOfCurrentNode){
if(!(isVisitedMap.containsKey(childId))){
nodeInElaboration = mapToIndex.get(childId).;
nodeInElaboration.setBpmnIndex(index);
index ++ ;
isVisitedMap.put(nodeInElaboration.getBpmnId(),true);
followChildren(nodeInElaboration.getBpmnId(),mapToIndex,isVisitedMap);
}
}
}
The pseudocode develops in a few steps. mapToIndex is the implemen-
tation’s graph representation. At first, the starting node, which is the node
with no predecessors (in a BPMN diagram it coincides with a Start Event) is
identified and indexed. The isVisitedMap map keeps track of the already
scanned nodes. After its updating with the identifier of the first node, the
followChildren function is called recursively. The latter selects the chil-
dren of the node in elaboration, which at first step is the starting node, and
follow its children until the graph’s end or the encountering with an already
visited node. The procedure is repeated for all the children of the starting
node.
A closer look at Figure 3.3 will immediately clarify the idea just de-
scribed: the graph is scanned, as the algorithm’s name suggests, in depth
(vertically).
44
60. Breadth-first algorithm
The breadth-first pseudocode is as follows:
indexNodes(){
firstNode = mapToIndex.get(mapToIndex.findStartItem());
firstNode.setBpmnIndex(index);
index++;
isVisitedMap.add(firstNode.getBpmnId());
breadthFirstAlgorithm(firstNode);
}
breadthFirstAlgorithm(node){
isVisitedMap.add(node.getBpmnId());
if(!(node.getChildrendIds().isEmpty())){
indexChildren(node);
index ++;
for(childId : node.getChildrendIds()){
if(!(isVisitedMap.contains(childId))){
breadthFirstAlgorithm(mapToIndex.get(childId));
}
}
}
}
As for the depth-first search, the isVisitedMap keeps track of the al-
ready scanned nodes. After the first node is identified among the others
by the findStartItem() method, it is indexed and passed as the initial
seed for the recursive call of breadthFirstAlgorithm. The latter indexes
sequentially the current node’s children and is then applied over the node
own children. No unvisited node is left behind before going deeper into the
graph.
A closer look to Figure 3.4 will immediately clarify the idea just de-
scribed: the graph is scanned, as the algorithm’s name suggests, in breadth
(horizontally).
A remark on acyclic graphs
We mentioned the resemblance of a finite undirected acyclic graph with a
BPMN diagram. It can be argued that a BPMN model as the one in Figure
2.9 presents an iteration loop which can not be included in an acyclic graph.
The diagram in Figure 2.9 can be nonetheless abstracted by a cyclic graph,
onto which the depth-first and breadth-first algorithms can be applied with
no modifications. Cyclic means that it is possible to scan twice a starting
node by reaching it from other nodes.
46
61. 3.2 Technology
3.2.1 Architecture
The application’s architecture is represented in Figure 3.5, which displays a
3-tier application architecture. A 3-tier application physically decouples the
user interface (Presentation layer), the business logic (Application layer)
and the data access (Data layer). In the present case the presentation
layer is structured as a single-page application (SPA) developed with the
Angular framework [38]. A SPA thins the user experience by rewriting the
page currently on the view, acting like a desktop application rather than a
web page. The application layer is built upon a Spring-based web service
[36], which deals also with BPMN processing using a third-party library
(Camunda’s BPMN Model API [32]). The data layer is ruled by Spring’s
starter JPA, which connects the higher tiers with the relational database H2
[39] by means of the open-source Java persistence framework Hibernate [33].
Presentation Layer
The user interface (Figure 3.1) of the single-page application allows the
user to select the desired DSM from a lateral menu (on the left, grey back-
ground). On the top-left corner, above the available DSM names and be-
low the dark blue toolbar displaying the application name (a temporary
bpmn2dsm), there is a frame to upload BPMN XML files to be converted.
The lower light-blue toolbar shows the currently drawn DSM, (the Library
one in Figure 3.1).
Figure 3.5: The single-page web application architecture
47
62. The user interface is ruled by two Angular components (the first for
the lateral menu and the second for the main card in which the DSM is
shown). The components interact with 3 Angular services. The first service
retrieves the menu’s entries at first opening of the web page. The second
one gets the JSON object describing the DSM (see Section 3.3.2) from a
RESTful endpoint (Application Layer) when required by the user, while the
third manages files uploading. The DSM’s JSON object is then visualized
through Angular’s Structural Directives (Section 3.4).
Application Layer
The Presentation Layer interacts with a RESTful endpoint provided by a
Spring Boot application. Spring is a framework for building Java applica-
tions, whose Spring Boot project [37] constitutes a simplified tool for fast
development. Spring Boot is based on an opinionated view of the Spring
framework. The starter dependencies of our concerns are about the JPA
implementation and the database storage.
Besides acting as a RESTful endpoint for the retrieval of data at the ser-
vice of the Presentation Layer, the Application Layer contains the Business
Logic (Section 3.3) that converts the BPMN files to DSM resembling JSON
objects.
Data Layer
The application leans on one of Spring Boot’s integrated databases, H2, in
embedded mode. This choice is due to this thesis project extent, which is
simply a proof of concept on the feasibility of the BPMN to DSM conversion.
The database data can be easily accessed thanks to the spring-boot-
starter-data-jpa dependency, which is Spring Data JPA with Hibernate [33]
as the implementation.
We take advantage of the Data Layer to give an example of Spring Boot
fast development conception. To configure H2 in embedded mode, using
Hibernate as JPA implementation, it is sufficient to add to the
application.properties project configuration file the following lines:
spring.datasource.url=jdbc:h2:~/test
spring.datasource.driverClassName=org.h2.Driver
spring.jpa.database-platform=org.hibernate.dialect.H2Dialect
In the schema.sql project file it is possible to specify the database tables
creation and schema:
CREATE TABLE tbl_files (
fileid INT AUTO_INCREMENT PRIMARY KEY,
bpmnname VARCHAR(200) DEFAULT NULL,
json CLOB DEFAULT NULL,
48
63. processed BOOLEAN DEFAULT FALSE
);
On startup, Spring framework scans the application.properties con-
figurations and therefore allocates the database, detects the repositories,
and so on and so forth.
3.3 Business Logic
3.3.1 BPMN processing
Once received from the Presentation Layer, the BPMN file is stored in one
of the project folders. Camunda’s readModelFromFile method returns a
BpmnModelInstance (Section 3.1.1) from which the XML processing can be
started. The conversion is completed in three steps: partial BPMN parsing
for graph creation, graph sorting, completion of BPMN parsing. Parsing is
executed through appropriate variations of the Camunda example in Section
3.1.1. The conversion result consists of a JSON object, describing the BPMN
in a DSM advantageous format, whose structure is specified in Section 3.3.2.
Partial BPMN parsing for graph creation
First BPMN parsing solves the crucial problem of BPMN to DSM conver-
sion, that is BPMN nodes ordering. To automatize the handmade operation
of Chapter 2, we need a data structure that summarizes the diagram ele-
ments relationships (e.g., Ask for a book succeeds the Start Event; Go to
library precedes the End Event; etc) and an algorithm to operate on that.
It may be unclear the reason why a sorting algorithm is needed, because we
did not linger long on BPMN serialization. To make it clear, we recall the
short extract of BPMN XML file presented in Section 1.5.3:
[...]
<bpmn2:process id="_11" name="Process" isExecutable="true" isClosed="true">
<bpmn2:boundaryEvent id="errorBoundaryEvents_dfd9db6d-5532-96a3-7e0a-a202f4ce40e1"
cancelActivity="true" attachedToRef="tasks_b47fd0a1-04fe-6826-db12-611ce9033a46">
<bpmn2:outgoing>sequenceFlows_05526f32-52e2-78d6-83f7-5174939b53ac</bpmn2:outgoing>
<bpmn2:outputSet id="outputSet_5c85f736-e2cc-3c75-39e5-41aa5ab45b37"
name="default input set"/>
<bpmn2:errorEventDefinition
id="errorEventDefinition_ffb2b2a3-f0a5-d5ab-7e6f-fd482f605aa6"/>
</bpmn2:boundaryEvent>
[...]
<bpmn2:startEvent id="startEvents_a3cf2661-9e87-bf17-82fd-2c014916ee90"
name="Start Event">
<bpmn2:outgoing>sequenceFlows_dfbd352b-55be-6959-2126-e1ab7a948ba9</bpmn2:outgoing>
</bpmn2:startEvent>
<bpmn2:task id="tasks_b47fd0a1-04fe-6826-db12-611ce9033a46" name="Task A">
<bpmn2:incoming>sequenceFlows_dfbd352b-55be-6959-2126-e1ab7a948ba9</bpmn2:incoming>
49
