Keywords

1 Introduction

Business process modeling is a complex task where the knowledge of different people is combined, for example business specialists, stakeholders, and analysts [1]. The tacit knowledge of the business experts is an usual challenge during the business process modeling [2].

For the software development, business process models are a useful artifact for the software developers in order to understand the business of the companies [3,4,5]. Hence, to obtain free of errors user requirement specifications in the first stages of the information systems development process, the modeling of business processes is essential [6,7,8]. However, several studies provide evidences that demonstrate the existence of errors in business process model usually [7, 9]. The wrong modeling of business processes and its lack of correspondence with the system design are usual factors for the systems failure [10].

In spite of the relevance of process modeling, often is carried out by inexpert modelers [11]. Therefore, the quality of the models is affected in terms of flexibility and completeness [12, 13]. Even, sometimes modelers are not aware of the importance of their work to prevent that errors in these models from spreading to other stages of the software development process [14, 15].

Since the importance of the business process modeling for the software development, its evaluation is critical for the success of the process. In that sense, the understandability is a key quality indicator of business process models [16]. The understandability of models can be related to structural properties of its graphical elements [6]. Some practical guidelines to evaluate the understandability of business process models have been proposed [15]. However, it is not easy to find proposals that support the automatic application of these practical guidelines.

On the other hand, ontologies have become in a suitable technology to represent, validate, and analyze business processes [17]. The description of business processes in an ontology helps to detect model inconsistencies automatically and avoids the propagation of errors to system models [18].

This paper aims to describe an ontological model to assess business process descriptions. The assessment is based on practical guidelines to check the structural properties and the understandability of models [15]. Some specifications to automatically apply these guidelines in the ontology were implemented. To ensure the quality of the ontology, a solid methodology was adopted. Likewise, a procedure to evaluate the ontology was applied.

The rest of the paper is organized as follows. In Sect. 2, the practical guidelines and the basic technologies to develop the ontology are introduced. In Sect. 3, an ontological model to assess business process descriptions is described. In Sect. 4, some examples to illustrate the applicability of the approach are presented. Section 5 presents the conclusions and future work.

2 Background

Several works that deal with the quality of business process descriptions were analyzed [4, 6, 19,20,21,22,23,24]. Some authors have proposed practical guidelines to enhance the quality of the business process descriptions [6, 25, 26]. The application of these practical guidelines may reduce errors and improve the understandability of the business process models. However, some practical guidelines are not support by the modeling tools. Therefore, an alternative to support the application of these practical guidelines may be a useful contribution.

Several authors foster the adoption of ontologies to represent and validate business process descriptions. An ontological approach may support the identification of errors and improve activity labels of process models [2, 17, 18]. Therefore, we have adopted an ontological approach to support the application of practical guidelines to assess business process descriptions.

2.1 Quality Practical Guidelines

Table 1 gives ten practical guides related to the size of business process models. These guidelines allow to classify business process models according to the number of modeling elements they have [21, 27].

Table 1 Practical guidelines regarding size
Full size table

2.2 Methodology and Tools to Support the Development of the Ontology

The selection of a proper methodology is a key step to develop an ontology. To guide the development of the ontology presented in this paper, the methodology of Noy and McGuinness was adopted [28]. This is a solid methodology that has been widely adopted and includes the following steps:

  • Determine the domain and scope of the ontology.

  • Consider reusing existing ontologies.

  • Enumerate important terms in the ontology.

  • Define the classes and the class hierarchy.

  • Define the properties (called relationships or slots) of the classes.

  • Define facets and/or restrictions on slots or relationships.

  • Define instances.

Web Ontology Language (OWL) [Ref] was adopted to represent the ontology. OWL is based on description logics and includes the operator’s intersection, union, and negation which are very useful to represent knowledge. Furthermore, the models represented in OWL can be analyzed by reasoners which automatically check the consistency and infer new knowledge. The reasoner Pellet was adopted to analyze our ontology. To implement the ontology, the tool Protégé [Ref] was adopted. Protégé is multiplatform and open-source, and it has a flexible and extensible architecture. The language OWL and the reasoner Pellet are supported by Protégé.

3 An Ontological Model to Support the Application of Practical Guidelines to Assess Business Process Description

To develop the ontology, the steps defined in the methodology of Noy and McGuinsess were carried out. Below the main results are described.

Step 1. Determine the domain and scope of the ontology

The ontology has the purpose of assessing the quality of the business process descriptions applying practical guidelines. To achieve this objective, the ontology must be able of answering the following competence questions (CQ):

  1. 1.

    Does the process meet basic workflow patterns?

  2. 2.

    What activities are included in the process?

  3. 3.

    What processes have problem of size?

  4. 4.

    What processes have problem of morphology?

  5. 5.

    What processes are efficient?

  6. 6.

    What processes are inefficient?

  7. 7.

    What processes are very efficient?

  8. 8.

    What processes are very inefficient?

  9. 9.

    What processes are low efficient?

Step 2. Consider reusing existing ontologies

Concepts of the ontology described by Silega and Noguera were reused [18]. This ontology supports the description of business processes and includes specifications for its validation.

Step 3. Enumerate important terms in the ontology

The main terms are related with the components of a process such as activity, event, gateway, input, output, and others terms. Furthermore, terms related with the application of practical guidelines (see Table 1) to assess the models are considered.

Step 4. Define the classes and the class hierarchy

To define the classes of the ontology, three main elements were considered. First of all, we considered the concepts related to the representation of business process, for this regard, the concepts of the ontology developed by Silega [18], such as Processs, Activity, Event, and Gateway were reused. Likewise, this ontology includes classes such as Step and FlowElement to represent the flow of activities. Furthermore, we included classes to assess the processes based on the practical guide. For example, to classify the processes that do not fulfill some practical guideline related to the size, the class ProcessWithSizeProblem was included. The classes ProcessWithMorfologyProblem, ProcessEfficient, ProcessInefficient, ProcessVeryInefficient, and GatewayWithProblem are related to the application of the practical guidelines too. These last classes were declared as defined classes. Defined classes in OWL include a set of necessary and sufficient conditions, thus a reasoner can automatically infer their instances. Hence, the process with problems will be automatically identified. Figure 1 shows an excerpt of the class hierarchy.

Fig. 1
An illustration depicts the class hierarchy. It has the main components of object type, process, object, step, flow element, metrics, and state.

Classes hierarchy

Full size image

Step 5. Define the properties

Properties are the other core component of ontologies. Object properties and data properties are the two types of properties in an ontology. The object properties allow to represent a binary relationship between two individuals. Each object property has an inverse object property, for example, an Activity belongsTo a Process and a Process HasActivity an Activity. A total of 64 object properties in the ontology were defined. Table 2 gives some object properties related to the classes Process and Step.

Table 2 Examples of object properties
Full size table

After creating the properties, it is possible to declare some necessary and sufficient conditions to automatically classify the instances of the defined classes. For example, Fig. 2 shows the necessary and sufficient conditions to identify the processes that belong to the class ProcessWithSizeProblem.

Fig. 2
A table depicts the examples of object properties related to the classes, process, and setup. The three columns represent domain, object, and range.

Example of a set of necessary and sufficient conditions

Full size image

Other rules to assess the processes also have been implemented. In spite of the expressivity richness of OWL, some complex relations cannot be expressed. Therefore, the semantic web rule language (WSRL) was adopted to complement OWL.

Step 6 Define instances

An example to illustrate the creation of instances in the next section is presented.

4 Evaluation of the Ontology

Checking that the ontology fulfills its conditions as a logical-formal system is the first step to evaluate its quality. The reasoner Pellet confirmed that our ontology fulfills its conditions as a logical-formal system.

On the other hand, to demonstrate the applicability of our approach, some business processes in the ontology were described and assessed. The processes Process_Make-A_Deposit and Process-Example2 were modeled in the ontology and classified as a ProcessVeryEfficient while the process Process-Example1 was classified as ProcessWithSizeProblem because meets the necessary and sufficient conditions of this class. Figure 3 depicts a view of Protégé where the classifications carried out by the reasoner are displayed. This view shows the classifications for Process_Make-A_Deposit, Process-Example1, and Process-Example2. This examples answer the competence questions 4 and 7.

Fig. 3
A screenshot depicts the business process classification. The view has the classification for process-make-a-deposit, process-example 1 and 2.

Classification of business processes

Full size image

By means of this ontology, other practical guidelines can be verified. For example, it is possible to identify the gateways with multiple input and output flows. A process with this type of gateways should be classified as a process with problem of morphology. Figure 4 depicts an example of a process description with this problem.

Fig. 4
A state diagram depicts the process description with the problem of morphology. The gateway with a problem is classified as activities 1, 2, 3, and 4.

Model of a process with problem of morphology

Full size image

To identify the gateways with multiple input and output flows, some rules were specified. The gateways with this problem will be classified as GatewayWithProblem. Furthermore, we defined that if a processes has some GatewayWithProblem then it is classified as ProcessWithMorphologyProblem. After modeling in the ontology, the process of Fig. 4, the reasoner classified Gateway2 as a GatewayWithProblem (Fig. 5a). Since that Process-Example3 has to Gateway2, it is classified as a ProcessWithMorfologyProblem (Fig. 5b).

Fig. 5
An illustration depicts the process with the morphology problem. Gateway 2: gateway and gateway with a problem. Process-Example 3: process, process with a problem.

Classification of a process with problem of morphology

Full size image

5 Conclusions

The business process models are a useful instrument to understand the business of organizations. Likewise, it is a key artifact to design information systems. Therefore, assuring the quality of process descriptions is crucial to prevent errors in other stages of the software development process. Some quality practical guidelines to evaluate business process descriptions have been proposed. In this article, an ontological model to represent and assess business processes was introduced. The formalization of the process models through the OWL language allows verifying the problems related to non-compliance with the quality practical guidelines related to general complexity. The compliance of these practical guidelines improves the understanding between business experts, analysts, and the development team. The conditions of the ontology as a logical-formal by means of a reasoner were verified. Some examples to illustrate how the expressivity richness of OWL was exploited to represent and assess business process were presented.