processes generate value — for example, many busi-
ness processes are used to transform raw materials
into final 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 identified a list of all the data/objects refer-
enced in the requirements — the next step will be the
definition of how they are exchanged among different
participants.
2.3 Interaction Modeling
Data flows will then be used to generate a so called
skeleton diagram representing how data is exchanged
between the participants to produce the final 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 flow between two of them for each requirement.
In this way, after having identified all interaction re-
quirements we can automatically build a skeleton di-
agram, as we have exemplified 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
verification of choreographies,but with the formaliza-
tion of existing informal descriptions of a choreogra-
phy — automated verification 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 final 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 refine 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