A Pattern-based Process Management System to Flexibly Execute

Collaborative Tasks

Mamadou Lakhassane Cisse

1,3

, Hanh Nhi Tran

, Samba Diaw

, Bernard Coulette

and Alassane Bah

IRIT Laboratory, Jean Jaures University, Toulouse, France

IRIT Laboratory, Paul Sabatier University, Toulouse, France

UMMISCO, Cheikh Anta Diop University, Dakar, Senegal

Keywords: Process Management, Process Execution, Multi-instance Task, Collaboration Process Pattern, Late-binding.

Abstract:

Managing collaborations during the execution of a process is complex and challenging, especially for man-

aging the collaboration inside a task having multiple instances performed by various actors. Existing process

management approaches propose either a rigid control for conducting such collaborative tasks or no control

at all. Aiming at a more ﬂexible way to execute and control multi-instance tasks, we investigate a solution

based on late-binding mechanism to allow actors choosing dynamically suitable strategies to perform their

collaboration. First, we propose a process modeling language which focuses on describing multi-instance

tasks and their dynamic instances at execution time. Second, this language is then used to represent patterns

capturing reusable collaboration strategies. A prototype of a pattern-based Process Management System has

been developed to demonstrate the possible ﬂexible execution of collaborative tasks.

1 INTRODUCTION

Collaborative processes have to deal with dynamic

and complicated relationships between participants of

a given project. Thus, they should beneﬁt from pro-

cess management methods and tools which, based on

the information ﬂows described in the process model,

allow coordinating the activities performed by pro-

cess actors at process execution time. Conventionally,

a task is the smallest unit of work in a process sub-

ject to management accountability. Existing process

management systems focus on coordinating process’s

tasks but pay less attention to managing the collabo-

ration of actors inside a given task to achieve a com-

mon goal. In general, there are two usual approaches

to deal with the collaboration inside a task: (1) rep-

resenting the collaborative task only in the process

model but ignoring interactions among actors during

its enactment; (2) reﬁning the inner steps inside the

task concerning actors and describing these sub-tasks

in the process model so that they are manageable dur-

ing process execution. In the ﬁrst case, the collabo-

ration at runtime is not monitored and controlled, in

the second case, the collaboration is controlled but is

rigid and cannot adapt to evolving contexts, for exam-

ple when the number of task’s actors changes.

Many works have been done on designing collab-

oration strategies (Briggs et al., 2006; Kolfschoten

and de Vreede, 2007), on modeling collaborations

(Lonchamp, 1998; Hawryszkiewycz, 2005; Kedji

et al., 2012; Antunes et al., 2013; Gallardo et al.,

2013). However, there have been few studies about

assisting and controlling the execution of collabora-

tive processes, especially to allow the collaboration

to evolve according to the process application context

(Ariouat et al., 2016).

Motivated by this lack when working on model-

ing and execution of collaborative processes (Cisse

et al., 2018), we have been investigating a solution

for executing collaborative tasks in a ﬂexible way. We

are interested in a special form of collaborative tasks,

so-called Multi-Instances Tasks (MIT). At execution

time, a single task is instantiated once and the task in-

stance is performed by an actor playing the required

role. An MIT needs several instances to accomplish

the task’s goal. The relationships among the instances

of an MIT depend on the collaboration strategy used

to realize the task’s goal. In order to enable a ﬁne

control of an MIT’s enactment, these inter-instances

relations must be deﬁned.

As an extension of the work in (Cisse et al., 2018),

this paper presents our proposition to allow executing

ﬂexibly multi-instance tasks. The main steps are: (1)

deﬁning a set of patterns to capture different collab-

Cisse, M., Tran, H., Diaw, S., Coulette, B. and Bah, A.

A Pattern-based Process Management System to Flexibly Execute Collaborative Tasks.

DOI: 10.5220/0007680702730280

In Proceedings of the 14th International Conference on Evaluation of Novel Approaches to Software Engineering (ENASE 2019), pages 273-280

ISBN: 978-989-758-375-9

273

oration strategies that deﬁne typical relations at exe-

cution time among the instances of a multi-instance

task in speciﬁc situations; (2) using the patterns in

(1) to specify ﬂexibly the inter-instances relations of

an MIT at execution time in order to allow actors

adapting their collaboration strategies according to

the project’s context.

The main contribution of this work is the proposal

of the late-binding mechanism to dynamically choose

the execution strategy of a multi-instance task. In or-

der to do so, we have deﬁned a set of collaboration

patterns from which one is chosen at execution to con-

duct a particular strategy in a given project’s context.

A collaboration pattern captures a recurrent col-

laboration strategy that can be used at execution time

to perform a collaborative task in a speciﬁc context

of the application project. A collaboration pattern de-

scribes the typical relationships among the instances

of a collaborative task from two main perspectives:

the control-ﬂow and the data-ﬂow. The control-ﬂow

perspective provides the execution order of task in-

stances, represented by the work-sequence relations

among the instances. The data-ﬂow perspective spec-

iﬁes, via the task parameter relations, the data manip-

ulated, exchanged or shared by the task’s instances.

In contrast to the modeling patterns proposed in (Lon-

champ, 1998), (der Aalst et al., 2003) and (Vo et al.,

2015) that are applied at modeling time for describ-

ing collaboration scenarios, our collaboration patterns

(see Section 2.2) are applied dynamically at execution

time to generate the detailed model of running collab-

orative tasks.

A loosely speciﬁed collaborative task at model-

ing time needs to be completed at execution time to

enable a controlled ﬂexible execution. To do so, we

use the late-binding mechanism to select dynamically

a suitable collaboration pattern and use it as a tem-

plate to generate the inter-instances relations for the

collaborative task. To enable adapting the execution

of a collaborative task to the evolution of a project

context or to change collaboration strategy during the

execution, a collaborative task can be bound to differ-

ent collaboration patterns. Generally, the main factors

that can impact the choice of a collaboration are con-

straints on the availability of resources (humans, time,

tools etc.) or constraints on the order of manipulating

or producing the inputs and outputs. Selecting (semi-)

automatically a suitable pattern is out of scope of this

paper.

Furthermore we have also deﬁned an operational

semantics that enables the application of collabora-

tion patterns to make the execution of collaborative

tasks ﬂexible. Due to space constraint, this semantics

is not presented here.

The paper is structured as follow. Section 2

presents ﬁrst our executable process modeling lan-

guage used to describe collaborative tasks and the re-

lations among their instances at execution time, and

second collaboration patterns for MITs execution. A

prototype implementing our work is described in Sec-

tion 3. We discuss in Section 4 some related works

and summarize in Section 5 our contributions as well

as our perspectives.

2 MODELING COLLABORATIVE

TASKS

To enable a ﬁne-grained control of collaboration dur-

ing process execution, both the structural and behav-

ioral aspects of collaborative tasks must be known.

Aiming at a ﬂexible execution, we deﬁne these as-

pects of a collaborative task in two times: at mod-

eling time, only the task’s structural elements (e.g.

performing role, used artifacts) are described, then

at execution time, when the task is instantiated into

several instances, the relations among the task’s in-

stances (e.g. work-sequences, exchanged-data) will

be speciﬁed according to the used collaboration strat-

egy and in this way reﬂect the task’s behavior. The

challenge for such an approach is how to generate at

execution time the behavioral model of a collabora-

tive task without requiring process actors to go back

to the modeling phase.

Dealing with this issue, ﬁrst in Section 2.1 we pro-

pose the Executable Collaborative Process Modeling

Language (ECPML) which is composed of two pack-

ages allowing to represent the process elements at

modeling time (ECPML Core ) and their dynamic in-

stances at execution time (ECPML Execution). Then

in Section 2.2 we propose a catalog of collaboration

patterns that can be bound dynamically to a collab-

orative task instance at execution time to deﬁne its

behavior.

2.1 Executable Collaborative Process

Modeling Language

Figure 1 shows an extract of the meta-model

of our Executable Collaborative Process Model-

ing Language (ECPML). This language is in-

spired from SPEM (OMG, 2008) for the ele-

ments of ECPML Core. The concepts represent-

ing ECPML

Execution were deﬁned by ourselves be-

cause SPEM does not provide elements concerning

process execution.

The Figure 1a deﬁnes the process elements and

ENASE 2019 - 14th International Conference on Evaluation of Novel Approaches to Software Engineering

274

Figure 1: Extract of the meta-model deﬁning the ECPML. ”instance of” dependency abstracts the instantiation links between

concepts of ECPML Core and ECPML Execution.

the relations among them. Our main focus in this

paper is the Task concept representing a manageable

unit of work. A Role is an abstract entity represent-

ing some qualiﬁcations. The relation TaskPerformer

allows to specify a speciﬁc role required to perform

a given task. WorkProduct represents concrete, tan-

gible entities used or produced during the execution

of a task via the relation TaskParameter. The rela-

tion WorkSequence between two tasks represents the

constraint on the orders to execute the tasks. Our lan-

guage distinguishes two types of task: a SingleTask

which has only one instance at execution time and a

CollaborativeTask which can have several instances

at execution time.

The Figure 1b deﬁnes the concepts used to repre-

sent the execution of a process, i.e. the dynamic in-

stances created at execution time from the elements

deﬁned at modeling time in a process model. The

relation instance of represents the mapping between

the two packages of the meta-model. As an example

we can say: a Task at modeling time is instantiated

at execution time into one or many TaskInstances; a

WorkProduct at modeling time is instantiated at exe-

cution time into one or many WorkProductInstances.

A Role is played by one or many Actors at execu-

tion time. The relations between the instances are the

same as those deﬁned between their modeling con-

cepts. Concretely, a TaskInstance can have TaskIn-

stanceParameter relations with the WorkProductIn-

stances that it uses or produces, a TaskInstance has

a TaskInstancePerformer relation with the Actor who

enacts it and a TaskInstance can have TaskInstanceSe-

quence relations with other task instances to specify

their execution orders.

Focusing on controlling the execution of an MIT

performed by several actors, we distinguish Single-

TaskInstance (STI), which is an instance of Single-

Task, and CollaborativeTaskInstance (CTI), which is

an instance of CollaborativeTask. An STI is the

main executable element representing a unit of work

assignable to a single actor. A CTI is composed of

several STIs performed by separate actors.

We present in Figure 2 the example Writing pro-

cess modeled in ECPML. It contains two single tasks

WriteDocument and ReviseDocument, each one being

performed by one actor playing the role Author, and

a collaborative task ReviewDocument which is per-

formed by several actors playing the role Reviewer.

Manuscript and Assessment represent the in and out

WorkProduct of the tasks.

Figure 2: Model of the Writing process in ECPML at mod-

eling time.

Controlling the execution of a process is essen-

tially coordinating the execution of different STIs. To

do so, the TaskInstanceSequence relations among the

TaskInstances must be known. However, only those

specifying the relations among the instance of differ-

ent tasks are deﬁned in the process model and thus

known at modeling time. For example, from the pro-

A Pattern-based Process Management System to Flexibly Execute Collaborative Tasks

275

cess model in Fig. 2, we can know only the work-

sequences FS (i.e. Finish2Start) between the Write-

Document and the ReviewDocument, between the Re-

viewDocument and the ReviseDocument. However,

the relations among multiple instances of a collab-

orative task, i.e. among the STIs inside a CTI as

among the STIs of the ReviewDocument CTI, are not

described in the process model and need to be estab-

lished at execution time.

The inter-instances relations among the STIs of a

CTI are dependent on the collaboration strategy used

to carry out the task. In our approach, we use collabo-

ration patterns to capture such strategies and to reuse

these patterns as templates to deﬁne the relations be-

tween the STIs inside a CTI. The following section

presents how ECPML can be used to model collabo-

ration patterns and shows two representative patterns.

2.2 Patterns for Multi-instances Task

Execution

We have identiﬁed several patterns based on the way

the manipulated artifacts are shared. In this paper,

we consider only how the output artifacts that are

changed by the collaborative task are shared among

its instances. The input artifacts are implicitly con-

sidered as ”read-only” items shared by the instances

inside the collaborative task and are not shown in the

patterns.

Using our own template, a pattern is presented

with its name, description, problematic, context of

use, and a solution described in ECPML. Presenting

the exhaustive list of these patterns is out of scope of

this paper. In the following, we present 2 representa-

tive patterns corresponding to the two main types of

execution: in parallel and in sequence.

2.2.1 Pattern Parallel Instances with Composite

Out Parameter

Name: PAR-INSTANCES-COP

Problematic: need to realize a quick production of a

composite artifact made of independent parts

Context: This pattern serves to manipulate a com-

posite artifact regardless of the order of production

for the different parts. It means that those parts must

be independent. It can be used when all the resources

needed for the enactment of the collaborative task are

available.

Description: Given a collaborative task T having one

output parameter P composed of n independent com-

ponents P

, this pattern is used to execute a set of n

single task instances t

inside the collaborative task in-

stance of T simultaneously. Each task instance t

will

manipulate separately an instance p

of the compo-

nent P

. The different task instances can be executed

at any time as there is no sequencing between them.

They should be executed in parallel to minimize the

execution time.

Solution: Figure 3 shows the models of PAR-

INSTANCES-COP pattern respectively at modeling

time, and at execution time with 2 task instances of

the collaborative task T .

Figure 3: Pattern PAR-INSTANCES-COP for a collabora-

tive task T.

2.2.2 Pattern Sequential Instances with

Composite out Parameter

Name: SEQ-INSTANCES-COP

Problematic: need for a progressive production of a

composite artifact made of dependent parts.

Context: This pattern serves to manipulate different

components of a composite artifact in a sequential

order determined by the dependencies among them.

This can happen when we need to divide the work on

the production of the composite artifact among sev-

eral actors according to their availability.

Description: Given a collaborative task T having one

output P which is composed of n dependent compo-

nents P

, i ∈ [1, n], this pattern is used to execute a se-

ries of n consecutive single task instances t

, i ∈ [1, n]

inside the collaborative task instance of T . Each task

instance t

manipulating an instance p

of the com-

ponent P

and is performed by a different actor play-

ing the same role. The execution order FS among the

task instances is imposed by the dependencies deﬁned

among the components of P: the creation of P

+ 1

needs the completion of P

thus t

+ 1 (which works

on P

+ 1) has to follow t

(which produces P

). The

value of n can be given when the collaborative task is

deployed.

ENASE 2019 - 14th International Conference on Evaluation of Novel Approaches to Software Engineering

276

Solution: Figure 4 shows the models of SEQ-

INSTANCES-COP pattern respectively at modeling

time, and at execution time with 2 task instances of

the collaborative task T .

Figure 4: Pattern SEQ-INSTANCES-COP for a collabora-

tive task T.

As a dynamic entity, a TaskInstance has a lifecy-

cle composed of different states through which it goes

when executed. To allow deploying and executing

a multi-instance task, we need to deﬁne the task in-

stance’s lifecycle, its operational semantics. As men-

tioned above, the semantics of the behavior of the pro-

cess engine is out of scope of this paper.

Figure 5 describes the application of the pattern

SEQ-INSTANCES-COP presented in Figure 4 to de-

scribe the behavior of the collaborative task Review.

Notice that the resulting Review document is com-

posed of Alice Assessment and Bob Assessment.

Figure 5: Application of SEQ-INSTANCES-COP to deﬁne

the relations among the task Review’s instances.

3 IMPLEMENTATION OF A

PROTOTYPE

As a proof of concept, we have developed the proto-

type CPE (Collaborative Process Engine), a process

management system supporting ﬂexible execution of

multi-instance tasks so that users can choose, at enact-

ment time, appropriate collaboration strategies corre-

sponding to their organizational model. Figure 6 be-

low describes the general architecture of CPE.

Figure 6: General architecture of CPE.

CPE has two main components:

• Process Editor allows process designers using

ECPML to model processes and collaboration

patterns then store them into Process Model

Repository and Patterns Catalog.

• Process Engine supports process actors perform-

ing their process, i.e. instantiating the tasks de-

ﬁned in their process model and managing the ex-

ecution of these tasks. Process actors choose a

process model in Process Models Repository to

execute and the process engine will generate the

dynamic instances of the process’s elements and

store them in the Instances Store. At execution

time, the process engine updates the process’s in-

stances, by using the operational semantics, to

evolve the process. To deploy a collaborative task,

the number of instances for each task can be given

by the project manager or imposed by the orga-

nizational model of the project. Then according

to the project characteristics, the project manager

chooses the most suitable collaboration pattern to

the project’s context, among those of the Patterns

Catalog, for executing each collaborative task.

The physical artifacts and human resources ma-

nipulated during the process execution are managed

by external Databases: Artifacts Management System

for artifacts and Resources Management System for

actors. These databases are connected to CPE which

manages just the references of artifacts and actors in-

side its InstancesStore.

Figure 7 shows a screenshot of the execution of

our motivating example in the prototype. In this step,

the manager chooses the most suitable pattern to de-

ploy the collaborative task Review. Given that all the

actors are available at the same time and the different

A Pattern-based Process Management System to Flexibly Execute Collaborative Tasks

277

document’s parts to be reviewed are independent, he

has chosen the pattern Parallel Instances Composite

Out Parameter.

Figure 7: Screenshot of the CPE prototype.

Thanks to CPE, the project manager can monitor

the execution of collaborative tasks and adapt the col-

laboration strategy for conducting collaborative tasks

at any moment according to the alteration of project’s

constraints and needs. CPE provides process actors

with not only the necessary functionalities to perform

their task (by verifying the condition to create, start,

end or assign resources to a task instance) but also a

global and real-time view on the progress of develop-

ment tasks (by showing the information about the col-

laborative task that he participates in: what is the cur-

rent state, who are other actors performing the task,

what are exchanged data, etc.).

Although CPE is helpful for all kinds of processes

which have multi-instance tasks, it can beneﬁt partic-

ularly system and software processes which are of-

ten performed by several teams to produce different

parts of the ﬁnal product. Moreover, generally sys-

tem and software processes’ projects have changing

contexts because of the evolution of product’s speci-

ﬁcation as well as the evolution of production’s con-

straints. The above characteristics make system and

software processes require more assistance and con-

trol during their execution - what is offered by our

CPE.

4 RELATED WORKS

There are some works (Hawryszkiewycz, 2005; Kedji

et al., 2012; Antunes et al., 2013; Gallardo et al.,

2013) addressing the modeling of a collaborative pro-

cess. Mostly they proposed constructs to model ac-

tivities that need to be coordinated during the process

execution but did not deal with the management of

collaborative tasks during execution.

Process patterns have been used to describe a set

of activities realized to solve common problem in a

software development lifecycle or in a business pro-

cess. The works in (Lonchamp, 1998; A. de Moor,

2006; Verginadis et al., 2010) proposed patterns cap-

turing best practices about organizing collaborative

activities. The mentioned works also focused only on

representing collaborative strategies at modeling-time

contrarily to our approach which studies the applica-

tion of collaborative strategies.

The work of (der Aalst et al., 2003) proposed a

series of workﬂow patterns representing typical solu-

tion for modeling and implementing processes. Their

work is used principally for evaluating the expressive-

ness of process modeling languages and the support-

ing capacity of process management systems. In con-

trast to us, they did not provide a formalized solution

to integrate the proposed patterns into a process sys-

tem.

Few works on multi-instance tasks have also been

investigated in the literature. In (Atwood, 2006), the

author proposed a way to represent loop of tasks or in-

dependent tasks. However, it focuses only on control-

ﬂow between instances but ignores data-ﬂow. (Sun

et al., 2006) also introduced patterns for multiple in-

stances activities. They dealt with the ﬂexible exe-

cution by allowing a workﬂow management system

to perform an activity several times, not like us who

proposes deﬁning the behavior of the system at ex-

ecution time. Although (der Aalst et al., 2003) pre-

sented some workﬂow patterns concerning the imple-

mentation of multi-instance tasks, it does not address

the question of using dynamically patterns to support

a ﬂexible execution of collaborative as done in our

work.

The ﬂexibility of process execution is an impor-

tant challenge of the process community. One ap-

proach to handle this is allowing deviations inside

process environments i.e., detecting, tolerating and

managing deviations, as done in (da Silva et al., 2011;

Smatti and Nacer, 2014). Another approach is al-

lowing late-modeling or late-binding, i.e. the abil-

ity to deal with unpredictable situations by allowing

the process model to be partially unknown at design-

time and reﬁned at run-time. As for (Dustdar, 2004),

they proposed a process-aware CSCW system sup-

porting process schemas that are created on-the-ﬂy.

In (Charoy et al., 2006), authors introduced a Work-

ﬂow management system allowing users to modify

the instance of a process, such as adding an activity.

It has been taken into account in the development of

the Bonita workﬂow management system. Compared

to the cited works, we also adopt the late-binding ap-

proach, but propose to use dynamically patterns to pa-

rameterize the behavior of the process engine and thus

make it ﬂexible.

ENASE 2019 - 14th International Conference on Evaluation of Novel Approaches to Software Engineering

278

In (Tran et al., 2011), the authors deﬁned pat-

terns for modeling process and a mechanism for ap-

plying patterns to refactoring process models. This

work does not tackle collaborative tasks. (Vo et al.,

2015) proposed also an approach to deﬁne and apply

collaboration patterns for software development mod-

eling. Compared to these pattern-based approaches,

our work allows dynamical application of patterns for

adapting the behavior of a running process at execu-

tion time.

5 CONCLUSION

Our current research focuses on the ﬂexible manage-

ment of collaborative processes. Our work targets

the modeling and execution of collaborative tasks.

The work presented in this paper considers in partic-

ular multi-instance tasks which are instantiated sev-

eral times at execution and performed by different ac-

tors but all collaborating to produce a common result.

The objective of this work was providing a solution

to model partially multi-instance tasks and then us-

ing the late-biding mechanism to complete the tasks

behavior ﬂexibly at execution time.

The main contribution of our work is the language

ECPML used to model collaborative process, both

structural and behavioral aspects, at modeling and ex-

ecution time. We have used ECPML to model a set of

collaboration patterns describing the typical behavior

models of multi-instance tasks. These patterns can be

bound to the structural model of a collaborative task

to complete the task information and thus allow man-

aging collaborative tasks. The execution of the col-

laboration is assisted by our prototype process man-

agement system CPE.

To improve the validation of our approach, we

need to apply it to other case studies and especially to

real projects. Indeed, it is always better to work with

real project data, but our objective is mostly to test

the set of collaboration strategies at execution time.

Adding new collaboration patterns is also desirable

but the limited set of collaboration patterns imple-

mented, so far, does not question the validity of our

approach. The proposition of more patterns, which is

one of our perspective, will not put at risk the scala-

bility of our approach since the search function com-

plexity of a suitable pattern is linear.

We aim also supporting more complex collabo-

rative task behaviors. Currently, we only deal with

patterns describing one kind of work-sequence rela-

tions among the single tasks instances of a collab-

orative task (for example Finish2Start). However,

sometimes in practice there are several kinds of inter-

instances relations inside a task. To support more

complex collaborations, we intend to investigate the

proposition of new patterns covering those situations.

We explore also the capacity of combining dynami-

cally collaboration patterns at execution time.

One of our perspective also is to investigate the

possibility of allowing a single task instance inside a

collaborative task instance to become itself a collab-

orative task instance during enactment. Indeed, it is

needed sometimes to allow a task to be reﬁned into

several instances due to constraints (such as emer-

gency for a faster execution).

REFERENCES

A. de Moor, A. (2006). Community memory activation with

collaboration patterns. In 3rd Prato Community Infor-

matics Research Network Conference (CIRN 2006),

pages 1–18, Prato, Italy.

Antunes, P., Herskovic, V., Ochoa, S. F., and Pino,

J. A. (2013). Modeling highly collaborative pro-

cesses. In 2013 IEEE 17th International Conference

on Computer Supported Cooperative Work in Design,

CSCWD 2013, number July 2014, pages 184–189.

Ariouat, H., Andonoff, E., and Hanachi, C. (2016). Do

process-based systems support emergent, collabora-

tive and ﬂexible processes? comparative analysis of

current systems. Procedia Computer Science, 96:511–

520.

Atwood, D. (2006). Bpm process patterns: Repeatable de-

sign for bpm process models. BPTrends, pages 1–20.

Briggs, R., Kolfschoten, G., and de Vreede, G. J. (2006).

Deﬁning key concepts for collaboration engineering.

Association for Information Systems, 12th Americas

Conference On Information Systems, AMCIS 2006,

1:117–124.

Charoy, F., Guabtni, A., and Faura, M. (2006). A dynamic

workﬂow management system for coordination of co-

operative activities. Proceedings of the Business Pro-

cess Management Workshop, pages 205–216.

Cisse, M., Tran, H., Diaw, S., Coulette, B., and Bah, A.

(2018). Collaborative processes management: from

modeling to enacting. In 2018 IEEE 22nd Interna-

tional Conference on Computer Supported Coopera-

tive Work in Design (CSCWD), pages 461–466. IEEE.

da Silva, M., Blanc, X., and Bendraou, R. (2011). Devia-

tion management during process execution. In 2011

26th IEEE/ACM International Conference on Auto-

mated Software Engineering, pages 528–531. IEEE

Computer Society.

der Aalst, W. M. V., Hofstede, A. H. T., Kiepuszewski, B.,

and Barros, A. P. (2003). Workﬂow patterns.

Dustdar, S. (2004). Caramba—a process-aware collab-

oration system supporting ad hoc and collaborative

processes in virtual teams. Distributed and parallel

databases, 15(1):45–66.

A Pattern-based Process Management System to Flexibly Execute Collaborative Tasks

279

Gallardo, J., Bravo, C., Redondo, M. A., and Lara, J. D.

(2013). Modeling collaboration protocols for col-

laborative modeling tools: Experiences and applica-

tions. Journal of Visual Languages and Computing,

24(1):10–23.

Hawryszkiewycz, I. T. (2005). A metamodel for modeling

collaborative systems. Journal of Computer Informa-

tion Systems, 45(3):63–72.

Kedji, K. A., Lbath, R., Coulette, B., Nassar, M., Baresse,

L., and Racaru, F. (2012). Supporting collaborative

development using process models: An integration-

focused approach. In 2012 International Conference

on Software and System Process (ICSSP), pages 120–

129, Zurich, Switzerland. IEEE.

Kolfschoten, G. and de Vreede, G. (2007). The collabora-

tion engineering approach for designing collaboration

processes. In Springer, editor, International Confer-

ence on Collaboration and Technology, volume 4715,

pages 95–110, Berlin.

Lonchamp, J. (1998). Process model patterns for col-

laborative work. In 15th IFIP World Computer

Congress, Telecooperation Conference, Telecoop’98,

Vienna, Austria.

OMG (2008). Software & systems process engineering

meta-model speciﬁcation v2.0. (April):236.

Smatti, M. and Nacer, M. (2014). Dealing with deviations

on software process enactment: Comparison frame-

work. In ICAASE, pages 108–115.

Sun, R., Liu, G., and Shi, M. (2006). The speciﬁcation of

workﬂow activity multiple instances. In 10th Interna-

tional Conference on Computer Supported Coopera-

tive Work in Design, CSCWD 2006, pages 1179–1183,

Nanjing, China. IEEE.

Tran, H., Coulette, B., Tran, D., and Vu, M. (2011). Au-

tomatic reuse of process patterns in process model-

ing. In 2011 ACM Symposium on Applied Computing

(SAC), TaiChung, Taiwan, March 21 - 24, 2011, pages

1431–1438.

Verginadis, Y., Papageorgiou, N., Apostolou, D., and

Mentzas, G. (2010). A review of patterns in collab-

orative work. In ACM, editor, GROUP ’10 Proceed-

ings of the 16th ACM international conference on Sup-

porting group work, pages 283–292, Sanibel Island,

Florida, USA. ACM.

Vo, T. T., Coulette, B., Tran, H. N., and Lbath, R. (2015).

An approach to deﬁne and apply collaboration process

patterns for software development. In Model-Driven

Engineering and Software Development - Third Inter-

national Conference, MODELSWARD 2015, Angers,

France, February 9-11, 2015, Revised Selected Pa-

pers, pages 248–262.

ENASE 2019 - 14th International Conference on Evaluation of Novel Approaches to Software Engineering

280