Bridging the Gap between a Set of Interrelated Business Process Models

and Software Models

Estrela F. Cruz

1,2, ∗

, Ricardo J. Machado

and Maribel Y. Santos

Instituto Polit

ecnico de Viana do Castelo, Viana do Castelo, Portugal

Centro ALGORITMI, Escola de Engenharia, Universidade do Minho, Guimar

aes, Portugal

Keywords:

Business Process Modeling, BPMN, Use Case Model, UML, Requirements Elicitation.

Abstract:

A business process model identiﬁes the activities, resources and data involved in the creation of a product or

service, having lots of useful information for starting to develop a supporting software system. With regard to

software development, one of the most difﬁcult and crucial activities is the identiﬁcation of system functional

requirements. A popular way to capture and describe those requirements is through UML use case models.

Usually an organization deals with several business processes. As a consequence, a software product does

not usually support only one business process, but rather a set of business processes. This paper presents an

approach that allows aggregating in one use case model all the information that can be extracted from the

set of business process models that will be supported by the software under development. The generated use

case model serves as a basis for the software development process, helping reducing time and effort spent in

requirements elicitation. The approach also helps to ensure the alignment between business and software, and

enables traceability between business processes and the corresponding elements in software models.

1 INTRODUCTION

Business Process Management (BPM) is being in-

creasingly used by organizations as a means to im-

prove the quality of their products or services, the efﬁ-

ciency of their processes and productivity and increas-

ing the beneﬁts for their stakeholders. By this way,

BPM is becoming increasingly important to organiza-

tions. BPM includes methods, techniques, and tools

to support the design, enactment, management, and

analysis of operational business processes (van der

Aalst, 2004). A business process is a set of interre-

lated activities that are executed by one, or several,

organizations working together to achieve a common

business purpose (Ko, 2009). Among the various ex-

isting modeling languages, we opted for the Business

Process Model and Notation (BPMN), currently in

version 2.0 (OMG, 2011), because it is a widespread

OMG standard that is very well accepted and actually

used in companies and organizations (Recker, 2008).

Moreover, it is a complete language that allows creat-

ing a detailed business process model (OMG, 2011).

Information systems researchers and profession-

∗

This work has been supported by FCT - Fundac¸

ao para

a Ci

encia e Tecnologia in the scope of the project: PEst-

UID/CEC/00319/2013.

als have recognized that understanding a business

process is the key to identify the user needs of the

software that supports it (Shishkov et al., 2002; Ko,

2009). In fact, one of the main software quality ob-

jectives that needs to be addressed is to ensure that

a software product meets the business needs (Jalote,

2008). For that, the software product requirements

need to be aligned with the business needs, both in

terms of business processes and in terms of the infor-

mational entities that those processes deal with. This

drives us to the question: “Is it possible to systemati-

cally derive a use case model from a set of interrelated

business process models?”

Requirements elicitation is a key step in the soft-

ware development process. Nevertheless it is a time-

consuming step that can take several months (or even

years) to complete and usually involves many re-

sources (Cockburn, 2001). Use case models aim to

capture and describe the functional requirements of a

system (Hull et al., 2011). A use case model is a set of

use case diagrams and the corresponding use case de-

scriptions (Bittner and Spence, 2003). The use case

diagrams enable to perceive the need of describing

the system behavior in response to messages received

from outside the system (i.e., from its actors and ex-

ternal systems) (Hull et al., 2011).

338

Ferreira Cruz E., Machado R. and Santos M..

Bridging the Gap between a Set of Interrelated Business Process Models and Software Models.

DOI: 10.5220/0005378103380345

In Proceedings of the 17th International Conference on Enterprise Information Systems (ICEIS-2015), pages 338-345

ISBN: 978-989-758-097-0

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

Approaches such as BPEL (Business Process Exe-

cution Language) allow the execution of business pro-

cesses in a service-oriented perspective by integrating

enterprise applications (Liang et al., 2008). Such ap-

proaches, however, require the existence of services,

which could be internal or external to the organiza-

tion, whose orchestration can be done using BPEL.

The aim of this approach is to generate models that

can be used as basis to the development of software

that supports the business processes. To plan and de-

sign a suitable software supporting system, ﬁrst it is

necessary to know the main requirements that must be

supported by the software under development. The

approach presented in this paper intends to identify

the functional requirements (representing them as a

use case model) based on the set of interrelated busi-

ness processes. Shishkov et al. state that deriving

use case models from business analysis models would

be useful, since both reﬂect behavior within busi-

ness/software systems (Shishkov et al., 2002).

This paper further complements and improves

previous work, presented by the same authors, on

bridging the gap between business process models

and software models. The approach presented in

(Cruz et al., 2014a) derives a use case model from

one business process model. However, in a real situa-

tion a software product does not usually support only

one business process, but rather a set of business pro-

cesses. In the approach presented herein we intend to

improve the work presented in (Cruz et al., 2014a) ex-

tending it in order to treat sub-processes without los-

ing information and to aggregate and merge the infor-

mation we have in a set of interrelated business pro-

cesses into one integrated use case model.

The remainder of this paper is structured as fol-

lows. Next section summarizes two fundamental ap-

proaches, which are used in the approach described

herein, and presents some related work. The proposed

approach is presented in section 3. The application of

the proposed approach is illustrated through a demon-

stration case in section 4. Finally, conclusions and

some remarks to future work are presented in section

2 PREVIOUS AND RELATED

WORK

Previous work by the same authors (Cruz et al.,

2014a), summarized next, allows generating a use

case model, including descriptions, from one private

BPMN business process model. Nevertheless, when

sub-processes are involved, the approach may lose

some structuring information (Cruz et al., 2014a) and

most of all, the approach deals with a single process.

Usually, a software product does not support only one

business process, but rather a large number of busi-

ness processes. In this case, we have to group in one

use case model all the information we have in the set

of business process models that will be supported by

the software under development.

The approach described in this paper, and pre-

sented in section 3, starts with high abstraction level

use cases, each corresponding to a business process,

and reﬁnes them (by decomposition) in order to ob-

tain detailed use cases, useful to software develop-

ment. To do that we are using the decomposition

triangle approach (Cruz et al., 2014b) (summarized

next) that reﬁnes a use case into a more detailed use

case model.

From one Business Process Model to a

Use Case Model

An approach to generate a use case model, including

descriptions, from a single private business process

diagram (modeled in BPMN) has been presented in

(Cruz et al., 2014a). The approach comprises the def-

inition of a set of rules to generate a use case diagram

in which each activity in the BPMN model gives ori-

gin to a use case, and a participant gives origin to an

actor in use case model. The relationship between

actors and use cases is derived from the existing re-

lations between the corresponding participant and ac-

tivities. The actor that is derived from a pool (or lane)

is related with the use cases that are derived from the

activities belonging to that pool (or lane). The ac-

tor that is derived from a participant that exchanges

messages with an activity is related with the use case

derived from the activity.

All existing information (data involved in the pro-

cess, decisions that have to be made, exchanged mes-

sages and so on) that cannot be represented as an actor

or as a use case is depicted in the use cases descrip-

tions. To describe a use case, a template that sim-

pliﬁes the Cockburn’s template for use cases is used.

Based on a private business process model the ap-

proach is able to identify the use case names and the

related actors. Depending on the incoming and out-

going connections from the corresponding activity, it

is also able to identify each use case’s pre-conditions,

post-conditions, trigger and the main scenario.

The Decomposition Triangle Approach

An approach, named as Decomposition Triangle, to

decompose and reﬁne use cases has been presented

in (Cruz et al., 2014b). The approach starts with high

BridgingtheGapbetweenaSetofInterrelatedBusinessProcessModelsandSoftwareModels

339

abstraction level use cases and ends with very detailed

level use cases. An extension to the UML2.5 is also

proposed for accommodating a new reﬁnement rela-

tion from a use case to a use case (sub-)model (Cruz

et al., 2014b).

The approach is iterative and incremental and

starts by identifying the system scope and the actors

involved. Then, the system’s main functionalities are

identiﬁed and represented as use cases in the use case

model level 1. Based on the use case descriptions and

stakeholder’s feedback, each use case can be decom-

posed in a use case model represented on the next

decomposition level, decreasing this way the abstrac-

tion level and increasing the detail level. The process

ends when the CRUD (Create, Retrieve, Update and

Delete) operations are identiﬁed. The use cases iden-

tiﬁed are numbered using a leveled numbering.

Related Work

Lubke and Schneider (Lubke and Schneider, 2008)

propose an approach to generate a business process

model (modeled in BPMN) from a UML use case di-

agram. The authors justify the need for this approach

with the increasing number of use cases and with the

possibility of losing the execution order of the various

use cases (Lubke and Schneider, 2008).

Other authors propose approaches to derive use

cases from business process models. Some of the ex-

isting approaches are presented next.

Dijkman and Joosten propose an approach that

maps a business process model (modeled using the

UML Activity Diagram) into use case diagrams (Di-

jkman and Joosten, 2002b). They also proposed an

algorithm to derive a use case diagram from a busi-

ness process modeled as activity diagrams (Dijkman

and Joosten, 2002a). To do so, Dijkman and Joosten

start by deﬁning the activity diagram and the use case

diagram meta-models. Then, the authors establish a

relation between the “role” from the activity diagram

and the “actor” in a use case diagram and a “step”

(a sequence of tasks) from the activity diagram origi-

nates a “use case” in a use case diagram (Dijkman and

Joosten, 2002a).

Rodr

ıguez et al. propose a systematic approach to

derive a use case diagram from a UML activity dia-

gram (Rodr

ıguez et al., 2008) and another to derive

a use case diagram from a BPMN model (Rodr

ıguez

et al., 2007). In the latter approach, the transformation

is guided by a set of QVT (Query View Transform)

rules and checklists. In a summarized way, in the Ro-

driguez et al. approach, a participant is mapped to

an actor in the use case diagram and an activity gives

origin to a use case.

Cockburn (Cockburn, 2001) distinguishes differ-

ent use case abstraction levels. The low detail level

use cases, and the very detailed use cases with a clear

intention. Cockburn states that low detail level use

cases are not trustable as functional requirements for

the system being built (Cockburn, 2001). From an-

other point of view, Cockburn categorizes use cases

as business use cases and system use cases (Cockburn,

2001). Cockburn sees business use cases as low de-

tail level (high abstraction) use cases and system uses

cases as high detail level (low abstraction) use cases

and advises the use case writers to start with the busi-

ness use cases and “unfold” them continuously until

they become system use cases (Cockburn, 2001).

The approach we are presenting herein is aligned

with Cockburn’s points of view, helping in trans-

forming business process models (low detail level use

cases) into system level functional requirements (high

detail level use cases), and helping in keeping track of

the transformations of the use cases.

All surveyed existing approaches obtain a use case

diagram based on a single business process model.

None of the surveyed approaches aggregates a set of

business processes models in one use case model in-

cluding the use case descriptions. But, typically, in

a real situation, a software product does not support

only one process, but a reasonable set of processes. In

order to generate useful use case model it will be nec-

essary to consider the set of business process models

that will be supported by the software under develop-

ment.

3 DERIVING A USE CASE

MODEL FROM A SET OF

INTERRELATED BUSINESS

PROCESS MODELS

In the approach presented herein we intend to improve

the work presented in (Cruz et al., 2014a) extending

it in order to treat sub-processes without losing infor-

mation and to aggregate and merge the information

we have in a set of interrelated business processes into

one integrated use case model.

The set of business processes, belonging to an or-

ganization, being supported by the software under de-

velopment must be grouped in a single use case model

because a software development team needs to under-

stand the system context and scope before starting to

plan and design a solution. Following this reason, ﬁrst

it is needed to identify and specify which business

processes are to be supported by the software under

development.

ICEIS2015-17thInternationalConferenceonEnterpriseInformationSystems

340

Figure 1: A generic decomposition scheme.

A use case model can be created with a high ab-

straction level or low abstraction level (Cockburn,

2001; Cruz et al., 2014b). The approach we are

presenting here starts with high abstraction level use

cases and ends with lower abstraction level use cases.

The approach starts by grouping all processes that

will be supported by the software under development

in one use case diagram where each process is repre-

sented as a use case. Each use case is then reﬁned and

decomposed in a use case model as described in (Cruz

et al., 2014b). All identiﬁed use cases are numbered

using the tag=value UML mechanism. A generic

scheme of applying the decomposition is shown in

Figure 1.

Similarly to what happens in (Cruz et al., 2014b),

the approach represents the use case models in differ-

ent abstraction levels:

• Level 0: At this level, the system scope and fron-

tier must be identiﬁed as well as all the actors in-

volved, so the set of business processes that will

be supported by the software under development

must be identiﬁed. Each participant in a business

process model (represented as a pool or a lane) is

transformed in an actor (with the same name) in

the use case diagram (see Figure 1, level 0). The

subdivision of a pool in several lanes, or a lane in

other lanes originates an actor’s hierarchy (Cruz

et al., 2014a). Thus, at this level all participants

involved in the set of business processes are rep-

resented, as actors, in the actor’s diagram.

Usually a participant is involved in several busi-

ness processes belonging to an organization.

When participants with the same name are in-

volved in more than one business process we as-

sume that they represent the same participant, and,

as consequence, they will be represented by the

same actor in the use case model.

• Level 1: At this level, the ﬁrst use case model is

created with the highest abstraction level where

each top level business process is transformed into

a use case, in the use case model (a business use

case) (see Figure 1, level 1). Each use case, rep-

resenting a business process, is related with the

corresponding actors representing the participants

involved in the process. The use cases are num-

bered sequentially. The use case description is a

general overview of the process it addresses.

Monsalve et al state that a business process model

does not allow identifying business process goals

or main objectives, but that is important to soft-

ware requirements elicitation (Monsalve et al.,

2012). At this level, the use case description can

be used to represent the business process goal and

objective helping to understand the business pro-

cess purpose. That can be accomplished by talk-

ing/discussing with stakeholders since at this soft-

ware development process’ stage the stakeholders

are still actively involved in the process.

• Level 2: At this level, each process (represented

as a use case in level 1) is mapped to a use

case model following the rules described in (Cruz

et al., 2014a). Basically one activity from a busi-

ness process is transformed into a use case and

each participant is transformed into an actor. All

incoming and outgoing connection ﬂows from the

activity originate a NL sentence in the description

of the use case that represents the activity. Each

generated use case model in level 2 reﬁnes and

BridgingtheGapbetweenaSetofInterrelatedBusinessProcessModelsandSoftwareModels

341

decomposes a corresponding use case in level 1

(see Figure 1, level 2). The number of use case

models, at this level, is the same as the number of

use cases existing in the diagram at level 1. The

use cases identiﬁed are numbered using a leveled

numbering.

• Level (i+1), (i≥2) : At this level, each use case

that represents a sub-process in level i is decom-

posed and reﬁned in a use case model in level

(i+1) (see Figure 1, level 3). BPMN has two types

of activities: a task (atomic activity) and a sub-

process (OMG, 2011). A sub-process is a pro-

cess, so in this case, the use case that represents

the activity can be decomposed and mapped to a

use case model. The decomposition ends when all

use cases representing processes or sub-processes

are reﬁned.

In the presented approach, reﬁning a use case

means detailing all activities involved in the cor-

responding process, including all resources and/or

data that are consumed and produced, messages ex-

changed, decisions that have to be taken, events that

can occur, etc.

The decomposition results in a tree structure

where the leaf nodes represent the tasks and the non-

leaf nodes represent the processes and sub-processes.

The decomposition tree has high abstraction level use

cases at level 1. The abstraction level decreases in ev-

ery use case decomposition. The approach allows to

relate use cases belonging to different abstraction lev-

els allowing to drill down and up between different

abstraction levels. This way, the approach allows trac-

ing back from requirements to the business processes

and from the business processes to the corresponding

requirements.

4 DEMONSTRATION CASE

In this section we use, as a demonstration case, a

very well-known example of a School Library Sys-

tem where some of the business process more com-

monly used have been selected to present here: Reg-

ister User, Lend a Book, Purchase a Book, Return a

Book and Renew Loan. The Return a Book business

process model includes the sub-process, Penalty treat-

ment.

Figure 2 shows the use case diagram level 0 (ac-

tors diagram) with four actors, which were derived

from the business process participants. The actors are

also depicted in diagram level 1 as seen in Figure 3.

In the Purchase a Book business process model

(represented in Figure 4) the participants involved are

Figure 2: Actors diagram (level 0).

Figure 3: Use Case diagram (level 1).

Librarian and Supplier. Following the rules presented

previously, Librarian and Supplier must be repre-

sented as actors in the actors diagram level 0 and in

use case diagram level 1 (see Figure 3).

In Lend a Book business process model (Figure 5)

two participants are identiﬁed, Borrower and Atten-

dant. The two corresponding actors (with the same

name) will be also represented in the actors diagram

and in the use case diagram level 1 (see Figure 3).

In Return a Book business process (Figure 6),

the participants involved are Borrower and Attendant

already identiﬁed in Lend a Book business process

model. So, the actors belonging to the actors diagram

and use case diagram level 1 remain the same.

For limitations of space, the Register User and Re-

new Loan business process models are not presented

here, but in both processes the participants involved

are the same Borrower and Attendant. The corre-

sponding actors are already represented in the actors

diagram and in the use case diagram level 1.

Summarizing, and looking at the business pro-

cesses we have selected for our demonstration case,

we can see that Librarian and Supplier are the partic-

ipants involved in Purchase a Book business process,

Borrower and Attendant are the participants involved

in all the other processes. Thus, these four partici-

pants are represented as actors in the actors diagram

(level 0), as seen in Figure 2.

In the use case diagram level 1 (refer to Figure 3),

ICEIS2015-17thInternationalConferenceonEnterpriseInformationSystems

342

Figure 4: Purchase a Book business process model.

Figure 5: Lend a Book business process model.

Figure 6: Return a Book business process model.

Figure 7: Penalty Treatment business process model.

each selected business process is represented as a use

case connected with the actors that represent the cor-

responding participants. So, Purchase a Book busi-

ness process is related to actors Librarian and Sup-

plier. Lend a Book, Return a Book, Renew Loan and

Borrower and Attendant. The use cases are numbered

sequentially. Each use case, which represents a pro-

cess, is then detailed in a use case model at level 2, as

we can see in Figure 8.

When an actor is related with all use cases in a

use case diagram, the established association between

the actor and the use cases is represented by a single

link to the diagram boundary, to simplify the repre-

BridgingtheGapbetweenaSetofInterrelatedBusinessProcessModelsandSoftwareModels

343

Figure 8: Complete Use Case model (level 3).

sentation. If an actor is associated to only some of the

use cases that belong to the use case diagram, the link

is established between the actor and the related use

cases.

By analyzing the Return a Book business process

model (refer to Figure 6), we can see that the pro-

cess comprises ﬁve activities: Receive returned book,

Search for book’s active loan, Check for delivery de-

lay, Update Loan Info and Penalty treatment, each

one giving origin to a use case in the use case model

that reﬁnes the Return a Book use case (level 2). All

activities belong to the Attendant pool, so all use cases

representing the activities are related with the Atten-

dant actor. Receive returned book activity receives a

message from the Borrower participant and Penalty

treatment activity also exchange messages with the

Borrower participant, so the Borrower actor is related

with both corresponding use cases. Similar line of

reasoning can be applied to explain the Lend a Book

(refer to Figure 5) and Purchase a Book (Figure 4)

business process models transformation.

The Penalty Treatment use case represents a sub-

process (represented in Figure 7), so it can be repre-

sented as a use case model in the next level (level 3),

detailing and reﬁning the use case (level 2) as we can

see in Figure 8.

5 CONCLUSIONS AND FUTURE

WORK

The approach presented in this paper allows conclud-

ing that is it is possible to systematically derive a com-

plete data model from a set of interrelated business

process models, helping to ensure that the software

requirements really meet business needs.

The approach starts by identifying the set of busi-

ness processes that will be supported by the software

under development, identifying the system scope.

Then a use case model, divided in several abstraction

levels, is created based on a set of identiﬁed business

process models. In level 0, all actors and all actors’

hierarchies are identiﬁed, representing the involved

participants. In level 1, the highest abstraction level

use cases are represented in the use case model, each

one representing a business process being supported

by the software system under development. Each use

case is then decomposed and reﬁned in a use case

model (level 2). All existing information in a private

ICEIS2015-17thInternationalConferenceonEnterpriseInformationSystems

344

business process model is transformed to information

in the use case model. Most of the information is tran-

scribed to use case descriptions. The approach ends

when all use cases representing processes and sub-

processes are decomposed into atomic activities, each

one being represented as a use case.

The decomposition process generates a use case

tree structure, which enables one to drill down and

easily trace any use case back to its more abstract base

use case and corresponding business process, allow-

ing traceability between business processes and soft-

ware representations. The created use case model will

serve as a basis to the development of the software

that will support the business. At the same time, busi-

ness and software modeling efforts can be joined to-

gether, reducing the analysis time and avoiding for-

getting functional requirements.

Generating a use case model joining the informa-

tion from a set of business process models allows

us to use existing methods, techniques and tools to

generate other software models from use case mod-

els. One of those methods is the 4SRS (4-Step Rule

Set), which generates a logical architecture and corre-

sponding class diagrams from user requirements, rep-

resented as use cases (Santos and Machado, 2010).

As future work, we intend to apply this approach,

integrated with the 4SRS, in a real industrial scenario

which complexity and dimension will beneﬁt from a

systematic approach to the generation of the use case

model and other software models.

REFERENCES

Bittner, K. and Spence, I. (2003). Applying use cases: a

practical guide. Pearson Education inc.

Cockburn, A. (2001). Writing Effective Use Cases. Addison

Wesley.

Cruz, E. F., Machado, R. J., and Santos, M. Y. (2014a).

From business process models to use case models: A

systematic approach. In Aveiro, D., Tribolet, J., and

Gouveia, D., editors, Advances in Enterprise Engi-

neering VIII, volume 174 of LNBIP, pages 167–181.

Springer International Publishing.

Cruz, E. F., Machado, R. J., and Santos, M. Y. (2014b). On

the decomposition of use cases for the reﬁnement of

software requirements. In 14th ICCSA, IEEE Com-

puter Society Press, pages 237–240.

Dijkman, R. M. and Joosten, S. M. (2002a). An algorithm

to derive use cases from business processes. In 6th

Int.Conf. on SEA, pages 679–684.

Dijkman, R. M. and Joosten, S. M. (2002b). Deriving use

case diagrams from business process models. Techni-

cal report, CTIT Technical Report, The Netherlands.

Hull, E., Jackson, K., and Dick, J. (2011). Requirements

Engineering. Springer.

Jalote, P. (2008). A concise Introduction to Software Engi-

neering. Springer.

Ko, R. K. L. (2009). A computer scientist’s introductory

guide to business process management (bpm). Cross-

roads, 15:4:11–4:18.

Liang, Y., Tian, J., Hu, S., Song, Y., and Zhang, Y. (2008).

A template-based approach for automatic mapping be-

tween business process and BPEL process. Wuhan

University Journal of Natural Sciences, 13:445–449.

Lubke, D. and Schneider, K. (2008). Visualizing use case

sets as BPMN processes. In Requirements Engineer-

ing Visualization.

Monsalve, C., April, A., and Abran, A. (2012). On the ex-

pressiveness of business process modeling notations

for software requirements elicitation. In IECON 2012

- 38th Annual Conference on IEEE Industrial Elec-

tronics Society, pages 3132–3137.

OMG (2011). Business process model and notation

(BPMN), version 2.0. Technical report, OMG.

Recker, J. C. (2008). BPMN Modeling – Who, Where, How

and Why. BPTrends, 5(3):1–8.

Rodr

ıguez, A., Fern

andez-Medina, E., and Piattini, M.

(2007). Towards CIM to PIM transformation: From

secure business processes deﬁned in BPMN to use-

cases. In B. Process Management, pages 408–415.

Rodr

ıguez, A., Fern

andez-Medina, E., and Piattini, M.

(2008). Towards obtaining analysis-level class and use

case diagrams from business process models. In Ad-

vances in Conceptual Modeling Challenges and Op-

portunities, volume 5232 of LNCS, pages 103–112.

Springer Berlin / Heidelberg.

Santos, M. Y. and Machado, R. J. (2010). On the derivation

of class diagrams from use cases and logical software

architectures. In 2010 Fifth ICSEA.

Shishkov, B., Xie, Z., Liu, K., and Dietz, J. L. (2002). Us-

ing norm analysis to derive use cases from business

processes. In Proceedings of the 5th Workshop On

Organizational Semiotics.

van der Aalst, W. (2004). Business process management

demystiﬁed: A tutorial on models, systems and stan-

dards for workﬂow management. In Desel, J., Reisig,

W., and Rozenberg, G., editors, Lectures on Concur-

rency and Petri Nets, volume 3098 of LNCS, pages

1–65. Springer Berlin / Heidelberg.

BridgingtheGapbetweenaSetofInterrelatedBusinessProcessModelsandSoftwareModels

345