Process Lines for Automatic Workﬂow Development

Mario L. Bernardi

, Marta Cimitile

and Fabrizio M. Maggi

University of Sannio, Benevento, Italy

Unitelma Sapienza University, Roma, Italy

University of Tartu, Tartu, Estonia

Keywords:

Workﬂow Development, SOA, Business Process Lines.

Abstract:

In some business environments, processes of different organizations are very similar to each other. This

produces families of processes with common characteristics but also portions that vary according to the speciﬁc

organization. Two emerging approaches can be adopted and combined to easily model, implement and update

families of business processes: Software Product Line (SPL) and Service-Oriented Architecture (SOA). Our

work suggests a framework to transfer the main peculiarities of the SPL to the SOA system development, in

order to realize a SOA system line. Starting from the SPL concept, we introduce process lines, i.e., families

of process models suitable for different customers or market segments. Moreover, we present an approach

for the automatic generation of a SOA system starting from a process model. The combination of these

approaches, can be used to easily develop a family of SOA systems each one appropriate for different context

characteristics. In this work, an application of the proposed approach in a real project is also proposed.

1 INTRODUCTION

Often, organizations working in the same business en-

vironment execute their business processes in simi-

lar but slightly different manners (Mohammadi and

Mukhtar, 2011). To provide them with appropriate

workﬂow systems, it is necessary to tailor these sys-

tems according to different context factors (objec-

tives, technologies, industrial standards, quality pro-

grams, budget, workers, tools, cultural factors). For

this reason, it is necessary to deﬁne new approaches

aiming at reducing the effort in modeling, updating

and implementing a family of similar processes each

one suitable to be used in a speciﬁc context. We pro-

pose an approach based on process lines and Service

Oriented Architectures (SOA) supporting the reuse of

process model components, the generation of process

models based on combinations of such components

(suitable for different contexts) and their rapid im-

plementation into workﬂow systems. This proposal

comes up from the following considerations:

• the concept of Software Product Line (SPL) is

based on the idea that enterprises can imple-

ment software systems for different customers

reusing software resources rather than developing

the same software capabilities again. This concept

can be extended to processes for modeling them

in the perspective of process reuse and ﬂexibility

(Bernardi et al., 2012a).

• SOA offers a mature platform to rapidly imple-

ment a process model in pace with speciﬁc busi-

ness needs (Welke et al., 2011).

The proposed approach consists of 2 phases: Pro-

cess Variant Deﬁnition (PVD) and Automatic Work-

ﬂow Development (AWD). The PVD phase is based

on the concept of process line, which is, in turn, de-

rived from the one of SPL. Through a process line, it

is possible, starting from a basic process model, to de-

ﬁne a process variant based on the customization and

the adaptation of the basic process model according

to different customer needs. We use BPMN (Business

Process Modeling Notation) (Dijkman et al., 2011) to

deﬁne the process models in a process line.

In the AWD phase, we transform a process vari-

ant into an executable SOA system through successive

transformations aimed at making the process model

understandable by an execution engine. In particu-

lar, we introduce an approach for transforming BPMN

process models to BPEL (Business Process Execution

Language) (Zhao et al., 2010).

Starting from a process line, it is possible, there-

fore, to automatically generate a SOA system line that

automates the underlying process models. So, a pro-

cess model can be customized using a process line and

Bernardi M., Cimitile M. and Maggi F..

Process Lines for Automatic Workﬂow Development.

DOI: 10.5220/0004492400410049

In Proceedings of the 8th International Joint Conference on Software Technologies (ICSOFT-EA-2013), pages 41-49

ISBN: 978-989-8565-68-6

 2013 SCITEPRESS (Science and Technology Publications, Lda.)

the SOA system generated from it will be, in turn, cus-

tomized. Also, if the underlying process line changes,

it becomes straightforward to adapt the SOA system

line accordingly. Finally, since a SOA system will re-

sult from the automatic translation of a process model,

it will be in line with the underlying model without

misalignment between models and their implementa-

tion.

The remainder of the paper is structured as fol-

lows: section 2 presents some related work; section

3 gives the overview of the proposed approach; sec-

tion 4 illustrates the application of the approach in a

research project; section 5 completes the paper pro-

viding some conclusive insights and ﬁnal remarks.

2 RELATED WORK

The proposed approach is mainly based on the ap-

plication of SPL principles to the business process

domain and their integration with a workﬂow devel-

opment method for business process implementation.

The adoption of SPL in the context of process mod-

els was introduced in (Bernardi et al., 2012a) and can

also be found in (Gimenes et al., 2008; Rolland and

Nurcan, 2010). For example, in (Rolland and Nur-

can, 2010) the authors propose to organize business

processes as business process families and to manage

variability and commonalities within the family in or-

der to promote reuse and adaptability of business pro-

cess models. To capture variability across the busi-

ness processes of a family in an intentional manner, a

modeling formalism is used.

A method that enables business managers to cre-

ate and edit business rules is presented in (Auechaikul

and Vatanawood, 2007). This approach allows the

user to construct decision tables as a guideline and to

expose them as web services. Similarly, in (Costello

and Molloy, 2004), an approach decoupling business

logic encoded as business rules from the applications

in an organization is proposed.

Our approach to workﬂow development is based

on a reﬁnement of the algorithm ﬁrst presented in

(Ouyang et al., 2006; Ouyang et al., 2007). Here a

mapping of BPMN process models to BPEL is in-

troduced. Based on this algorithm, a process vari-

ant derived from a process line (according to a given

context proﬁle) can be translated into an executable

workﬂow. We deﬁne a mapping between BPMN arti-

facts and BPEL variables and between BPMN activi-

ties and the web services to be orchestrated (including

user interfaces to execute human tasks). Then, based

on the algorithm presented in (Ouyang et al., 2006;

Ouyang et al., 2007), we translate well-structured

BPMN components into standard BPEL constructs

and BPMN components that are not well-structured

into control links and BPEL handlers.

3 PROPOSED APPROACH

The proposed approach consists of two main phases:

Process Variant Deﬁnition (PVD) and Automatic

Workﬂow Development (AWD). In the ﬁrst phase,

starting from a process line and from speciﬁc cus-

tomer needs, a process variant is identiﬁed. In the

second phase, the process variant is automated and

transformed into a SOA system. These phases, shown

in Figure 1, are detailed in the following subsections.

Figure 1: Proposed Approach.

3.1 Process Variant Deﬁnition

The PVD phase is focused on the concept of process

line. Process lines realize the idea that Software Prod-

uct Line principles can be transferred to the business

process ﬁeld. In (Schnieders and Puhlmann, 2006),

(Bayer et al., 2006), a process line is deﬁned as a

set of similar process models sharing invariant assets

and variant assets. The ﬁrst formalization of a pro-

cess line through a decision table is proposed in (Bof-

foli et al., 2009). In this work, the authors deﬁned

a process asset as an atomic reusable part of a pro-

cess model including one or more activities with their

inputs/outputs. A process variant is composed of in-

variant and variant assets integrated to obtain a pro-

cess model suitable for a given context. Variant as-

sets are selected to be included in a process variant

depending on the speciﬁc context where the process

ICSOFT2013-8thInternationalJointConferenceonSoftwareTechnologies

will be executed whereas invariant assets are always

included in every process variant independently of the

speciﬁc context proﬁle.

The Process Variant Deﬁnition can be done

through the following steps:

Process Line Selection: A process line is selected

basing on the type of the process to model. Some

examples of process lines can be: Selling, Procure-

ment, Marketing, Human Resource Management, Fi-

nancial Management, Shipping. For each one of these

processes, some invariant and variant assets can be

deﬁned. For example, an invariant asset for Selling

is activity Obtain order and all the inputs/outputs re-

lated to it.

Variant Assets Deﬁnition: When a process line is se-

lected, invariant assets and all candidate variant as-

sets are speciﬁed. To extract a process variant from

the process line, the suitable variant assets must be

selected on the basis of the speciﬁc customer needs.

For example, if we are interested in the process vari-

ant Sell Product in electronic store with auction we

will use the process line Selling and we will select

(among the others) the variant asset Auction and its

related inputs/outputs.

Process Assets Specialization: Process assets (vari-

ant or invariant) are also specialized basing on the

context. The specialization aims at specifying the be-

havior of each process asset through specialization ac-

tions. A specialization action can consist of the addi-

tion of input/output artifacts to an activity, the special-

ization of an artifact name, the specialization of an ac-

tivity name, the addition of an attribute to an artifact

(e.g., size, compilation guidelines, quality standards

etc.), the addition of an attribute to an activity (e.g.,

required skills, tools, hardware or software resources

etc.). For example, if we want to specialize Selling

into Sell Product in electronic store we specialize ac-

tivity Obtain order in Obtain order in electronic store.

Assets Integration: The process assets selected and

specialized must be integrated into a process vari-

ant. This integration is obtained relating the activities

through their inputs and outputs.

More formally, the Process Variant Deﬁnition can

be described as a function associating to a speciﬁc

context proﬁle the corresponding process variant in

the process line:

f : CP → S (1)

CP is the set of all the possible context proﬁles. cp

is an element of CP and is represented as a vector

of diversity factors in DF

with i = 1, . . . , r. Each

is a factor characterizing a particular aspect of

the environment and has a deﬁnition domain [DF

] =

d f

, d f

, . . . , d f

, where each d f

i j

with j = 1, . . . , q

is an instance of DF

. Therefore, CP = [DF

] ×

[DF

] × . . . × [DF

]. S is the set of all the possible

process variants of the considered process line. f can

be detailed in this way:

f (cp) = φ(ρ(cp, K), ρ(cp, χ(cp))) (2)

If A is the set of all the process assets associated to

the process line, in (2):

• K = {ia

, ia

, . . . , ia

} ⊆ A is the set of invariant

assets;

• χ : CP → A − K is the function associating to

each ﬁxed cp in CP the set of variant assets

{va

, va

, . . . , va

} ⊆ A− K according to the ﬁxed

context cp. A − K is the set of the candidate vari-

ant assets associated to the process line;

• ρ is the function associating to a set of assets

another set of assets specialized according to the

ﬁxed context proﬁle through specializing actions.

In particular, ρ(cp, {asset

, asset

...asset

}) =

{ρ

(cp, asset

), ρ

(cp, asset

), . . . , ρ

(cp, asset

)},

where ρ

, ρ

, . . . , ρ

are transformations special-

izing respectively assets asset

, asset

, . . . , asset

according to the context proﬁle cp.

• φ includes the integration rules useful to compose

the assets.

3.1.1 Asset Selection and Specialization

The process line logic model can be implemented

through a decision table system (Hong et al., 1999).

A decision table is a tabular representation of a proce-

dural decision situation, where the state of a number

of conditions determines the execution of a set of ac-

tions. In general, a decision table is a table divided in

four quadrants: conditions, conditional states, actions

and rules. The table is deﬁned so that each combina-

tion of conditions and conditional states corresponds

to a set of actions to be executed. We need two types

of tables for deﬁning the process line logic model, one

for Variant Asset Selection and another for Asset Spe-

cialization.

A Variant Asset Selection Table is structured as

follows:

CONDITIONS. The quadrant contains the diver-

sity factors DF

with i = 1, . . . , r driving the variant

assets selection. They are all the factors characteriz-

ing a given context.

CONDITIONAL STATES. The quadrant contains the

possible values for each diversity factor: [DF

] =

d f

, d f

, . . . , d f

ACTIONS. The quadrant contains all the candidate

variant assets (va) that can be selected to deﬁne a pro-

cess variant.

ProcessLinesforAutomaticWorkflowDevelopment

RULES. The quadrant identiﬁes the relationships be-

tween each context proﬁle and the variant assets to

realize the corresponding process variant.

An Asset Specialization Table allows us to spe-

cialize a process asset (variant or invariant) on the ba-

sis of a speciﬁed context proﬁle, by executing a set

of specializing actions. This decision table is differ-

ent from the Variant Asset Selection table only for the

actions and the rules quadrants. The actions quad-

rant contains the specialization actions (sa) used to

specialize the asset according to the speciﬁed context

proﬁle. The rules quadrant identiﬁes the relationships

between each context proﬁle and the specialization

actions to be applied. A Variant Asset Selection Table

and an Asset Specialization Table are shown in Figure

3.2 Automatic Workﬂow Development

The AWD phase allows a process model deﬁned in

BPMN to be translated into a BPEL workﬂow. BPMN

models are well versed for communication between

domain experts. These models can be understood by

both business users and developers and they are often

given as requirement speciﬁcations for software de-

velopment projects. To implement a BPMN model it

is necessary to translate it in a language for process

execution like BPEL. BPEL derives from the exten-

sion of imperative programming languages with con-

structs characteristic of service orientation and also

deﬁnes a concrete engine for executing business pro-

cesses. Even if BPMN and BPEL share several con-

structs there is no simple one-to-one mapping be-

tween them. Indeed, there are several constructs and

components in BPMN diagrams that could not be eas-

ily translated to BPEL. Here, we adopt an extension

of the automatic approach for mapping BPMN pro-

cess graphs to BPEL processes described in (Ouyang

et al., 2006).

The ﬁnal outcome of the AWD phase is a BPEL

application realizing the integration of the web ser-

vices provided by all the parties involved. The Au-

tomatic Workﬂow Development can be done through

the following steps:

• Process model speciﬁcation: Due to the gap ex-

isting between a process modeling language and

a process execution language, the original process

model must be translated into a detailed process

model including all the information needed for its

implementation.

• BPEL generation: The detailed process model is

automatically translated into an executable BPEL

process.

3.2.1 Process Model Enrichment

The translation of a BPMN process model into an ex-

ecutable BPEL process is possible by deﬁning a map-

ping between BPMN and BPEL entities. In partic-

ular, we enrich the abstract model with few imple-

mentation details, thus generating a detailed BPMN

model. BPMN activities can be translated to web ser-

vices or human tasks depending on their properties.

In particular, system-side activities that do not need

interactions with human actors can be translated to

web services. If a web service implementing an ac-

tivity is already available, the detailed BPMN model

will associate the activity to the corresponding WSDL

URL. Conversely, if for some activities a web service

is not available, the detailed BPMN model will asso-

ciate them to a skeleton java class. Activities requir-

ing data and the interaction with at least a (human)

system user will be mapped to adequate human tasks.

For the implementation of the user interfaces we use

the BPEL extension BPEL4People (Kloppmann et al.,

2005).

We map a BPMN artifact to a BPEL variable

whose name corresponds to the artifact label. More-

over, the variable type should match the structure of

the class which represents the artifact. However, in-

formation contained in the class deﬁnition is not al-

ways sufﬁcient to automatically translate the class

into a BPEL type. Consequently the detailed BPMN

model must also provide a mapping between each

class in the abstract process model and the corre-

sponding BPEL types in the executable process. A

BPEL type can be simple, or complex (equivalent to

Java data structures deﬁned as a combination of one or

more simple or complex types). The detailed model

will include the (simple or complex) BPEL type cor-

responding to each (simple or complex) artifact in

the abstract model. For instance, in the Selling pro-

cess the artifact Order can correspond to the Java data

structure:

public class Order {

public int sellerID;

public int buyerID;

public int productID;

public int quantity;

public float price;

}

Note that, when an activity is implemented using a

web service, the corresponding WSDL ﬁle is already

provided with the BPEL types associated to the web

service input/output variables. In this case, the de-

tailed BPMN model should only contain the mapping

between the input/output artifacts of the BPMN activ-

ity and the (existing) BPEL types extracted from the

speciﬁed WSDL ﬁle.

ICSOFT2013-8thInternationalJointConferenceonSoftwareTechnologies

Figure 2: Asset Selection (left) and Specialization (right) Table.

</sequence>

</complexType>

Figure 3: XML Code Translation.

3.2.2 BPEL Generation

If a detailed BPMN model is built including the in-

formation mentioned above, an automatic translation

algorithm is able to automatically generate a BPEL

application implementing the underlying model. We

ﬁrst execute a pre-processing phase to import into the

generated BPEL workﬂow the complex types needed

for its execution. Complex types are imported from

the existing WSDL ﬁles implementing the different

activities of the business process. Complex types

which cannot be extracted from the available WSDL

ﬁles must be created using the information contained

in the detailed BPMN model. For instance, the above

Order type is translated into the code of Figure 3.

A recursive algorithm has been implemented to

deal with nested complex types. After the pre-

processing phase, we start the translation of the entire

BPMN (detailed) model. The adopted algorithm is

introduced and largely discussed by (Ouyang et al.,

2006; Ouyang et al., 2007). The approach distin-

guishes between well-structured BPMN components

(that can be directly mapped to BPEL structured ac-

tivities) and components that are not well structured.

A formal deﬁnition of well-structured component is

given in (Ouyang et al., 2006). The algorithm tries

to map to control link-based BPEL code components

that are not well structured but acyclic. Components

that are not well-structured and, also, cannot be trans-

lated using control links (e.g., if they contain unstruc-

tured cycles) are mapped to BPEL code based on

event handlers.

4 CASE STUDY

In order to validate the feasibility of our approach,

we applied it for the deﬁnition and implementation

of an online selling process. In particular, we used

our approach to model the selling process of a typical

online shopping auction store.

At this aim, ﬁrst, we created a process line for

selling processes. Then, we used this process line to

model a selling process variant. Finally, the obtained

process variant was implemented in BPEL with our

automatic workﬂow development approach.

4.1 Selling Process Line Deﬁnition

Starting from the analysis of the literature (Malone

et al., 2003; Bernardi et al., 2012b; Bernardi et al.,

2012c), we realized a process line for selling pro-

cesses. The characteristics of this process line are

synthesized in Tables 1, 2 and 3. Table 1 includes

the invariant assets, i.e., the assets that are common to

all the selling process variants.

For example, each process variant contains an as-

set corresponding to activity Obtain Order with input

Order request and output Order.

Table 2 is obtained taking into consideration the pos-

sible application contexts where a selling process can

be applied. In this table, we list a number of diversity

factors and their possible values. For example, we

introduce the diversity factor Sell How and its possi-

ble values: Sell via physical store, Sell via electronic

store, Sell via face to face, Sell via direct mail, Sell via

email/fax, Sell via television. This means that the sell-

ing process will be executed differently based on how

the items are sold. For example, we will select dif-

ferent variant assets (and we will specialize the assets

differently) if the items are sold in a physical store or

in an electronic store. Finally, in Table 3, we indicate

the candidate variant assets, which are the assets that

can be included in one or more process variants. For

example, we can have, in some process variants, the

asset Share out goods with input Goods and Shared

out equipments and output Shared out goods.

Starting from the tables just described, we create

the Variant Asset Selection Table. An extract of this

ProcessLinesforAutomaticWorkflowDevelopment

Table 1: Invariant Assets.

Activity IN OUT

Obtain order Order request Order

Deliver Order Delivered goods

Receive payment Order Receipt

Table 2: Diversity Factors.

Diversity Factors Values

Sell How

Sell via physical store

Sell via electronic store

Sell via face to face

Sell via direct mail

Sell via email/fax

Sell via television

Sell via telemarketing

Sell What Services

Product

Store

Auction Y , N

Advance Payment Y , N

Quality control Y , N

Selling Suggestions Y , N

Seller Direct , Indirect

Advertising Y , N

Customer Assistance Y , N

table is shown in the top of the Figure 5.

It speciﬁes

the rules for associating to each possible context pro-

ﬁle the related variant assets. These have to be com-

posed with the invariant assets to obtain the process

variant speciﬁc for the given context proﬁle.

For instance, we have that for the context proﬁle

cp*= (Sell via electronic store, Product, Y, Y, Y, N, In-

direct, Y, Y) the variant assets to be selected are (see

column 101 of the table): va

= Register Seller, va

Arrange store displays, va

= Auction, va

=Check

Quality, va

=Register Auction Result, va

=Identify

potential customer needs, va

=Identify potential cus-

tomers, va

= Manage customer relationship.

To deﬁne the Asset Specialization Table of the

process line we have to identify the specializing ac-

tions needed for each possible context proﬁle. Figure

4 (bottom) includes some of the rules for associating

to each context proﬁle, the actions to be executed to

specialize the behavior of the (variant and invariant)

assets of the process line. For instance, for the con-

text proﬁle cp* considered before (see column 52), we

need to specialize the activities: Deliver in Deliver

product and Obtain order in Obtain order in elec-

tronic store. Moreover, we have to add inputs Receipt

and Shipping paper to Deliver Product. To obtain the

In this case study, we use Prologa (Vanthienen and

Wets, 1995), a tool supporting the decision table modeling.

process variant for a given context proﬁle, we have to

integrate variant and invariant assets. This integration

is obtained based on the inputs and the outputs of each

asset.

4.2 Process Variant

The process line introduced in the previous section

can be used to model different process variants of a

selling process. In particular, here, we describe the

application of the process line to automate a selling

process with online auction. The considered process

owner sells products in an electronic store through

auctions. The organization is an indirect seller, i.e.,

it offers a virtual market place and some additional

services to support the interaction between the di-

rect seller and the customers. In particular, a regis-

tered seller can send an auction proposal. The pro-

cess owner certiﬁes the quality of the products and

starts the auction. When the auction is over, the orga-

nization offers an online payment service. After the

payment, the (direct) seller sends the products to the

process owner that, in turn, sends them to the cus-

tomers. The process owner also offers customer as-

sistance and advertising services. The process owner

needs to model the selling process as just described

and to automate it into a SOA system. The system

must integrate the services of the indirect seller with

the ones provided by the direct sellers and by their

shipping partners. Starting from the process owner re-

quirements, we specify the context proﬁle cp* = (Sell

via electronic store, Product, Y, Y, Y, N, Indirect, Y,

Y). Using the Variant Asset Selection table, we iden-

tify the list of variant assets needed for the given con-

text proﬁle. Through the Asset Specialization table,

we identify the list of specialization actions to be ap-

plied to the process assets. The specialized assets are

integrated in the process variant shown in Figure 5.

In the ﬁgure, invariant assets are colored in blue, vari-

ant assets are colored in yellow, while the specialized

artifacts/activities are highlighted with a red border.

4.3 BPEL Workﬂow Generation

Using our workﬂow development approach, we have

generated the detailed process model starting from

the process variant identiﬁed through the process line.

ICSOFT2013-8thInternationalJointConferenceonSoftwareTechnologies

Table 3: Variant Assets.

Activity IN OUT

Share out goods Goods, Shared out equipments Shared out goods

Arrange store displays Registered entry document Arranged goods

Auction Arranged goods Customer ID, Order request

Check quality Arranged goods Quality certiﬁcation

Identify customers needs Registered Order Marketing report

Identify potential customers Customer request Marketing report

Inform potential customers Marketing report Advertising initiative

Manage customer relationships Marketing report, Customer ID Customer support

Figure 4: An example of Variant Asset Selection Table (top) and Asset Specialization Table (bottom).

This new model has been obtained enriching the pro-

cess model with implementation details. We have

implemented a prototype tool to support the detailed

process model generation. This tool has been re-

alized as an Eclipse add-inn, a graphical UML de-

sign and business analysis tool for modeling, doc-

umenting, building and maintaining object-oriented

software systems. Starting from the detailed process

model previously created, through the algorithm de-

scribed in (Ouyang et al., 2006), we generated the

workﬂow BPEL implementing the underlying process

variant. The process structured composition tree, ob-

tained by applying the algorithm to the portion of the

BPMN model highlighted with a red dashed line in

Figure 5, is shown in ﬁgure Figure 6. Using such a

model as a guide, the corresponding BPEL code is

generated as shown in Figure 7.

5 CONCLUSIONS

This paper extends the best practices of SPL to the

SOA systems development. In particular, we intro-

duce here the concept of process line aiming at com-

bining a set of reusable process assets into a BPMN

process variant suitable to be used in a speciﬁc con-

text. In addition, we show an approach for imple-

menting a SOA system starting from the obtained

BPMN process model. This system will be, in turn,

suitable to be used in the context previously speci-

ProcessLinesforAutomaticWorkflowDevelopment

Figure 5: Online Selling Process Variant.

Figure 6: Excerpt of BPEL Process composite Structure.

Figure 7: Small Excerpt of BPEL Generated Code.

ﬁed. We show an application of our approach to a case

study for the automation of an online auction selling

process. In this scenario, we have evaluated the fea-

sibility of our approach. In particular, we carried out

a qualitative evaluation in which two developers were

asked to model and implement the same process. The

ﬁrst developer was asked to use our approach whereas

the second developer was asked to use a only stan-

dard CASE tools. According to the data gathered, we

found out that the proposed approach reduces the time

required for modeling and workﬂow development of

around 65%. A limit of the proposed approach is re-

lated to the effort needed to model the process lines

(200h were required for the Selling process line de-

scribed in this work). However, when the decision ta-

ble system has been created no much effort is needed

to maintain it, due to the availability of mature tool

support for decision table modeling.

REFERENCES

Auechaikul, T. and Vatanawood, W. (2007). A develop-

ment of business rules with decision tables for busi-

ness processes. In TENCON 2007 - 2007 IEEE Region

10 Conference, pages 1 –4.

Bayer, J., Kose, M., and Ocampo, A. (2006). Improving

the development of e-business systems by introduc-

ing process-based software product lines. In Proceed-

ings of the 7th international conference on Product-

Focused Software Process Improvement, PROFES’06,

pages 348–361, Berlin, Heidelberg. Springer-Verlag.

Bernardi, M. L., Cimitile, M., Lucca, G. A. D., and Maggi,

F. M. (2012a). M3d: a tool for the model driven devel-

opment of web applications. In WIDM, pages 73–80.

Bernardi, M. L., Cimitile, M., Lucca, G. A. D., and Maggi,

F. M. (2012b). Using declarative workﬂow languages

to develop process-centric web applications. In EDOC

Workshops, pages 56–65.

Bernardi, M. L., Cimitile, M., and Maggi, F. M. (2012c).

Model driven development of process-centric web ap-

plications. In ICSOFT, pages 340–346.

Boffoli, N., Cimitile, M., and Maggi, F. M. (2009). Man-

aging business process ﬂexibility and reuse through

business process lines. In ICSOFT (2), pages 61–68.

Costello, C. and Molloy, O. (2004). Orchestrating supply

chain interactions using emerging process description

languages and business rules. In Proceedings of the

6th international conference on Electronic commerce,

ICEC ’04, pages 21–30, New York, NY, USA. ACM.

Dijkman, R. M., Hofstetter, J., and Koehler, J., editors

(2011). Business Process Model and Notation -

Third International Workshop, BPMN 2011, Lucerne,

Switzerland, November 21-22, 2011. Proceedings,

volume 95 of Lecture Notes in Business Information

Processing. Springer.

Gimenes, I., Fantinato, M., and Toledo, M. (2008). A prod-

uct line for business process management. In Software

Product Line Conference, 2008. SPLC ’08. 12th Inter-

national, pages 265 –274.

Hong, T.-P., Wang, S.-L., and Tsai, J.-S. (1999). Inte-

grating multiple knowledge sources using decision ta-

bles. In Systems, Man, and Cybernetics, 1999. IEEE

SMC ’99 Conference Proceedings. 1999 IEEE Inter-

national Conference on, volume 2, pages 142 –147

vol.2.

Kloppmann, M., Koenig, D., Leymann, F., Pfau, G., Rick-

ayzen, A., von Riegen, C., Schmidt, P., and Trickovic,

I. (2005). Ws-bpel extension for people–bpel4people.

Joint white paper, IBM and SAP, 183:184.

Malone, T. W., Crowston, K., and Herman, G. A., editors

ICSOFT2013-8thInternationalJointConferenceonSoftwareTechnologies

(2003). Organizing Business Knowledge: The MIT

Process Handbook. The MIT Press, 1st edition.

Mohammadi, M. and Mukhtar, M. (2011). Soa-based

business process for supply chain management. In

Software Engineering (MySEC), 2011 5th Malaysian

Conference in, pages 213 –216.

Ouyang, C., Dumas, M., ter Hofstede, A. H. M., and van der

Aalst, W. M. P. (2006). From bpmn process models to

bpel web services. In Proceedings of the IEEE In-

ternational Conference on Web Services, ICWS ’06,

pages 285–292, Washington, DC, USA. IEEE Com-

puter Society.

Ouyang, C., Verbeek, E., van der Aalst, W. M. P., Breutel,

S., Dumas, M., and ter Hofstede, A. H. M. (2007).

Formal semantics and analysis of control ﬂow in ws-

bpel. Sci. Comput. Program., 67(2-3):162–198.

Rolland, C. and Nurcan, S. (2010). Business process lines to

deal with the variability. In System Sciences (HICSS),

2010 43rd Hawaii International Conference on, pages

1 –10.

Schnieders, A. and Puhlmann, F. (2006). Variability mech-

anisms in e-business process families. In Proc. Inter-

national Conference on Business Information Systems

(BIS 2006, pages 583–601.

Vanthienen, J. and Wets, G. (1995). Integration of the de-

cision table formalism with a relational database envi-

ronment. Inf. Syst., 20(7):595–616.

Welke, R., Hirschheim, R., and Schwarz, A. (2011).

Service-oriented architecture maturity. Computer,

44(2):61 –67.

Zhao, W., Huang, Y., Yuan, C., and Wang, L. (2010). For-

malizing business process execution language based

on petri nets. In Intelligent Systems and Applications

(ISA), 2010 2nd International Workshop on, pages 1

–8.

ProcessLinesforAutomaticWorkflowDevelopment