A DSL for collaborative Business Process
Leila Amdah Adil Anwar
Mohammed V University
in rabat
Siweb Team Researsh,EMI Siweb Team Researsh,EMI
Rabat, Morocco
leila.amdah@gmail.com
Abstract—Business process modeling is now an essential
point in building businesses; there is a wide choice of modeling
language in the market, the most popular of which are UML and
BPMN. However, when it comes to modeling a specific area,
these languages remain restricted. A DSL, meanwhile, allows a
concise representation of the semantics of a particular business
field, which allows the development of coherent and expressive
business process models. Thus, these models can be use not only
for modeling a system but also for generating executable
applications. Collaborative business processes are increasingly
present in practice. Their modeling, integration or execution
becomes more and more complex because it involves an
exchange of resources and data between several partners.
Current modeling languages such as BPMN do not allow
detailed modeling of these environments. Thus, in this paper, we
propose a DSL to model business processes in a collaborative
environment. The creation of the latter goes through these
stages: a) defining the abstract syntax of our language, which
consists in the creation of our own metamodel. b) Define a
semantics, which allow presenting the functioning of each
element of our language. c) Finally, define a graphical language
syntax that allows a clear visualization for modeling.
Keywords—BPMN, DSL, Model-Driven, MDA, Collaborative
Business Process.
I. INTRODUCTION
Business processes are now not only modeled but also
managed, which means that the process modeling tool has
been integrated into a process management system which
controls the execution of processes and integrates other parts
of the information system. There are many languages for
modeling business processes. One of the most popular of these
is probably UML activity diagrams. However, there are also
languages for managing business processes for which there is
a compiler for executable code on a process engine. Here,
mention must be made of BPMN [1] and its possible target
language BPEL (Business Process Execution Language).
However, these languages or tools are not useful for everyday
situations, complex or specialized systems, which are used for
specific fields. Indeed, the concept of MDE [2] has proven to
be a very useful asset. In fact, it allows complex systems
development by focusing on an abstract concern rather than
conventional programming. The main idea is to use different
modeling languages called DSL (Domain Specific Language).
A DSL is a modeling language dedicated to a particular field,
it offers users concepts specific to their profession and of
which they have mastery. These languages are generally small
and must be easily manipulated, transformable, combinable,
etc. Thus, one can for example use concepts "customer",
"banker", "account" instead of general concepts like
"component", "class", "node", etc. There are different
approaches to define a DSL, the designer can proceed to a total
creation of a new language from scratch, or extend or refine
an existing language. In our case, we opted for the second
solution and thus we extended the BPMN language. Of
978-1-7281-8041-0/20/$31.00 ©2020 IEEE
Authorized licensed use limited to: TH Brandenburg. Downloaded on October 22,2022 at 17:17:14 UTC from IEEE Xplore. Restrictions apply.
Mohammed V University
in rabat
Rabat, Morocco
anwar@emi.ac.ma
course, BPMN offers the possibility of adding attributes to
these tasks, but it cannot offer the same functionalities as a
DSL.In this work, we propose a DSL for collaborative
business process. That aim to manage deferent scenarios of
collaborative environment. To create a DSL, we start with a
metamodeling that insure a correct definition of DSL.
Managing business processes in collaborative
environments is becoming increasingly tedious, especially
when it is a distributed team where employees are not on the
same workroom. In fact, engineers easily lose track of the
execution of some very important tasks, remote monitoring of
tasks becomes complicated. As well as decision-making
becomes very slow due to miscommunication, delayed task
execution and overrun deadlines. Thanks to collaborative
processes, companies manage to achieve flexible and dynamic
collaboration. In the market, there are several tools for
modeling and executing collaborative business processes
(CBP), namely: Jbpm [3], Bonita [4], Bizagi [5] and others.
According to a comparison made in [6], the author compares
the most used collaborative business process tools and
concludes that the existing tools can only deploy and execute
CBP centrally. That said, an interoperability and autonomy
problem will arise when using these tools. Thus, an MDA
approach seems very logical in this case because it allows
separating between the two layers of modeling and execution.
The platform independent model (PIM) is produce in a
general-purpose or domain-specific modeling language.
Second, PIM is translated into a PSM platform-specific
model, thereby obtaining an executable application. In the
literature there are several proposals on the application of the
MDE paradigm generally [7] in the field of business processes
management, and particularly the MDA approach [8,9] in the
context of managing collaborative business processes to guide
the design, implementation, maintenance and management of
business processes.
In our work, we will use an MDA [10] approach for
collaborative business processes. First, we will define
collaborative process in a business level using a technology-
independent language. This PIM layer describe the explicit
behavior of the collaboration along with the partners’
responsibilities in an independent way of the implementation
technology. Indeed, at this phase analyzes don't have to worry
about technical details. In our case, the realization of the PIM
layer will be translated by the creation of a DSL. Second, in
the technological level, enterprises have to focus on the
implementation of the information system that supports the
collaborative processes. The realization of the PSM layer will
be the objective of our next work.
This paper is organized as follows. Section 2 discusses
related works. Section 3 present steps followed for the
creation of our DSL, starting by metamodeling then semantic
and graphical syntax. Section 4 describes an illustrative
example. Section 5 presents conclusions and outlines future.
 II. RELATED WORK
A DSL allows the semantic representation of a particular
field of activity, which allows more precise and meaningful
business process models. Several works try to create a DSL
for business process. In [11], the authors propose to build a
DSBPMS which is a BPMS Based on a DSL (Domain
Specific Language), instead of using BPMN. The goal of the
approach is to simplify the development of a specific business
process. So, they propose a platform called «GraDe3 »
composed of a Configurator for easy definition of a graphical
editor for the chosen DSL and a new simple mapping language
for defining a transformation. In [12], author create a graphical
domain specific language which can be easily understood by
non-IT professionals called PromodDSL, the DSL is based on
BPMN and keeps his more frequently symbol and is designed
to specify the area of social insurance. This paper [13] presents
a generic framework for process modeling language called
DSLs4BPM, it provides elements common to process
modeling and a basic transformation to the generic BPMN.
The DSL is created by adding types to the framework
language and rules to the transformation at predefined
extension points. Finally, the author implemented his
approach based on the Eclipse Modeling Framework. In the
field of Web 2.0 [14], the author propose a DSL based on
extension of the BPMN standard to model social elements of
social business process, he add new notation to BPMN like
communication, collaboration activities.
Among these works, there are certain approaches, which
are similar to ours, except that our DSL deals with
collaborative environments in general, and not a specific
collaborative domain. Moreover, our DSL gives more
importance and specification to the dataObject that plays a
very important role during the communication between the
partners of the collaboration.
III. DSL FOR COLLABORATIVE BUSSINESS PROCESS
A. DSL Metamodeling
Creating business process collaboration DSLs is a
challenge because collaborative business processes require
different collaboration semantics. Our DSL is based on
Authorized licensed use limited to: TH Brandenburg. Downloaded on October 22,2022 at 17:17:14 UTC from IEEE Xplore. Restrictions apply.
BPMN models to allow clear and understandable modeling for
the various participants, whether being engineers, technicians,
managers or tradesmen. To create our DSL we started with the
metamodeling of our language. In a previous work [15] we
presented a metamodel for collaborative processes called
BPMNForCollaboration, in this work we have improved it
and create the metamodel of our DSL, hence the metamodel
Figure1. We focused on the extension of two elements of
BPMN, which are essential for the construction of our
language (Activity and DataObject). In addition to basic
element of BPMN named on the metamodel
<<BPMNElement>>, the metamodel consists of our
stereotypes named <<ExtensionElement>>.
The "CollabortaiveActivity" stereotype extends the
BPMN class "Activity". It is characterized by the attributes
"type", "isMonitoring", "isTreacable" and
"isMultiparticipant", it is associated with the stereotype
"Actor" thanks to the association Class "Role", it means that a
collaborative activity is performed by an actor that have two
types: either a simple participant or a manager. Then,
"CollaborativeActicvity" is associated with the class
"StateOfProgress" which defines three state of progress
"InProgress, OnBreak, Completed" and finally we define
another activity that is a generalization of the class
"CollaborativeActivity", it is "DeadlinedActivity"
characterized by two attributes: a due date and a relaunch date.
The stereotype "CollaborativeData" extends the BPMN
class "DataObject", it is associated with "Actor" thanks to two
associations "send and receive", in fact, collaborative
document must have one and only one sender and one or more
recipients. Then a "collaborativeData" can be in two forms: a
"Mail" characterized by a creation date and a
"CollaborativeDocument" associated with the class
"DocumentState" which allows defining two document states,
either "Locked" or "validate".
In this section, we have been content to give a general
explanation of the stereotypes because an explicit
specification of these elements will be described thereafter in
table 1.
 Fig. 1. The metamodeling of our DSL
B. Semantic and graphical syntax
In this section, we explain the elements of collaboration
in a detailed way. Each element of table1 contains a
description and a constraint as well as a graphic representation
to concretize our DSL. We chose the OCL (Object Constraint
language) [16] to specify restrictions on our metamodel.
The graphic notations respect the BPMN notation to keep our
DSL more readable and close to the BPMN standard. On va
expliquer brièvement par la suite les nouvelles notations
graphiques de notre langage :
“Shared Activity" means that several external and internal
actors share this activity. "Traecable Activity" is an activity
that keeps track of the execution of the task. "Private Activity"
is an activity that shows that the task is confidential and cannot
be shared with an external collaborator. "Monitoring Activity"
presents an activity that is always monitored by a manager.
"Multiparticipant Activity" is an activity that must have the
Authorized licensed use limited to: TH Brandenburg. Downloaded on October 22,2022 at 17:17:14 UTC from IEEE Xplore. Restrictions apply.
role of participant or manager so it is carried out by several
collaborators. "Activity InProgress / OnBreak / Completed"
specifies the execution progress of the task. "Deadelined
Activity" is an activity with a due date, so it must be completed
before the end of that date.
“Shared data” is data shared between internal and external
collaborators. "Private Data" is confidential data that cannot
be shared with an external collaborator. "Document version"
allows us to specify the version of the shared document, it can
be either an initial version VI or a Final version VF. Our
language also treats the state of the document, so it can be
"Locked" which means that the document can no longer be
modified or "Validate" which means that the document is
validated by the manager.
 TABLE I. SEMANTIC AND GRAPHICAL REPRESENTATION OF OUR DSL

Element of language Graphical Representation

CollaborativeActivity
Description identifies whether the Activity is private or can be shared with a third party, Private
activity can be seen only by the participant to which it belongs

constraint It must be associated at least to one external actor and one internal actor
Context CollaborativeActivity inv:
self.actor->select(a | a. oclIsKindOf (Intern)).size()=1 and self.actors->select(a | a.
oclIsKindOf (Extern)).size()=1
CollaborativeActivity
Description Identifies whether if we can trace the activity or not.
Constraint A traceable activity is always linked to a document that keeps track of its execution
Context CollaborativeActivity inv:
Self.isTraceable= true implies self.CollaborativeDocument-> size()  1

CollaborativeActivity
Description A private activity can’t be seen by an external Actor
Constraint An Activity is said private if it has no external actor.
Context CollaborativeActivity inv:
self.actor-> select(a | a. oclIsKindOf (Extern)).isEmpty()

CollaborativeActivity
Description This attribute means that the status of this task is monitored by a responsible

Constraint This activity must have a responsible and be attached to an event.

Context CollaborativeActivity inv:
self.isMonitoring implies self.actor.role -> select (r | r.type == RoleType:Responsible)
-> size() >= 1

CollaborativeActivity
Description A multi participant activity is made by several participant of the process
Constraint This activity must have at least one role.
Context CollaborativeActivity inv: self.actor.role-> size() = 1

State of progress
Description It’s a specialization of the ActivityState which specifies that Activity is in progress,
onBreak or completed
Constraint A notification is sent to the activity manager when the activity status changes.

DeadlinedActivity
Description This activity is characterized by : a due date and a frequency of relaunch.
Constraint This activity must have a responsible and be attached to an event.
Context DeadlinedActivity inv:
self.actor.role -> select (r | r.type == RoleType:Responsible) -> size() > =1

Shared Data
Description A type that identifies whether the DataObject is private or can be shared with a third
party, Private DataObject can be seen only by the participant to which it belongs

Constraint It must be associated at least to one external actor and one internal actor
Context CollaborativeData inv:
Self.type=ArtificatType:Shared implies self.actor->select(a |
a.oclIsKindOf(Extern)->size()=1 and self.actor->select(a |
a.oclIsKindOf(Intern)->size()=1
PrivateData
Description A private Data can’t be seen by an external Actor
Constraint A Data is said private if it has no external actor.
Context CollaborativeData inv:
Self.type=ArtificatType:Private implies self.actor->select(a |
a.oclIsKindOf(Extern)->isEmpty()
Document Version

Authorized licensed use limited to: TH Brandenburg. Downloaded on October 22,2022 at 17:17:14 UTC from IEEE Xplore. Restrictions apply.
 Description This attribute specifies the version of the document. A document has at least a first
version.
Constraint It have at least an initial version

Locked
Description It’s a specialization of the DocumentState that means the CollaborativeDocument
cannot be modified.
Constraint Only the person responsible for the document can Locked it.

Validate
Description It’s a specialization of the DocumentState that means the CollaborativeDocument is
validate by a responsible.
Constraint A validated document cannot be modified

to the manager for verification, then to the administration

IV. ILLUSTRATIVE EXAMPLE
We will illustrate the use of our DSL in an example of
document management figure2, this example will not
Fillustrate all the elements of our DSL but just some of them.
The document management process takes place between two
companies "Company A" and "Company B". The process
begins with a request to write a document. The request is
received by the administration, which drafts and then transfers
it to the Manager for approval. If the document is not approve
by the manager, it will be returned to the administration,
otherwise it is sent to the director for signature, then returned
which performs its printing. Finally, the document is sent to
company A to be executed. The modeling by our DSL unlike
the BPMN made it possible to specify several types of data to
be exchanged between the different participants, such us,
specifying if the document has a version, when it’s validate, if
it’s a locked document which allows data security. As for the
"Writing" activity, as it can take time to be completed, it has a
progress state, which allows the manager to monitor the
progress of the task. The “Approval” Activity is a deadline
task, which does not exceed the execution time of the task.

Fig. 2. Modeling of a document management process by our DSL

managers) to the more technical level (developers and

V. CONCLUSION AND FUTURE WORK
In practice, Enterprises need to represent their processes in
the form of models understandable by the whole working
community from the more abstract level (business analysts,
technicians). Thus, the choice of a graph representation
language seems more judicious. Recently, among these
languages, BPMN is emerging as a standard widely used by
companies and supported by many tools. However, BPMN
fails to satisfy some points, which are essential for the

Authorized licensed use limited to: TH Brandenburg. Downloaded on October 22,2022 at 17:17:14 UTC from IEEE Xplore. Restrictions apply.
successful modeling of collaborative work, such as the
exchange of resources, confidentiality, task monitoring,
traceability, and document viewing. Etc. Therefore, our work
consists of creating a DSL that allows the modeling
collaborative work environments. The construction of the
DSL is done according to three stages: the first, being the
metamodelling of our language, it is the abstraction part where
we describe the different types of model elements and how
they are arranged, connected and constrained. It helps to better
understand the concept of language. The second is the
semantics that make sense of our language. The third, being
the concrete syntax of language, which has a graphic
formalism to easily manipulate the concepts of our language.
To make the process models operational, at the
implementation level you must choose an adequate tool to
define these models and then execute them by a process
engine. As in the process-modeling phase, in this phase, the
implementation of these executable models requires
manipulation data. A standard emerges for definition and
implementation is the Business Process Execution Language
(BPEL), which is a target language of BPMN. Therefore, the
goal of our next work will be to make our DSL operational.
Through a written transformation by a set of rules that
describe the transition from the BPMN process model to the
BPEL process model.
REFERENCES
[1] Object Management Group. “Business Process Model and Notation,
version 2.0.2”, 2013.
[2] D. C. Schmidt, « Guest Editor’s Introduction: Model-Driven
Engineering », Computer, vol. 39, no 2, p. 25-31, févr. 2006, doi:
10.1109/MC.2006.58.
[3] Jbpm User Guide.
[4] BonitaSoft. BOS V5.3-User & Reference Guide.Oct 19 2010
[5] BizAgi. Functional Descriptionv9.2009.
Authorized licensed use limited to: TH Brandenburg. Downloaded on October 22,2022 at 17:17:14 UTC from IEEE Xplore. Restrictions apply.
[6] H. Liu, Y. Lembaret, D. Clin, et J.-P. Bourey, « Comparison between
Collaborative Business Process tools », in 2011 FIFTH
INTERNATIONAL CONFERENCE ON RESEARCH CHALLENGES
IN INFORMATION SCIENCE, Gosier, France, mai 2011, p. 1-6, doi:
10.1109/RCIS.2011.6006864.
[7] J. M. Perez, F. Ruiz, et M. Piattini, « MDE for BPM: A Systematic
Review », in Software and Data Technologies, vol. 10, J. Filipe, B.
Shishkov, et M. Helfert, Éd. Berlin, Heidelberg: Springer Berlin
Heidelberg, 2008, p. 127-135.
[8] P. D. Villarr, « A MDA-based Development Process for Collaborative
Business Processes », p. 16.
[9] J. Touzi, F. Benaben, H. Pingaud, et J. P. Lorré, « A model-driven
approach for collaborative service-oriented architecture
design », International Journal of Production Economics, vol. 121,
o
n 1, p. 5-20, sept. 2009, doi: 10.1016/j.ijpe.2008.09.019
[10] Miller, J., Mukerji, J.: MDA Guide Version 1.0.1, OMG (2003)
[11] A. Kalnins, L. Lace, E. Kalnina, et A. Sostaks, « DSL Based Platform
for Business Process Management », in SOFSEM 2014: Theory and
Practice of Computer Science, vol. 8327, V. Geffert, B. Preneel, B.
Rovan, J. Štuller, et A. M. Tjoa, Éd. Cham: Springer International
Publishing, 2014, p. 351-362.
[12] J. Bicevskis, J. Cerina-Berzina, G. Karnitis, L. Lace, I. Medvedis, et S.
Nesterovs, « Domain Specific Business Process Modeling in
Practice », in Proceedings of the 9th International Baltic Conference
on Databases and Information Systems, January 2010, p. 14.
[13] H.Heitkotter and Al. « A Framework for Creating Domain-specific
Process Modeling Languages »:, in Proceedings of the 7th
International Conference on Software Paradigm Trends, Rome, Italy,
2012, p. 127-136, doi: 10.5220/0004024201270136.
[14] F. Yahya, K. boukadi, Z. Maamar, et H. Ben Abdallah, « Enhancing
Business Processes with Web 2.0 Features »:, in Proceedings of the
12th International Conference on e-Business, Colmar, Alsace, France,
2015, p. 183-190, doi: 10.5220/0005526501830190.
[15] L. Amdah et A. Anwar, « BPMN4 Collaboration: An Extension for
collaborative Business Process », Adv. sci. technol. eng. syst. j., vol. 4,
no 6, p. 297-305, 2019, doi: 10.25046/aj040638.
[16] Object Management Group. “Object Constraint Language, version
2.4”, 2014.