Measuring Size of Business Process From Use Case Description

Kanjan Dhammaraksa Software Systems Engineering Laborator

Department of Mathematics and Computer Science, Faculty of Science, King Mongkut’s Institute of

Technology Ladkrabang,Bangkok, Thailand

s9062908@kmitl.ac.th

Sarun Intakosum Software Systems Engineering Laborator

Department of Mathematics and Computer Science, Faculty of Science, King Mongkut’s Institute of

Technology Ladkrabang,Bangkok, Thailand kisarun@kmitl.ac.th

Abstract— The purpose of this paper is to present a new size metric for business process measurement. This metric aims to measure size of process from use case description. The metric consists of four series to support four perspectives of business process: functional, behavioral, informational and organizational. In addition, the guidance for pointing to related use case elements is included in each series. In this paper, each size of perspective which measured from the new metric can use for indicating the number of business process elements are represented by UML-activity diagram. Although the example of the metric is only one, it is possible to apply for another modeling method such as BPMN, Petri Net and EPC.

Keywords- Size metric, Business process, Use case description

I. INTRODUCTION

A size metric is a standard metric for identifying size of business process (BP). It also is a primary factor to guarantee the successful of business process development. However, it is difficult to define an appropriate size metric for business process. The major reason is that a BP has four perspectives [1] that should be concerned; functional, behavioral, informational and organizational. Unfortunately, the existing size metrics [8][11] are based on the diagram-based modeling methods (BPMN, EPC, UML-Activity Diagram). Almost of the diagrams tend to ignore some perspective, especially the organizational perspective. Therefore, this existing BP metrics could not support all perspectives. In order to solve the problem, this paper defines a new size metric that can support all perspectives. The metric is transformed from a use case description which is a general tool for capturing related information of all perspectives. Moreover, this paper prepares the guidance for each series. This guidance can help the metric user to find the use case elements that will be counted. The remaining contents of this paper can be discussed as follows. Section II is about the related background in the fields of business process. Section III presents the metric and guidance for measuring size from a business process use case description (BPUCD). Section IV gives an example of the method. Afterwards, the conclusion and future works are presented in the final section (V).

II. BACKGROUND

A. Business process(BP) BP [4][18][19] is the collaboration between a set of

activities and their resources under organization for satisfying the business requirements. There are four perspectives [1]; functional, behavioral, organizational, and informational. First, the functional perspective shows what process elements are working and flows of information entities related to it. Second, the behavioral perspective focuses on the sequence of process elements and its behaviors (feedback loops, interaction, etc). Third, the organizational perspective shows the organization process elements such as place, person, goal, and others relevant. Finally, the informational perspective illustrates the information entities that relevant with the process. Today, most of the BP researches are modeling methods [3][4][16][21]. One method is the use case description. Use case is not a popular tool for the BP at the initial time. However, many recently researches such as Selioukova [20] , Nawrocki [17] and Moreover, J. García Molina et. al.[12] support the concept. The next section introduces an available use case description format for the business process.

B. Business process use case description (BPUCD) Use case description is a semiformal format for

describing software specification. It is used to capture functional requirements, manage and trace all artifacts in SDLC. In the context of BP, UC is used for describing process specification such as activities, flow, information and process organization. BPUCD is a text-based modeling method that differs from other BP modeling method such as UML-Activity Diagram (UML-AD), BPMN, EPC and Petri net. Furthermore, BPUCD can supports for planning and analyzing phases that other descriptions could not support. Currently, an available BPUCD have four formats are:

Cockburn’s format [2] is a fully dresses of use case. It is widely used in many fields of software development. This format has 14 elements to support the four dimensions of

_____________________________ 978-1-4244-4520-2/09/$25.00 ©2009 IEEE

software development; purpose, context, multiplicity and structure.

The RUP Project [3] defines use case template for a tier project. RUP added new element to describe flow of events. RUP template is shown in table I.

TABLE I. THE RUP’S USE CASE TEMPLATE

RUP Template 1. Use case Name

1.1 Brief Description 1.2 Actions 1.3 Triggers

2. Flow of Events 2.1 Basic Flows 2.2 Alternative Flows

2.2.1 <First Alternative Flow> 2.2.2 <Second Alternative Flow>

3. Special Requirements 3.1 <First special requirements> 4. Pre-Conditions 4.1 <Pre-Condition 1> 5. Post-Conditions 5.1 <Post-Condition 1> 6. Extension Points 6.1 <Extension Point 1>

Most use case formats only support behavioral

perspective, except in a Coleman’s use case format [7]. He defined his format to nearly the activity diagram for supporting the structure perspective.

TABLE II. COLEMAN’S USE CASE TEMPLATE

Use case 2. Repairing_Cellular_Networkhistory created 1/5/98 Derek Coleman, modified 5/5/98. Description Operator rectifies a report by changing parameters of a cell. sources [Operating Manual 1993], [Jones 1998]. Assumptions Changes to network are always successful when applied to a network. Actors Operator (primary) Cellular network Field maintenance engineer Steps 1. Operator notified of network problem. 2. Operator starts repair session. 3. REPEAT 3.1 Operator runs network diagnosis application. 3.2 Operator identifies cells to be changed and their new parameter values. 3.3 IN PARALLEL 3.3.1 Maintenance engineer tests network cells || 3.3.2 Maintenance engineer sends fault reports. UNTIL no more reports of problems 4. Operator closes repair session. Variations #1. System may detect fault and notify operator or Field maintenance engineer may report fault to Operator.Non-Functional Performance Mean: time to repair network fault must be less than 3 hours. Fault Tolerance: A repair session must be able to tolerate failure of Operator’s console. Issues What are the modes of communication between field maintenance engineer and operator?

Table II is an example of Coleman’s format. It uses if-else, REPEAT-UNTIL and IN PARALLEL statement to describe the use case.

ebXML[5] applies the UMM model method in the business process analysis worksheets. ‘Begin When’ and ‘End When’ are elements for representing an event of process. Use case of ebXML worksheet can directly support the BP description.

In order to compare various use case formats, four process perspectives will be consider. First, the use case step is an element for showing the functional perspective. Second, the behavioral perspective can be found as an ordering number and a marking-word in the steps. In the worst case, user might searches the behavioral perspective in the sentence. However, Coleman’s format is the simplest format to identify this perspective by using his marking words. Third, the informational perspective can be seen in the use case step and some parts of pre/post condition. Finally, the organizational perspective can be represented by various use case elements such as name, actor, role, goal, source, fault tolerance, stakeholders & interests. Cock burn’s format has more effective for supporting this perspective than other formats.

C. Software metric Metric is a standard term for software measurement. It is

used to understand, control and improve a software product. The available researches on BP metrics can be grouped as follows; size metrics [8][11], complexity metrics [11][12][13][14][15], cohesion and coupling metrics[9][10], and another metrics. For this paper will present only the BP size metrics.

In BP, size metric is used to identify the number of process elements such as the number of activities, connector types and flows. The simplest size metric for the BP is the proposed metric by Cardoso [11]. The research proposes three metrics based on the LOC metric; number of activities in a process (NOA), number of activities and control-flow (NOAC) and number of activities, joins, and a split in a process (NOAJS). Another example of size metric is the metric proposed by Rolón [8] that used to evaluated complexity of the BPMN meta-model. However, all of the mention metrics can not fully indicates size of all process perspectives.

III. SIZE METRIC OF BUSINESS PROCESS USE CASE

The purpose of this section is to show the size metric for measuring size of the business process. For this approach aims to find size of business process from use case description. This metric consists of four series; functional, behavioral, informational and organizational. The guidance for identifying the determining the use case elements to count is also provided for each series.

A. Functional metric series In this series, the size of use case is considered from the

number of activities. The activities are found in the use case flows; main flow, extension flow, alternative flow, option flow, variation flow and exception flow. In general, the

activity should be completely described in one step of BPUCD. In other words, the activity means one step of BPUCD In addition, the metric user should concerns that some activities may contain other activities. This paper defines four metrics to measure size of a process for functional perspective. As shown in table III.

TABLE III. METRICS FOR FUNCTIONAL PERSPECTIVE

Metric DescriptionNOUCA Number of use case activity

(NOUCAuser+ NOUCAsystem)NOUCAuser Number of user activity NOUCAsystem Number of system activity NOsubUCA Number of sub-use case activity

From the table, the activity is divided into two types; user and system. These activities are activated by user and system respectively. The number of each type can be measured by NOUCAuser and NOUCAsystem. In addition, NOsubUCA is to measure size of sub-activities in a process. The result from NOsubUCA can be used for the BP management. For example, the developers may decide to split sub-activities too a new process if it is considered to large.

B. Behavioral metric series The behavioral perspective can be supported by the

number of connectors among activities. This series has four metrics that are shown in table IV.

TABLE IV. METRICS FOR BEHAVIORAL PERSPECTIVE

Metric Description NOSeq Number of sequential NOAND Number of AND connector NOOR Number of OR connector NOXOR Number of XOR connector

One common problem of text-based modeling is it is not clear to present the connectors. As a result, three tasks to identify size of process in BPUCD are also defined by this paper as follows.

Task1, determine sequential flow and the connector types between activities in the main flow. Task2, determine the connector types between the main flow and other flows. Task3, determine sequential flow and the connector types between activities in each other flows. In order to count number of the connectors, the following

guidance can be followed. The size of the connector for task 1 and task 3 can be

measured as follows. - NOSeq counts only sequential steps from any sentence

of steps. - NOAND counts the AND connectors. A marking word

that represents this connector is ‘AND’. ‘AND’ will be counted if it describes a relationship between activities. Other marking words that can be included are ‘parallel’ and ‘concurrence’.

- NOOR metric counts the OR connector in the steps. An ‘OR’ and ‘IF ELSE’ are the marking words to represent the OR connector.

-NOXOR metric counts the XOR connector in the steps. For example, iteration is one decision behavior which has exactly one path is activated. Distinctly, one path of the decision is repeated until its condition is valid. The marking words for this metric are FOR, WHILE and DO UNTIL.

NOXOR is also used to count the connector among main flow, extension flow, alternative flow, and exception flow, while NOOR concern on the connector among main flow, option and variation flows.

C. Informational metric series This series count the number of data in use case

elements. The data consists of input, output, and inquiry. Table V summaries this metric as follows.

TABLE V. METRICS FOR INFORMATIONAL PERSPECTIVE

Metric DescriptionNOIn (NOIn + NOEXIn) Total number of inputs of use case NOOut (NOIOut + NOEXOut) Total number of outputs of use case NOQ Number of inquiry information TOIOQ (NOIn+NOOut+NOQ) Total number of input output and

inquiry information.

From the table V, the metric has four sub-series; NOIn, NOOut, NOQ and TOIOQ. The sub-series metric uses for counting size of three data types are input, output and inquiry respectively. This paper defines the guidance for identifying both of data types in the use case.

NOIn counts from input data are available in the use case element; various flows and pre-condition element. Input data are in various flows is an internal input that is produced by internal activity and actor.

NOOut counts from output in use cases elements; various flows and post-condition element.

Other messages between elements are included in the inquiry data NOQ.

D. Organizational metric series In this series, the events and resources in the use case

description are topics of interest. As shown in table VI.

TABLE VI. METRICS FOR ORGANIZATIONAL PERSPECTIVE

Metric DescriptionNOA (NOPA+NOSA) Number of Actors NOPA Number of Primary Actors NOSA Number of Secondary Actors NOE Number of Events NOEIn Number of Internal Events NOEEx Number of External Events NOIR Number of Internal Resources NOEXR Number of External Resources NOR (NOIR+NOEXR) Total number of Resources

The table VI shows the metrics to measure size of the process in organizational perspective. NOA is to measures number of actors. It has related two metrics; NOPA and NOSA. The primary actors are counted by NOPA, while the secondary actors are counted by NOSA. NOE is used to count the number of events. NOEIn and NOEEx are used together to count internal and external events. ebXML’s use case format supports this series. Trigger and pre/post condition defined in some formats can be used to describe events. NOR measure size of a process from resources. NOIR and NOEXR are two related metrics that support internal and external resources respectively.

IV. EXAMPLE

This section shows an example of the proposed size metric. A case study is a registration use case. It is a part of the tendering system [6]. This system uses the ebXML format for describing its specifications. The registration starts its work by receives registration form from Tenderers. It returns an examination result back to Tenderers after it process is completed. The details of this use case can be shown in table VII.

TABLE VII. REGISTRATION USE CASE

Use case name Registration Preconditions None Begins When Tenderers apply for registration. Definitions Tenderers apply for registration.

Procuring entity receives registration application.Procuring entity examines registration application. Procuring entity notifies tenderers of examination result.Tenderers receive examination result.

Ends When Tenderers receive examination result. Exceptions Procuring entity does not receive registration application

from tenderers. Tenderers do not receive examination result from procuring entity.

Postconditions Tenderers get examination result.

The registration use case is measured by the proposed metric. Moreover, finding the elements numbers can identify with guidance which presented in the previous section. The measured results for this example are shown in table VIII.

TABLE VIII. THE METRIC RESULT OF THE REGISTRATION USE CASE

NO. Metric Result NO. Metric Result 1 NOUCS 7 14 NOPA 2 2 NOUCSuser 3 15 NOSA - 3 NOUCSsystem 4 16 NOE 2 4 NOsubUCS - 17 NOEIn 1 5 NOseq 4 18 NOEEx 1 6 NOAND - 19 NOIR - 7 NOOR - 20 NOEXR - 8 NOXOR 2 21 NOR - 9 NOIn 1 10 NOOut 1 11 NOQ - 12 TOIOQ 1+1=2 13 NOA 2

The first to fourth metrics show the number of activities in the BPUCD. We can conclude there all three user steps and four system steps. In this use case has four sequential flows and two XOR connectors that can be measured by the fifth to eighth metrics. The ninth to twelfth metrics show that one internal input and one internal output. The remaining metrics showed organizational element that two primary actors and two events. These results can be grouped into four perspectives as shown in table IX.

TABLE IX. SIZE OF REGISTRATION USE CASE IN FOUR PERSPECTIVES

Perspective SizeFunctional perspective 7Behavioral perspective 6Informational perspective 2Organizational perspective 4Total size of process 19

This result, it can be used by many activities in the business process development such as planning, managing, estimating and reusing. For example, the result in table VIII and table IX can be used estimate the number of elements of the BP model under development.

Procuring EntityTenderers

Apply for Registration Receive Registration Application

Examine Registration Application

Notify Examination ResultReceive Examination Result

Registration Application : <unspecified>

Examination Result : <unspecified>

not receive registration application

receive registration application

not receive examination

result

receive examination result

Notify to Tenderer

Notify to Procuring Entitiy

Figure 1. The registration activity diagram

The figure 1 shows the registration function modeled by UML-AD. The number of elements in this model comes from the result in the table VIII and table XI. For example, the size of NOUCS is seven, therefore the number of activities in The UML-AD is also seven. The number of use case actors (NOA) effects to the number of swim lanes in UML-AD. Moreover, the numbers of XOR connector (NOXOR) are indicated with two decision notations in UML-AD.

V. CONCLUSION AND FUTURE WORK

Size metric is a standard tool for measuring size of BP. Size of BP which comes from the metric can improve the performance of BP management. However, the existing metrics [8][11] can support only two perspectives; functional and behavioral. One reason is this metrics were design from the diagram-based models that usually ignore some perspectives. To achieve the metric that supports all perspectives, this paper defines the new size metric based on use case description. The metric consists of four series for four perspectives; functional, behavioral, Informational and organizational. Each series has the guidance to help for identifying the related use case elements. The example in this paper, the number of BP elements identified by the proposed metric is used to draw with the UML-AD. The guidance is also created to help for identifying the use case element that will be used in the new size metric. Certainly, it is possible to apply the proposed metric to any common modeling methods such as BPMN, Petri Net and EPC.

REFERENCES

[1] B. Curtis, M. Kelner, J. Over, Process Modeling,Communications of the ACM, Vol. 35, No. 9, 1992.

[2] B. Henderson-Sellers, D. Zowghi, T. Klemola, and S. Parasuram, “Sizing Use Cases: How to Create a Standard Metrical Approach”, Springer, 2002, pp. 409-421.

[3] B. MacIsaac, An overview of the RUP as a process engineering platform, Process Engineering for Object-Oriented and Component-Based Development. Procs. OOPSLA, 2003, 43-52.

[4] Business Process Management Initiative (BPMI), “Business Process Modeling Notation (BPMN)”, Version 1.0 - May 3, 2004, Available: www.omg.org.

[5] Business Process Team, “Business Process Analysis Worksheets &Guidelines v1.0”, 2001, Available:http://www.ebxml.org/specs/bpWS.pdf.

[6] CEN “Business requirements specification - Cross industry e-Tendering process” 2007, Available:http://www.evs.ee/product/tabid/59/p-138330-cwa-156662007.aspx.

[7] Coleman, Derek, “A Use Case Template: Draft for discussion”, Fusion Newsletter, April 1998, Available: http://www.hpl.hp.com/fusion/md_newsletters.html.

[8] Elvira Rolón, Francisco Ruiz, Félix García, Mario Piattini,” Applying Software Metrics to evaluate Business Process Models”, CLEI electronic journal Volume 9,2006,pp.1-15.

[9] H.A. Reijers, “A Cohesion Metric for the Definition of Activities in a Workflow Process”, Proceedings EMMSAD, 2003, pp. 116-125.

[10] Irene Vanderfeesten, Jorge Cardoso, Hajo A. Reijers, “A weighted coupling metric for business process models”, Proceedings of the CAiSE'07 Forum, 2007. pp. 41-44.

[11] J. Cardoso, J. Mendling, G. Neumann, and H.A. Reijers,” A Discourse on Complexity of Process Models (Survey Paper)”, Springer, 2006, pp. 115–126.

[12] J. García Molina, M. José Ortín, Begoña Moros, Joaquín Nicolás, and Ambrosio Toval, “Towards Use Case and Conceptual Models through Business Modeling”, Springer, 2000, pp. 281-294.

[13] Jorge Cardoso, “Control-flow Complexity Measurement of Processes and Weyuker’s Properties”, 6th International Enformatika Conference. Transactions on Enformatika,

Systems Sciences and Engineering, Vol. 8, Hungary, 2005, pp. 213-218.

[14] Jorge Cardoso, “Process control-flow complexity metric: An empirical validation”, IEEE International Conference on Services Computing (SCC'06), 2006, pp. 167-173.

[15] Jorge Cardoso, “Approaches to Compute Workflow Complexity”, Dagstuhl Seminar Proceedings 06291 The Role of Business Processes in Service Oriented Architectures, Germany, 2006, pp.1-15.

[16] Manolis Koubarakis1 and Dimitris Plexousakis2“A Formal Model for Business Process Modeling and Design ”, Springer-Verlag Berlin Heidelberg , 2000,pp.142-156.

[17] Nawrocki, Tomasz Nedza, Miroslaw Ochodek, Lukasz Olek, “Describing Business Processes with Use Cases”, Business Information Systems, Proceedings of BIS 2006, Poland,2006,pp13-27.

[18] Papazoglou, M.P. and W.J. van den Heuvel, “Business Process Development Lifecycle Methodology”. to appear in Communications of ACM.2006.

[19] Wikipedia, “Business Process”, Available: www.wikipedia.org.

[20] Y. Selioukova, “Business Process Modeling in Software Requirements Engineering for Small and Medium Software Projects”, The Departmental Council of the Department of Information Technology, Finland, 2001.

[21] YAN Zhi-junI, WANG Tian-mei2, “Coupling Measurement of Interorganizational Processes Based on Petri Nets”, IEEE, 2006, pp.591-595.