MODELING WITH BPMN AND CHORDA: A TOP-DOWN,

DATA-DRIVEN METHODOLOGY AND TOOL

Andrea Catalano, Matteo Magnani and Danilo Montesi

Department of Computer Science, University of Bologna, Mura A. Zamboni 7, 40127 Bologna, Italy

Keywords:

BPMN, Methodology, Data, Design tool.

Abstract:

In this poster paper we present a methodology, named

chorda

, for the modeling of business processes with

BPMN. Our methodology focuses on the peculiar features of this notation: its ability to illustrate different

levels of abstraction, its support for both orchestration and choreography, and the representation of data ﬂows.

In particular, this last feature has been extended to allow a better mapping of real processes, where data often

plays a fundamental role. To evaluate and tune the methodology, we have developed a tool supporting it.

1 INTRODUCTION

BPMN is the OMG standard notation for the repre-

sentation of business processes(BPMN, 2009; Wohed

et al., 2006; White and Miers, 2008). Even if BPMN

constructs are very intuitive, business process dia-

grams can be difﬁcult to design without any associ-

ated methodology — much like building a miniature

ship model with glue and screws, but without instruc-

tions. In this poster paper we introduce a methodol-

ogy, named

chorda

, for the translation of informal

process descriptions into BPMN diagrams.

Why do we need a speciﬁc methodology for

BPMN? This lies in the very nature of this language,

which enables the representation of three important

aspects of business processes, making it a unique

modeling tool. First, we can represent a choreogra-

phy of processes, i.e., how different processes interact

with each other to fulﬁll a common objective. Sec-

ond, we can represent the orchestration of a process,

i.e., its internal organization into sequences of activ-

ities. Third, BPMN allows the representation of the

same information at different levels of detail, using

sub-processes — this being fundamental to provide

different views of the same process to people with dif-

ferent roles, like top managers and technical staff.

Basically, BPMN allows the representation of

complex scenarios because it can include many dif-

ferent aspects into a single diagram: choreography,

orchestration, and data, at several different levels

of abstraction (BPMN, 2009; Barros et al., 2006).

Therefore, the main idea behind our approach is

that the initial requirements can be split into differ-

ent classes, that can be speciﬁcally addressed during

well separated and thus simpliﬁed modeling steps.

As we have illustrated in Figure 1, after a typical

pre-processing of the available informal requirements

aimed at removing ambiguities and producing a dic-

tionary with all deﬁnitions and synonyms, we split

them into atomic statements referring to one of the

following aspects: (D) data, (I) interactions between

different participants, and (L) local work of a single

participant. At this point, each class can be processed

independently from the others.

To the best of our knowledge, this is the ﬁrst

presentation of a methodology for BPMN mod-

eling. Obviously, it is based on best practices

taken from existing data and software modeling

methodologies like the IBM Rational Uniﬁed Pro-

cess (

www-01.ibm.com/software/awdtools/rup

the IDEF methods (

http://www.idef.com

), data

modeling using ER diagrams and Object Pro-

cess Modeling (

http://www.objectprocess.org

The POEM (Process Oriented Enterprise Modelling)

methodology uses BPMN as one of several basic di-

agram types. Although we are not aware of existing

presentations of this methodology, still under devel-

opment, it seems to have a wider scope than our pro-

posal, covering several additional aspects of an enter-

prise, while we present speciﬁc results regarding the

BPMN notation.

1.1 Extended Notation and Design Tool

Before introducing the methodology, it is worth men-

tioning the extensions for the representation of data

389

Catalano A., Magnani M. and Montesi D. (2009).

MODELING WITH BPMN AND CHORDA: A TOP-DOWN, DATA-DRIVEN METHODOLOGY AND TOOL.

In Proceedings of the 11th International Conference on Enterprise Information Systems - Information Systems Analysis and Speciﬁcation, pages

389-392

DOI: 10.5220/0002003603890392

 SciTePress

Figure 1: A diagram summarizing the proposed methodology.

Figure 2: A store (a), which has been expanded in (b) to

show it at a lower abstraction level.

that we have implemented in our tool. In our opinion

data manipulation is usually the most important as-

pect and objective of a business process (Sadiq et al.,

2004; Russell et al., 2005). In addition, in the BPMN

speciﬁcation data objects have been deﬁned as a pre-

deﬁned artifact of BPMN (together with comments

and associations), because the BPMN speciﬁcation it-

self declares that in some diagrams they represent the

most important information to be modeled. However,

the current version of BPMN has been mainly devel-

oped to represent activities and events, and at the mo-

ment the only visual construct used to represent data

is the data ﬂow, a small rectangle with a folded corner

that can be added on top of control ﬂows.

In our tool, we have considered two main addi-

tional data representation capabilities. The ﬁrst con-

sists in the possibility of associating a data object to

an XML document or XML Schema, to provide a way

to represent complex and structured objects inside a

diagram. The second is a new visual construct, the

store, that has been taken from Data Flow Diagrams

(DFD) and can be used to show the full life cycle of

data: where it is stored, when it is retrieved to be ma-

nipulated and where it is stored again after their ma-

nipulation (Gane and Sarson, 1977; Yourdon, 2006).

Also stores can be structured, to provide different ab-

straction levels consistently with the philosophy of

BPMN, and to represent expanded stores we use an

ER-like notation (Chen, 1976). The visual construct

used to represent a store is illustrated in Figure 2.

The design tool developed to support our method-

ology is a plug-in for the Microsoft Visio applica-

tion (

http://office.microsoft.com/visio

The tool extends the POEM stencils

(

http://bpmnpop.sourceforge.net

), and can

be used to design BPMN diagrams, to annotate

them with additional attributes (like the cost of

activities) and to generate their XPDL representa-

tions (Magnani and Montesi, 2007; XPDL, 2005).

A beta time-limited version can be downloaded at

http://www.easybpmn.com

2 THE METHODOLOGY

2.1 Preliminaries

We shall assume to start from a single text ﬁle de-

scribing the requirements. This ﬁle can be processed

as usual, by clarifying unclear sentences, identify-

ing synonyms, replacing them with consistent terms,

and building a technical dictionary. Then, we may

identify all the data objects mentioned in the require-

ments, and all the participants.

At this point, we can split the requirements into

small atomic statements, and assign each statement to

one of the three following classes:

• Data requirement (the statement concerns only

data).

• Interaction requirement (the statement refers to

two participants).

• Local requirement (the statement refers to one

single participant).

2.2 Data Modeling

We can now start modeling data requirements (D).

Data is a primary component of real business pro-

cesses and will thus drive all the modeling activities.

In fact, a process is basically a sequence of activi-

ties aimed at modifying some data or objects, and the

production of new data is the way in which business

ICEIS 2009 - International Conference on Enterprise Information Systems

390

processes generate value — for example, many busi-

ness processes are used to transform raw materials

into ﬁnal products. As BPMN offers a limited support

to the modeling of data, being more activity/event-

oriented, these requirements could be addressed by

existing data modeling approaches and attached to the

diagrams as complementary documentation. How-

ever, as data is so important in many processes and we

do not want to lose the connection between the data

and the tasks manipulating it, in our tool we use the

aformentioned extended version of BPMN, obtained

by including some features of ER and Data Flow Dia-

grams into the notation. After this modeling step, we

will have identiﬁed a list of all the data/objects refer-

enced in the requirements — the next step will be the

deﬁnition of how they are exchanged among different

participants.

2.3 Interaction Modeling

Data ﬂows will then be used to generate a so called

skeleton diagram representing how data is exchanged

between the participants to produce the ﬁnal prod-

ucts of the process. Basically, during this step we

focus on choreography, i.e., we identify all the par-

ticipants and their interactions (I). Each participant is

represented using a BPMN pool, and we draw a mes-

sage ﬂow between two of them for each requirement.

In this way, after having identiﬁed all interaction re-

quirements we can automatically build a skeleton di-

agram, as we have exempliﬁed in Figure 3(a): each

interaction between participants A and B corresponds

to a

Send Data

activity in A, a

Receive Data

activ-

ity in B, and a

Process Data

sub-process in B, indi-

cating that the received data will be later manipulated

— this will be expanded during the next step of the

methodology.

Choreography has been studied extensively both

in academia (in the area of process algebras) and in-

dustry (with the proposal of standard languages): in

this paper we do not deal with the representation or

veriﬁcation of choreographies,but with the formaliza-

tion of existing informal descriptions of a choreogra-

phy — automated veriﬁcation tools will obviously be

of great utility to check the designed diagram, but this

is an orthogonal problem with respect to the scope of

this paper.

2.4 Local Modeling

Now, we will have a skeleton diagram with all the

participants (pools) and all messages exchanged be-

tween them, representing the complete (abstract) data

paths used to produce the ﬁnal outcome of the pro-

cess, be it a document, a product, or any other valu-

able object. For each exchanged message, we will

also have a sub-process (the rectangle with a small

plus sign represented in Figure 3(a)) hiding the lo-

cal activities performed by the participant to manipu-

late the data. Therefore, we can focus on the remain-

ing requirements (L) describing these activities. This

modeling step can be performed in a top-down way,

following the philosophy behind BPMN which uses

abstraction levels as a basic tool to provide different

views on the same process. Therefore, L-statements

will be structured hierarchically (as trees of require-

ments, or nested item lists) and modeled recursively.

For example, consider the following statements:

1. The CIO shall store a copy of the report into the

archive, and

2. prepare an IT plan as follows:

(a) collect information on all the systems currently

used in the company,

(b) then evaluate their life cycle state (trailing,

leading or bleeding edge)

These can be modeled as illustrated in Figure 3(b),

where we have also used one of our data modeling

extensions: the store (archive). Later, the

Prepare

IT plan

sub-process can be expanded including the

statements describing this activity (items 2.a and 2.b,

in this example), and so on recursively.

3 SUMMARY

The methodology proposed in this paper is composed

of the following main steps:

1. Pre-process the initial requirements (remove am-

biguities, update and reﬁne unclear sentences and

generate a dictionary with explanations of the

technical terms and indications of synonyms).

2. Split the requirements into elementary statements.

3. Identify the participants and the exchanged data.

4. Separate data (D) statements from activity state-

ments and model the data.

5. Mark each remaining statement as a local (L) ac-

tivity (orchestration) or an interaction (I) among

participants (choreography).

6. Draw the skeleton of the process, modeling inter-

action activities.

7. Tree-structure local activities, associate them to

sub-processes in the skeleton diagram, and model

them in a top-down way by increasing the level of

detail at each iteration (if necessary).

MODELING WITH BPMN AND CHORDA: A TOP-DOWN, DATA-DRIVEN METHODOLOGY AND TOOL

391

(a)

(b)

Figure 3: (a) The skeleton diagram corresponding to a statement: The report shall, as soon as it has been established, be

transmitted by the external consultant to the CIO, and (b) the modeling of local (L) requirements, in a top-down fashion.

In this way, part of the modeling activity can be

semi-automated, and the deﬁnition of the orchestra-

tion inside each pool can be performed by focusing

on small portions of the initial requirements. In ad-

dition, each statement can be easily associated to a

speciﬁc part of the ﬁnal diagram, and it can be then

veriﬁed if the diagram is complete, i.e., if it models

all the initial requirements.

REFERENCES

Barros, A., Dumas, M., and Oaks, P. (2006). Standards

for web service choreography and orchestration: Sta-

tus and perspectives. In Springer, editor, Work-

shop on Web Service Choreography and Orchestra-

tion for Business Process Management, volume 3812

of LNCS.

BPMN (2009). Business process modeling notation speci-

ﬁcation.

Chen, P. (1976). The Entity-Relationship model — toward

a uniﬁed view of data. Transactions on Database Sys-

tems, 1(1):9–36.

Gane, C. and Sarson, T. (1977). Structured Systems Analy-

sis: Tools and Techniques. IST, Inc.

Magnani, M. and Montesi, D. (2007). BPMN: How much

does it cost? an incremental approach. In Business

Process Management (BPM), 5th International Con-

ference, volume 4714 of Lecture Notes in Computer

Science, pages 80–87. Springer.

Russell, N., ter Hofstede, A. H. M., Edmond, D., and

van der Aalst, W. M. P. (2005). Workﬂow data pat-

terns: Identiﬁcation, representation and tool support.

In 24th International Conference on Conceptual Mod-

eling, volume 3716 of Lecture Notes in Computer Sci-

ence, pages 353–368. Springer.

Sadiq, S. W., Orlowska, M. E., Sadiq, W., and Foulger, C.

(2004). Data ﬂow and validation in workﬂow mod-

elling. In Fifteenth Australasian Database Confer-

ence, volume 27 of CRPIT, pages 207–214.

White, S. A. and Miers, D. (2008). BPMN Modeling and

Reference Guide. Future Strategies Inc.

Wohed, P., van der Aalst, W. M. P., Dumas, M., ter Hofst-

ede, A. H. M., and Russell, N. (2006). On the suitabil-

ity of BPMN for business process modelling. In Busi-

ness Process Management, 4th International Confer-

ence, volume 4102 of Lecture Notes in Computer Sci-

ence, pages 161–176. Springer.

XPDL (2005). Process deﬁnition interface – XML process

deﬁnition language (XPDL) speciﬁcation.

Yourdon, N. E. (2006). Just enough structured analysis. ch.

9: Dataﬂow diagrams. www.yourdon.com.

ICEIS 2009 - International Conference on Enterprise Information Systems

392