Extracting reusable fragments from Business Process ...

1 downloads 411 Views 187KB Size Report
analyze variability in the model in order to extract business ... small business process fragments. ... can find AND, OR, XOR, complex and parallel Gateway.
Extracting reusable fragments from Business Process using BPMN Maryam Radgui1 , Rajaa Saidi1,2 and Salma Mouline1 1

LRIT associated unit to CNRST (URAC 29), Faculty of Sciences, Mohammed V-Agdal University BP 1014, Rabat, Morocco 2 INSEA, BP 6217, Rabat, Morocco [email protected], [email protected], [email protected]

Abstract—During the last years, companies are developing a growing interest in improving the efficiency and quality of their internal business processes. The need of reuse of some business part to fulfill compagnie’s requirements leads to the need of extracting business fragments from business process model. The aim of this paper is to propose an approach for identifying business fragments from business process model using BPMN. Our approach is based on variability which is expressed in terms of variants and variation points. Applying this approach we can analyze variability in the model in order to extract business fragments that can be reused. Keywords— Information System; Business Process; Reuse; BPMN; Extraction; Goal.

I. I NTRODUCTION The increasing interest of the software engineering community is raised in using business process models as a source of requirements. Indeed, Process-Aware Information Systems (PAISs) become an important part of entreprise computing. PAISs are used to support business process at an operational level [1]. It enables a separation of process logic from application code which is a well established principle in computer science in order to reduce costs and to increase maintainability. Considering the constant evolution of business requirements and the need for a flexible and an adaptable information system to changing business processes, the need of reusing functional and pretested business parts in current information system emerges. This reuse can offer a solution to the business process flexibility and business agility for the information system. We distinguish two approaches related to the reuse engineering. Design for reuse and Design by reuse [2]. The Design for reuse summarizes the activities of production of reusable artefacts. It concerns the problems of identification, representation and organization of the business process, while the Design by reuse represents the activities of the inclusion of previously designed business process in an application under development. It concerns the problems of finding, selecting, adapting and assembling the business process. In this paper, we are interested in the design for reuse. Business processes are usually big and complex models which make them unreadable; They cannot be easily understood and maintainable and they cannot be reusable in totality. For this reason, we attempt to propose an approach that enables the extraction of business fragments from business process models.

To do so, we need to build reusable business processes fragments. The goal is not to create those fragments from scratch. The originality is to decompose business processes, which has generally a big and a complex structure, into small business process fragments. Indeed, smaller business fragments are easier to understand, easier to maintain and faster to reuse. Those fragments can be reused from another functional business process in order to adapt it according to the new business requirements. Many approaches have been proposed to deal with this identification, but most of them have other motivations such as the service orientation, the reduction of complexity, the representation of variability, ...etc. They are rarely approaches that have dealt with the identification in order to get reusable units and none of these approaches has really given a detailed and structured approach. In this paper, we propose an approach for the identification of business fragments from business process model. This approach is expressed in terms of variation points and variants [3] taking into account goal orientation. In fact, the proposed approach allows the extraction of business fragments from the presentation of business process using BPMN [4]. BPMN is widely used for business process definition. BPMN’s models are simple; they can be easily understood without deep knowledge of this standard. The remainder of this paper is organized as follows. Section 2 discusses an overview of the basic concepts of our work namely the definition of business process, BPMN and variability. Section 3 presents a state of the art. Section 4 exposes our proposal to deal with this identification and illustrates the approach with a case study. Section 5 concludes the paper and provides directions for future works. II. OVERVIEW OF THE BASIC CONCEPTS In this section, we expose a brief overview of the elements that we use in our approach namely : Business process, BPMN and the variability concept. A. Business Process A business process is a set of structured and hierarchical activities designed for reaching business goals. Business processes are central in the definition of an Information System (IS) and its evolution. Indeed, the close link between IS and

processes justifies their common goal which is to improve the productivity of the company. In this sense, the description of the business processes brings a real vision of the business, and it is an excellent tool for formalization and analysis in building systems. It should be emphasized that a good understanding of business process management contributes to a good management for the IS. In fact, a business process can be defined as a sequence of interrelated or interacting activities. A process receives input objects and adds value by means of resources, while providing output objects (products or services) to meet the needs and requirements of a client (goals) inside or outside the company. It can be triggered by internal or external events. Each process is in communication with others and can be decomposed into sub-processes. This definition seems fairly comprehensive as it takes into account both the structure of the process that the sensitivity of the latter to its environment. B. BPMN Business Process Modeling Notation (BPMN) is a notation to model business processes. It is based on the representation of activity flows and allows representing different levels of details for different purposes [4] [5]. BPMN defines a Business Process Diagram (BPD), which is based on set of graphical elements tailored for creating graphical models of business process operations. We especially focus on Flow objects, which are the main graphical elements that define the behavior of a business process. There are three Flow Objects: Events, Activities and Gateways. • Activities: An activity refers to the work that is performed within a business process and is represented by a rounded rectangle. • Events: An event is something that happens during the course of a business process which affects the sequence or timing of activities of a process. • Gateways: Gateways are used to control how sequence flows converge and diverge within a process. Gateways can represent decisions, where one or more paths are disallowed, or they can represent concurrent forks. We can find AND, OR, XOR, complex and parallel Gateway. A task Check or Cash A Start Event

Identify Payment Method

Accept Cash or Check

Payment Method ?

An end Event

Prepare Package for Customer

A Sequence Flow Credit Card

Process Credit Card

A Gateway « Decision »

Fig. 1.

A simple business process

Figure 1 presents a simple business process to illustrate the most commonly used BPMN elements and their graphical notation. BPMN become the most popular business process design

language and the privileged tool for most companies. That is the reason we choose BPMN for business process modeling. C. Variability The expansion of research in the field of variability has led to several definitions for this concept. For example, in [6] the author defines the variability as the ability to be subject to variation. But, most authors have adopted the definition quoted in [7]: ”Variability is the ability to change or customize a software system”. Furthermore, variability was introduced into various contexts, particularly in domain engineering in [6], [8] and product lines development [7], [9], [10]. However, it was weakly expressed in the design of business processes, although there have been some attempts like in [3]: Variability, on business process models, consists of defining alternative paths of execution in a workflow. In this paper, we especially focus on variability represented through the concepts of variation points and variants. Variation point is the place where the variation occurs, and each possible alternative for a variation point [3]. The variants describe the object of variation, it could be the different behaviors of processes. For example, if a task could be performed in different ways each one could be represented as a variant. Figure 2 presents an example of a payment process showing variants and variation point expressed in BPMN. Variation point

Payment by cash

Fig. 2.

Payment ?

Payment by check

Payment by credit card

Variants

An example of variability: payment process

III. S TATE OF THE A RT Many approaches have been proposed to deal with the identification of business fragments, those business fragments are generally considered as services. We notice that several concepts have been used in order to satisfy this identification. We propose to study those methods and we evaluate them to specify our proposition. The IBM’s method SOMA [11] and [12] is a method for the identification, modeling and service specification. It consists of three phases, the phase we are interested in is the identification phase which is based on three steps: (i) a Top-down approach for the decomposition of areas, (ii) a Bottom-up process for the analysis of existing assets and (iii) a hybrid (Middle-out) approach for a model of service depending on the purpose. The Top-down approach provides a mapping of use cases, while the Bottom-Up approach analyzes existing systems to identify low-level services. The hybrid approach consists of modeling service based on the goals and aims to identify services that

have not been identified in the other two approaches. A hybrid approach was also proposed by [13] in a method named CSOMA. This method provides a process covering the three phases of the life cycle of services: the identification phase, the modeling phase and the development phase. It is a hybrid approach that combines both top-down and bottomup approach. Among the important features of CSOMA is the flexibility in the services design. CSOMA is based on the notion of purpose to identify business services. The approach identifies the business service in adopting a process-oriented approach. It consists in identifying the services that highlights the goals that these services can achieve, rather than the features that enable to achieve them. The purpose of the approach is to use the services to develop a cooperative process inter-company. In [14], Business processes orchestrate the execution of several finer-grained business services to fulfill the required business functionality and are thus the units of decomposition into business services using top-down approach. The top down development approach allows the decomposition of business process into finer grained unit. This approach requires a clear view of business processes and their interactions within a company. It emphasizes how business domains are decomposed into a collection of business processes, how business processes are decomposed into constellations of business services, and how these services are implemented in terms of pre-existing companies assets. In fact, business services are the appropriate units of business process as they identify business processes and associate business costs, its also achieve reuse of resources across companies and business units. Furthermore, in [15], the authors, after the selection of automatic activities from business process model, identify candidate services by applying a set of proposed heuristics to the set of selected activities. Those heuristics are defined in order to address both syntactical and semantic analysis of the process model. Syntactical analysis consists on the structure of process model while Semantic analysis considers all indications for process automation. [16], in his book ”Service-Oriented Architecture: Concepts, Technology, and Design”, presents a method for defining services that cover the first two stages of the life cycle of building a SOA that include: identification and design services. This is a top down approach with twelve phases to achieve in order. The approach consists on the decomposition of the business processes already mapped into a set of steps. The proposed approach is a top down approach which means an overhaul of some or all of the information system of the company, often considered too costly and too risky. In addition to that, the method cited in [17] offers an approach to building services and service composition. The method identifies services from business process description and explicitly proposes a study of the variability in service design. On the other hand, the authors in [18] were interested to the reduction of model complexity. They identify patterns to reduce the model complexity on the level of the abstract

syntax; the goal is to simplify the structure of the process model. The authors identified twelve patterns operations on the abstract syntax of a process model and classified them according to the hierarchy. Three patterns: Vertical, Horizontal and Orthogonal Modularization patterns capture different ways in which a process model is decomposed into modules. Vertical Modularization pattern captures features to decompose a model into vertical modules (subprocesses), according to a hierarchical structure. Horizontal Modularization pattern captures features to partition a process model into peer modules, and Orthogonal Modularization pattern captures features to decompose a process model along the crosscutting concerns of the modeling domain, which are scattered across several model elements or modules [18]. Using a goal oriented approach, Some authors like [19] and [20] applies variability analysis over business process models. [19] presents a high level process that links different methods in order to describe a semantic way to update BPMN models. In this work [19], the commonality and variability can be represented through a structure of AND-OR decompositions. A goal graph [19] is characterized by the hierarchical decomposition of goals in sub-goals using logical operators such as And, Or and XOr decomposition. Moreover, [20] introduces a variability-intensive approach to goal decomposition. The approach is based on the semantic characterization of OR-decompositions of goals. In [20], goals are used to describe variability, the commonalities are expressed as And-Decompositions and the variability as OrDecompositions. A. Evaluation of the approaches Many approaches have been proposed to deal with the identification of small business parts from business process, but most of them have another motivation such as orientation service (building SOA) [14] [12] [13] , complexity reduction [18], variability representation [19] [20] ...etc. They are rarely approaches that have dealt with the identification in order to obtain reusable fragments and none of those approaches has really given a detailed and structured methods. The table 1 summarizes the overview of different methods. Most of those approaches use the concept of SOA which has been intensively debated in recent years. Various approaches for services development in SOA propose business processes as a starting point. A unified methodical approach for identifying services has not yet been reached. We will retain the interest of this work to use the services as a business unit extracted from business process. Thus, our proposition will focus essentially on the extraction of business fragments from business processes. Those fragments encapsulate a business goal, they can then be considered as business services. IV. E XTRACTING B USINESS F RAGMENTS A PPROACH Our approach aims to provide a guideline for extracting business fragments from business process models. Our approach is based on variability concept in order to obtain

TABLE I OVERVIEW OF DIFFERENT APPROACHES Method [11] and [12]

Finality Developing services in SOA

[13]

The flexibility in business design

[14]

To build SOA layers Services development in SOA Build an SOA

[15] [16]

[17] [18] [19] and [20]

Service composition To reduce the complexity To represent variability

concepts The domain decomposition, The modeling approach, The analysis of existing system Based on the purpose to identify BS Finer grained unit Syntactical and semantic analysis To obtain a set of applicative services the variability in service design variability

Approach Top-down

Goal orientation

Decomposition using goals and subgoals

then delimited between two variation points (gateways or event). We consider these variants as the process fragments. This approach can be used to extract a set of process fragments that encapsulate a business goal, from any model. Figure 4 a) presents generic business process model. According to the first step of our approach, we can extract different variants that exist in the previous model, Figure 4 b) depicts those identified variants. Figure 5 shows variants and variation points.

Bottom-up, Hybrid Hybrid approach: Top-down + Bottom-Up Top-down approach Heuristics

b)

a) Top down approach with twelve phases Approach with 5 phases Patterns

A3A3 A1A1

A4A4

A5A5

A2A2

Variant 2 A3A3

A4A4

A5A5

A6A6

A7A7

A8A8

A1A1 A2A2 Variant 1 A6A6

A7A7

A8A8

Variant 3

Fig. 4.

Business process model expressed with BPMN

fragments as generic as possible. The approach we propose is divided in two steps. The first step consists of analyzing the business process model represented with BPMN, in order to discover, identify and organize the variations that can be found on a given business process. While the second step consists on the description of business goal orientations. Figure 3 shows an overview of our approach.

A1 A1

A2 A2

A3 A3

Variant 1

Variant 2

Variation Points Business Process

A1

Fig. 5.

A2

Elicit variants and variation points Extracting Business Fragments Approach Describe business goals

Business fragment repository



Fig. 3.

Extracting Business Fragments Approach

A. Identifying fragments process •

Step 1- Elicit variants and variation points In the first phase, we describe the variation. Indeed, variability can be described in terms of variants and variations points. In the case of BPMN, the variation points, which are the place where the variation occurs, could be, Gateways, events ...etc, While the variants describe the object of variation. We attempt, in this first step, to detect the different variants that exist in a business process model. Considering that variants are generally alternative paths of execution in a workflow, they are

Variants and variation points

Variants and variation points are essential inputs for performing the process identification. However, this information itself is not sufficient to really delimit business fragments in order to fulfill the reuse of these fragments in other business process. So, in addition to the use of variability, a definition of variants goals seems to be necessary to really delimit a business process fragment and make it easier to reuse. Step 2- Describe business goals The variants resulted from step 1 should fulfill a particular business goal. Goals are the reason of being of a business system. They are established by actors to comply with business interests and needs demanded by the environment [21]. So, in this step, we analyze, understand and detect different business subgoals related to extracted variants. We attempt to link the identified variants from the previous phase to a specific business goal. Goal orientation is used for supporting business fragments identification in order to fulfill consumers’ requirements. Figure 6 shows each extracted variants with its business goal. It’s a textual documentation that should facilitates the reuse of the extracted business fragments.

Business Goal 1

Variant 1

Variant 2

Business Goal 2

Fig. 6.

Business Goals

With a specific definition of business goal, the reuse of such business fragments become much easier. After the definition of business goals, the obtained fragments constitute a set of business elements that can be grouped in a library. This library is considered as a repository that contains reusable business elements. The business analyzers can then consult this repository anytime they want to create or update their business processes. B. Case study In order to validate the application of our approach, we use a case study from bank domain. Figure 7 depicts a part of the Credit Application Process. A Credit Application process begins with the recording of the application where the client expresses an interest in acquiring credit. This is followed by an analysis or study of the credit application and finally we find the activities needed to either disburse the credit or to notify the client in case of rejection [22]. According to the steps of our proposed approach, we can extract the business fragments that are delimited between two gateways or a gateway and an Event provided that the process fragments identify a specific business goal. Figure 8 presents the application of our approach on the example in Figure 7. Applying our approach, we could extract 11 variants; For example, variant 1 contains two activities which fulfill a specific business goal related to the collection of client information, variant 2 is an activity which refers to check black list... etc. This result is grouped in a repository that contains a set of business fragments for further reuse. C. Discussion Our approach is part of an ongoing work. In this way, it may present some limitations related to specific example of business process modeled in BPMN. Indeed, a validation for our approach with more complex processes seems to be necessary to really experiment it performance. This may give us a clear vision on the complexity that the approach can reach. In fact, we believe that the complexity is relative to the volume of business model especially the number of variation points and variants that exist in those models. V. C ONCLUSION AND F UTURE WORK The reuse of existing business parts offer a solution to the business process flexibility and business agility for the

Information System. The aim of this paper is the extraction of business process fragments from the business process model. The proposed approach is based on variability in business process model using BPMN. Variability is specified in terms of variation points and variants. Our approach also takes into consideration the business goal of the extracted business fragments. This approach seems to fill the lack of flexibility and business agility by the reuse of business process extraction results. In fact, the obtained business process fragments are reusable elements that can be used to satisfy the new business requirements for another business process. As prospects of this work, it will be necessary in a much more depth future work to focus on the way to encapsulate these business processes’ fragments into business services model. Indeed, business services are a piece of business process. They are existing semantic components that can be selected and composed to define new business processes tailored to companies needs [23]. A set of generic business services can be grouped in a repository that contains reusable business elements. The future work will also focus on the composition of existing business services in order to create a new business process or to adapt a functional one. This work is part of a project aiming the connection of three business concepts which are: business component, business process and business service. The purpose is to design a modular architecture of an information system based on these concepts. R EFERENCES [1] B. Weber, M. Reichert, S. Rinderle-Ma, and W. Wild, “Providing integrated life cycle support in process-aware information systems,” Int. J. Cooperative Inf. Syst., vol. 18, no. 1, pp. 115–165, 2009. [2] R. Saidi, A. Front, D. Rieu, M. Fredj, and S. Mouline, “Componentbased development: Extension with business component reuse,” in RCIS, 2009, pp. 165–176. [3] E. Santos, J. Pimentel, J. Castro, J. S´anchez, and O. Pastor, “Configuring the variability of business process models using non-functional requirements,” in Enterprise, Business-Process and Information Systems Modeling, ser. Lecture Notes in Business Information Processing. Springer Berlin Heidelberg, 2010, vol. 50, pp. 274–286. [4] OMG, http://www.omg.org/spec/BPMN/2.0/, 2012. [5] G. Koliadis and A. Ghose, “A conceptual framework for business process redesign,” in Enterprise, Business-Process and Information Systems Modeling, ser. Lecture Notes in Business Information Processing. Springer Berlin Heidelberg, 2009, vol. 29, pp. 14–26. [6] R. Deneck`ere and E. Kornyshova, “Process line configuration: An indicator-based guidance of the intentional model map,” in Enterprise, Business-Process and Information Systems Modeling, ser. Lecture Notes in Business Information Processing. Springer Berlin Heidelberg, 2010, vol. 50, pp. 327–339. [7] J. van Gurp, J. Bosch, and M. Svahnberg, “Managing variability in software product lines,” Landelijk Architectuur Congres, Amsterdam, 2000. [8] R. Saidi, M. Fredj, S. Mouline, A. Front, and D. Rieu, “Variability modeling for business component customization,” in ISCC, 2008, pp. 730–735. [9] M. Galster and P. Avgeriou, “The notion of variability in software architecture: results from a preliminary exploratory study,” in Proceedings of the 5th Workshop on Variability Modeling of Software-Intensive Systems, ser. VaMoS ’11. New York, NY, USA: ACM, 2011, pp. 59–67. [10] F. Bachmann and L. Bass, “Managing variability in software architectures,” in Proceedings of the 2001 symposium on Software reusability: putting software reuse in context, ser. SSR ’01. New

Fig. 7.

The Credit Application Process [22]

Applicant Financial State ?

Variant 3 Check Credit bureau Yes

Rejected Check result ? Loan study

Rejected

Client OK

Variant 1 Record Loan Application Information

Ok

Check credit bureau

Check if existing Client

No

Application is Client?

Check Black list

Variant 5 Rejected

Result ?

Variant 2

Inform reason for rejection

Loan study

Ok

Variant 6

Application Approved ?

Variant 4

No

Inform customer of rejection

Inform customer of rejection

Yes Check Information Client

Check Black list

Inform reason for rejection

Variant 8

Verify Disbursement Documents

Disbursement by transfert to account

Transfer to account Confirm result to customer

Variant 11 Variant 9 Proceed to disbursement

Complete Disbursement Information Variant 7

Disbursement by check

Issue check

Confirm result to customer

Disbursement Media

Variant 10

Disbursement by transfert to loan account

Disbursement by check

Disbursement by transfert to loan account

Fig. 8.

[11]

[12] [13]

[14] [15]

[16]

[17]

[18]

Extracted Variants with their business goals

York, NY, USA: ACM, 2001, pp. 126–132. [Online]. Available: http://doi.acm.org/10.1145/375212.375274 A. Arsanjani, Service-oriented modeling and architecture: How to identify, specify, and realize services for your SOA, Available at: http://www.ibm.com/developerworks/library/ws-soa-design1/, 2004. A. Arsanjani and A. Allam, “Service-oriented modeling and architecture for realization of an soa,” in IEEE SCC, 2006, p. 521. K. Boukadi, L. Vincent, C. Ghedira, and Z. Maamar, “The contextual service oriented analysis and design,” Service Intelligence: The next wave of Service Computing (IJOCI), vol. 1, no. 2, pp. 1–29, Jun. 2010. [Online]. Available: http://liris.cnrs.fr/publis/?id=4797 M. P. Papazoglou, “What’s in a service?” in ECSA 2007, Springer-Verlag Berlin Heidelberg. Springer, 2007, p. pp. 11 28. L. G. Azevedo, F. M. Santoro, F. A. Bai˜ao, J. de Souza, K. Revoredo, V. Pereira, and I. Herlain, “A method for service identification from business process models in a soa approach,” in BMMDS/EMMSAD, 2009, pp. 99–112. T. Erl, Service-Oriented Architecture: Concepts, Technology, and Design. PRENTICE HALL PROFESSIONAL TECHNICAL REFERENCE, July 2005. S. H. Chang and S. D. Kim, “A service-oriented analysis and design approach to developing adaptable services,” in IEEE SCC, 2007, pp. 204–211. M. L. Rosa, P. Wohed, J. Mendling, A. H. ter Hofstede, H. A. Reijers,

[19] [20]

[21] [22] [23]

and W. M. van der Aalst, “Managing process model complexity via abstract syntax modifications,” IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS, 2011. E. Santos, J. Castro, J. Sanchez, and O. Pastor, “A goal-oriented approach for variability in bpmn,” in Workshop em Engenharia de Requisitos 2010 Cuenca, Equador, 2010. S. Liaskos, A. Lapouchnian, Y. Yu, E. Yu, and J. Mylopoulos, “On goalbased variability acquisition and analysis.” in Proceedings of the 14th IEEE International Conference on Requirements Engineering (RE’06). Minneapolis, Minnesota: IEEE Computer Society, September 2006. J. A. M. Calder´on and J. B. Albornoz, “Bmm: A business modeling method for information systems development,” CLEI Electron Journal., vol. 7, no. 2, 2004. Bizagi, http://www.bizagi.com/eng/downloads/BPMNbyExample.pdf, 2012. C. CAUVET and G. GUZELIAN, “Business process modeling : A service-oriented approach,” in Proceedings of the forty first Annual Hawaii International Conference on System Sciences HICSS-41, C. S. Press, Ed., 2008.