# Extending Conceptual Schemas with Business Process Information

Authors: Marco Brambilla; Jordi Cabot; Sara Comai
Journal: Advances in Software Engineering
 (2010)

---

## Abstract

The specification of business processes is becoming a more and more critical aspect for organizations. Such processes are specified as workflow models expressing the logical precedence among the different business activities (i.e., the units of work). Typically, workflow models are managed through specific subsystems, called workflow management systems, to ensure a consistent behavior of the applications with respect to the organization business process. However, for small organizations and/or simple business processes, the complexity and capabilities of these dedicated workflow engines may be overwhelming. In this paper, we therefore, advocate for a different and lightweight approach, consisting in the integration of the business process specification within the system conceptual schema. We show how a workflow-extended conceptual schema can be automatically obtained, which serves both to enforce the organization business process and to manage all its relevant domain data in a unified way. This extended model can be directly processed with current CASE tools, for instance, to generate an implementation of the system (including its business process) in any technological platform.


---

## Body

## 1. Introduction

All software systems must include a formal representation of theknowledge of the domain. In conceptual modeling, this representation is known as the conceptual schema of the software system [1]. However, software development processes for complex business applications usually require the additional definition of a workflow model to express logical precedence and process constraints among the different business activities (i.e., the units of work).Workflow models are usually specified through dedicated languages (e.g., Business Process Management Notation–BPMN [2]) and implemented with the help of specialized workflow management systems (WFMSs), for example, see [3, 4], which are heavy-weight applications focused on the control aspects of the business process enactment. This is clearly the best option to manage large workflow models. However, in some cases organizations may prefer a more lightweight approach that does not require acquiring a specific workflow subsystem.This paper tackles the problem of defining a light-weight approach to the implementation of business processes within software applications, without the use of specialized WFMSs, which represents a relevant issue in several application scenarios. Indeed. alternative solutions to complete WFMSs can be preferred in case of simple business requirements, small organizations, or when the business process needs are going to be drowned into a larger system that is being implementedad hoc for the organization. In these cases, designing and implementing the workflow using the same methods, notations and tools used to develop the rest of the system can be convenient and cost effective for the organization.Along these development lines, some approaches have focused on the implementation of workflow models in specific technology platforms, as  relational databases (generally in the form of triggers [5]), Web applications (by means of hypertextual links and buttons properly placed in Web pages, thus restricting the user navigation [6]), or Web services (through transformation into Business Process Execution Language for Web Services–BPEL4WS [7] specifications). This way, the workflow definition becomes part of the system implementation and no specific workflow engine is required. However, these approaches can be hardly generalized to technologies different from the ones for which they have been conceived (e.g., to new technology platforms), make difficult a wider adoption of business processes within the organizations, and present some limitations regarding the supported expressivity for the initial workflow model and/or its integration with the conceptual schema.As an alternative, in this paper we propose a formalized model-driven development (MDD) approach for developing workflow-based applications and advocate for the automatic integration of the workflow model within the (platform-independent) conceptual schema. The resulting workflow-extended conceptual schema includes in a single schema both the business process specifications and the domain knowledge, providing aunified view of the system and allowing treating both dimensions in a homogeneous way when implementing, verifying, and evolving the system. The integration is done at the model level. Therefore, current modeling tools can be used to manage our workflow extended schema, no matter the target technology platform or the purpose of the tool (e.g., verification, code-generation, etc.).The rest of the paper is structured as follows: Section2 summarizes and motivates our approach and its advantages. In Sections 3 and 4 the conceptual schema, the workflow concepts, and our case study are illustrated. Section 5 introduces the normalization phase. In Sections 6 and 7 we provide the definition of the workflow-extended conceptual schema and of the (Object Constraint Language OCL [8]) process constraints, respectively. Section 8 sketches possible implementation strategies for this extended model. Section 9 portrays our prototype tool implementation. Then, Section 10 compares our approach with related work and in Section 11 we draw our conclusions and discuss future work.


## 2. Overview of the Proposed Approach and of its Benefits

Our MDD approach for developing workflow-based applications is sketched in Figure1: the designer specifies the conceptual schema (e.g., in UML) and the workflow model of the application (e.g., in BPMN), using the appropriate design tools. At this stage some links between the workflow model and the conceptual schema can be already identified. Typically, they represent the usage relationship that associates objects of the application domain to activities in the workflow model.Figure 1
MDD process for workflow-based applications.The workflow model may need a normalization transformation for homogenizing the notation and making it fit for the next (automatic) steps.The conceptual schema and the workflow model undergo to the integration transformation phase that produces theworkflow-extended conceptual schema. More specifically, given a conceptual schema c and a workflow model w, it is possible to automatically derive a full fledged conceptual schema c′ enriched with the types needed to record the required workflow information in w (mainly its activities and the enactment of these activities in the different workflow executions) and with a set of process constraints over such types to control the correct workflow execution. Several workflow models can be integrated with the same conceptual schema since the process constraints of each workflow model do not interfere. This is guaranteed by the construction process of the workflow-extended model. This extended schema can then be managed using any commercial UML CASE tool.The whole approach has been implemented in a prototype tool that automatically translates the workflow specifications into a set of types and constraints on the conceptual schema, according to a set of translation patterns described in the paper.The focus of the paper will be on the platform-independent transformations of the conceptual models; however, some ideas on how to implement the workflow-extended conceptual schema into target platforms will be provided. As reference models, throughout the paper we will use UML class diagrams for the representation of conceptual schemas and OCL constraints to represent the process constraints. For the workflow, we will adopt a particular business process notation, namely BPMN [2], for sake of readability and concreteness. Indeed, business analysts are well aware of business process modeling techniques but are not so familiar with software engineering notations and practices. Recently, BPMN and other domain-specific notation have been increasingly accepted in the field, thus we based our examples on a notation that business roles in the enterprises are familiar with.Our model transformations are based on the concepts and definitions specified by (Business Process Definition Metamodel BPDM [9]), a platform- and notation-independent metamodel for defining business processes. Since BPDM is a common metamodel for all business process notations (e.g., it includes all concepts of BPMN and UML activity diagrams), our approach can be used exactly in the same way when using activity diagrams or any other BPDM-compliant notation to model the workflows. The proposed approach is therefore general-purpose and is valid regardless of the adopted business process notation.


### 2.1. Motivation and Discussion

The main advantage of the proposed approach is that the workflow-extended conceptual schema includes in a single conceptual schema both the business process specifications and the domain knowledge. Since the workflow-extended model is automatically generated from the workflow model and the conceptual schema, aunified view of the system is hence available without any additional effort by the designer. This allows treating both dimensions in the resulting model in a homogeneous and consistent way when implementing, verifying, and evolving the system. Thanks to this unified view, our workflow-extended schemas enable the definition of more expressive business constraints, generally not allowed by common business process definition languages such as timing conditions [10] or conditions involving both business process and domain information.Moreover, since the integration of the workflow and conceptual schemas is done at the model level, the resulting workflow-extended conceptual schema is aplatform-independent model. Thanks to the current state of the art of model-to-model and model-to-text transformation tools, integrating different notations in the same approach (e.g., UML class diagrams, OCL, and BPMN) does not make a difference. Indeed, the extraction and integration process will simply consider models conforming to different metamodels (e.g., UML and BPDM). Anyway, the model transformations involved are straightforward and compliant with the MDD approach.Once the final workflow-extended schema is produced, it can benefit from any method or tool designed for managing a generic conceptual schema, no matter the target technology platform or the purpose of the tool, spawning from direct application execution, to verification/validation analysis, to metrics measurement, and to automatic code-generation in any final technology platform. Those methods do not need to be extended to cope with the workflow information in our workflow-extended schema, since it is a completely standard UML model [11]. In this sense, with our approach we do not need to develop specific techniques for workflow models nor to use specific tools for managing them.Finally, once (automatically) implemented (with the help of any of the current UML/OCL CASE tools offering code-generation capabilities), the workflow-extended conceptual schema ensures a consistent behavior of all enterprise applications with respect to the business process specification. As long as the applications properly update the workflow information in the extended model, the generated process constraints enforce that the different tasks are executed according to the initial business process specification.


### 2.2. Original Contributions of the Paper

To our knowledge, ours is the first approach that automatically derives a platform-independent conceptual schema integrating both domain and business process information in a unified view. A first version of this proposal has been published in [12]; however, this paper extends [12] in several directions. In particular, the main original contributions of this paper include the following.(i)
The introduction of a normalization phase to simplify the initial workflow models and extend the set of workflow patterns we can directly cover with our method.(ii)
A complete description of the process that allows obtaining the workflow-extended conceptual schema starting from the domain model and the workflow model.(iii)
An extended and refined version of the translation of process constraints, including also the management of the start, end, and intermediate events in the business process specification. Such events can represent different event types (message, exception, rule, timer, etc.).(iv)
The specification of different integration scenarios that can be used in the transformation process and a discussion on their trade-offs in terms of the complexity of the resulting extended schema and of the process constraints.(v)
The description of different implementation alternatives for the workflow extended schema towards target platforms.(vi)
The description of our tool implementation, supporting all the (automatic) model transformations.


## 2.1. Motivation and Discussion

The main advantage of the proposed approach is that the workflow-extended conceptual schema includes in a single conceptual schema both the business process specifications and the domain knowledge. Since the workflow-extended model is automatically generated from the workflow model and the conceptual schema, aunified view of the system is hence available without any additional effort by the designer. This allows treating both dimensions in the resulting model in a homogeneous and consistent way when implementing, verifying, and evolving the system. Thanks to this unified view, our workflow-extended schemas enable the definition of more expressive business constraints, generally not allowed by common business process definition languages such as timing conditions [10] or conditions involving both business process and domain information.Moreover, since the integration of the workflow and conceptual schemas is done at the model level, the resulting workflow-extended conceptual schema is aplatform-independent model. Thanks to the current state of the art of model-to-model and model-to-text transformation tools, integrating different notations in the same approach (e.g., UML class diagrams, OCL, and BPMN) does not make a difference. Indeed, the extraction and integration process will simply consider models conforming to different metamodels (e.g., UML and BPDM). Anyway, the model transformations involved are straightforward and compliant with the MDD approach.Once the final workflow-extended schema is produced, it can benefit from any method or tool designed for managing a generic conceptual schema, no matter the target technology platform or the purpose of the tool, spawning from direct application execution, to verification/validation analysis, to metrics measurement, and to automatic code-generation in any final technology platform. Those methods do not need to be extended to cope with the workflow information in our workflow-extended schema, since it is a completely standard UML model [11]. In this sense, with our approach we do not need to develop specific techniques for workflow models nor to use specific tools for managing them.Finally, once (automatically) implemented (with the help of any of the current UML/OCL CASE tools offering code-generation capabilities), the workflow-extended conceptual schema ensures a consistent behavior of all enterprise applications with respect to the business process specification. As long as the applications properly update the workflow information in the extended model, the generated process constraints enforce that the different tasks are executed according to the initial business process specification.


## 2.2. Original Contributions of the Paper

To our knowledge, ours is the first approach that automatically derives a platform-independent conceptual schema integrating both domain and business process information in a unified view. A first version of this proposal has been published in [12]; however, this paper extends [12] in several directions. In particular, the main original contributions of this paper include the following.(i)
The introduction of a normalization phase to simplify the initial workflow models and extend the set of workflow patterns we can directly cover with our method.(ii)
A complete description of the process that allows obtaining the workflow-extended conceptual schema starting from the domain model and the workflow model.(iii)
An extended and refined version of the translation of process constraints, including also the management of the start, end, and intermediate events in the business process specification. Such events can represent different event types (message, exception, rule, timer, etc.).(iv)
The specification of different integration scenarios that can be used in the transformation process and a discussion on their trade-offs in terms of the complexity of the resulting extended schema and of the process constraints.(v)
The description of different implementation alternatives for the workflow extended schema towards target platforms.(vi)
The description of our tool implementation, supporting all the (automatic) model transformations.


## 3. Conceptual Schemas

Aconceptual schema (also known as domain model) defines the knowledge about the domain that an information system must have to perform its business functions. Without loss of generality, we will represent conceptual schemas using UML [11].The most basic constructors in conceptual schemas are entity types (i.e., classes in the UML terminology), relationship types (i.e., associations) and generalizations.Anentity type  E describes the common characteristics of a set of entities (i.e., objects) of the domain. Each entity type E may contain a set of attributes.A binaryrelationship type  R has a name and two participants. A participant is an entity type that plays a certain role in the relationship type. Each relationship (i.e., link) between the two participants represents a semantic connection between the entities. A participant in R may have a minimum and maximum cardinality. The minimum cardinality min between participants p1 and p2 in R indicates that all entities of E1 (type of the participant p1) must be related at least with min entities of E2 (type of the participant p2). A maximum cardinality max between p1 and p2 in R defines that entities of E1 cannot be related with more than max entities of E2.Ageneralization is a taxonomic relationship between a more general entity type E (supertype) and a set of more specific entity types E1,…,En (subtypes).As an example, Figure2 shows a conceptual schema, represented in UML, meant to (partially) model a simple e-commerce application. It consists of the entity types Product, Quotation, QuotationLine(to record the details of the products included in the quotation), and Order(an order is generated by each quotation accepted by the customer, and then, its quotation lines are referred to as order lines). According to the cardinality constraints in the relationship types, all quotation must include at least one product and orders must be of a single quotation.Figure 2
A partial conceptual schema for an e-commerce application.


## 4. Business Processes Concepts

Several visual notations and languages have been proposed to specify workflow models, with different expressive power, syntax, and semantics. Without loss of generality, in our work we have adopted theWorkflow Management Coalition terminology, the Business Process Definition Metamodel [9] (BPDM), and the Business Process Management Notation [2] (BPMN).BPDM is a standard proposed by OMG for representing and modeling business processes independent of any notation or methodology. This is done by proposing a unified metamodel that captures the common meaning behind the different notations and technologies. The metamodel is a MOF-compliant [13] metamodel.  As such, BPDM also defines a XML syntax for storing and transferring business process models between tools and infrastructures. BPDM has been evaluated in  [14] as the best business process interchange format in terms of expressivity.BPMN perfectly fits with the BPDM metamodel and provides a graphical notation to express BPDM business processes.  However, the specification of the business process can be provided with any other notation or language, including UML Activity Diagrams [11]. Several works evaluated and compared the different notations for specifying business processes (e.g., see [14–17]), highlighting strengths and weaknesses of every proposal. The results of our approach using one of these alternative notations would be quite similar. Indeed, our approach can be directly applied to any specification compliant with BPDM.In our work, we focus on the core part of the BPDM metamodel. The workflow model is hence based on the concepts ofProcess (the description of the business process), Case (a process instance, that is, a particular workflow execution), Activity (the elementary unit of work composing a process), Activity instance (an instantiation of an activity within a case), Actor (a user role intervening in the process), Event (some punctual situation that happens in a case), and Constraint (logical precedence among activities and rules enabling activities execution). Processes can be internally structured using a variety of constructs: sequences of activities; gateways implementing AND, OR, XOR splits, respectively, realizing splits into independent, alternative and exclusive threads; gateways implementing joins, that is, convergence point of two or more activity flows; conditional flows between two activities; loops among activities or repetitions of single activities. Each construct may involve several constraints over the activities.In the sequel, we will exemplify the proposed approach on a case study consisting of a simplified purchase process, illustrated using the BPMN notation in Figure3.Figure 3
Example of a workflow model.According to the BPDM semantics, the depicted diagram specifies a process involving two actors (represented by the two swimlanes): a customer and a seller. The customer starts the process by asking for a quotation about a set of products (Ask quotation activity). The seller provides the quotation (Provide quotation activity) and the customer may decide (exclusive choice) to modify the request (Change quotationactivity, followed by the repetition of the Provide quotation activity) or to accept it (then the order is submitted). For simplicity, it is not modeled what happens if they never reach an agreement. Depending on the complexity of the order, the process can follow two alternative paths: the first consists only of a Standard Shipment activity, while the second requires the customer to specify the kind of shipment he prefers (Choose shipment). After the choice, the Seller takes the order in charge and performs two parallel activities: the arrangement of the transport plan and the processing of each order line. The latter is represented by the multi-instance activity called Process order line: a different instance is started for each order line included in the order. Once all order lines have been processed and the shipment has been defined (i.e., after the AND merge synchronization), the path reaches the join point with the alternative path of the standard shipment. Independently on the kind of shipment, the Ship order activity is performed, and then two uncontrolled branches take place: the customer receives the goods and the seller issues and sends the invoice. When both activities have completed (synchronization AND gateway), the user pays for the goods, and thus closes the process.


## 5. Normalization Phase

Before addressing the actual integration of the workflow model and the conceptual schema, the business process specification usually needs to be normalized. This step simplifies the processing of the workflow model later on without losing generality in the coverage of the business process specification admitted in our method.Workflow languages allow different equivalent representations of the same business semantics (see [2] for details) and define several complex constructs that can be derived from more basic ones. The normalization phase tackles these problems by applying a set of model to model transformations that ensure a coherent representation and render all the complex concepts in terms of simple ones. Notice that this phase does not aim at the reconciliation of different business processes. Instead, it aims at unifoming the notation of different design styles that could be adopted even within the same notation. The main issues addressed in this phase are the following.(i)
Nested Structures. if the business process is specified by means of nested subprocesses, they are flattened into a single-level business process that includes all tasks that were included in the subprocesses. If the subprocess contained only one lane, all the activities are moved inside the current lane of the main process; if more lanes were contained in the subprocess, they are transferred to the current pool of the main process, together with their respective activities, thus introducing new lanes in the flattened process.(ii)
Different Notation Styles. all different notations with the same BPDM semantics are homogenized in a single BPMN notation style (some examples are shown next). Thanks to this step, the business process will use only a single representation for each modeled behavior.(iii)
Concatenation of Gateways. if two or more gateways are directly connected by a control flow, the transformation adds a fake intermediate activity in the middle of every gateway pair. This simplifies the integration job, since it permits to work in a modular fashion when generating the constraints and the rules imposed by the gateways. Fake activities can be treated as activities that can be immediately enacted as soon as their process constraints are satisfied, and then automatically completed without neither user interaction nor business action execution.Figure4 shows the result of applying the normalization phase on the workflow model specified in Figure 3. The elements added because of the normalization are highlighted in color and bold line face. Only the last two transformations apply to this example. To avoid the alternative notation for XOR-merge (consisting in directly connecting two incoming arrows to an activity), the XOR-merge after the Ask quotationactivity is made explicit and added to the model; analogously, to avoid two outgoing arrows from the Ship orderactivity, an AND-spit gateway is added. To remove the configurations of two connected gateways, a fake activity is added (EmptyActivity1).Figure 4
Example of a normalized workflow schema.


## 6. Extending Conceptual Schemas with Business Process Information

Given an initial conceptual schemac, the workflow-extended conceptual schema c′ of the workflow-based application w is obtained by extending c with some additional elements derived from the business process specification w. We will focus on the case of a single business process; however, our extensions to the conceptual schema suffice when considering different business processes on the same domain. Indeed, in our approach several workflow models can be integrated with the same conceptual schema since the process constraints of each workflow model do not interfere due to the construction process of the workflow-extended model.


### 6.1. Generation of the Workflow-Extended Conceptual Schema

The workflow-extended conceptual schema must include: (i) the original conceptual schema, (ii)user-related information, (iii)workflow-related information, (iv) a set of possible relationships between the conceptual schema, the workflow information and the user information, and (v) a set of process constraints guaranteeing a consistent state of the whole model with respect to the workflow definition (see Section 7). To illustrate the generation of these different parts of the workflow-extended conceptual schema we will use the workflow model of Figure 4 and we will assume that the initial conceptual schema is the one shown in Figure 2.More formally, we define a workflow-extended conceptual schema as follows. Given an initial conceptual schema with entity types (i.e., classes)E={e1,…,en}, representing the knowledge about the domain, and a workflow model w with activities A={a1,…,am}, the workflow-extended conceptual schema  is obtained in the following way.(i)
Domain Subschema. All entity types in E and their relationships (i.e., associations) and generalizations remain unchanged in the workflow-extended model (bottom part of Figure 5).(ii)
User Subschema.User-related information is added to the extended model by means of two entity types (see the top-left part of Figure 5): entity typeUser represents individual workflow actors; entity typeRole represents groups of users, having access to the same set of tasks. A user may belong to different roles.(iii)
Workflow Subschema.Workflow-related information (top-right part of Figure 5) includes several fixed types (i.e., independent of the particular workflow model):
(a)
Entity typeProcess represents the supported workflows. As an example, an instance of the Process type would be our Purchaseworkflow. Other instances would represent additional workflows over the same domain subschema.(b)
Entity typeCase denotes an instance of a process, which has a name, a start time, an end time, and a status, which can be: ready, active, cancelled, aborted, or completed [2]. Every execution of a process results in a new instance of this type. This new instance is related with the appropriate process instance.(c)
Entity typeActivityType represents the different activities that compose a process. Activity types are assigned to roles, which are responsible for executing them. In our case study, AskQuotation, ProvideQuotation, and so forth, would be instances of ActivityType.(d)
Entity typeActivity denotes the occurrence of a particular activity within a Case, described by the start time, the end time, and the current status, which can be: ready, active, cancelled, aborted, or completed. Only one user can execute a particular activity instance, and this is recorded by the relationship type Performs. The Precedes relationship keeps track of the execution order between occurred activities.(e)
Entity typeEventType represents the events that may affect the sequence or timing of activities of a process (e.g., temporal events, messages etc.). There are three different kinds of events (eventKind attribute): start, intermediate, and end. For start and intermediate events we may define the triggering mechanism (eventTrigger). For end events, we may define how they affect the case execution (eventResult).(f)
Entity typeEvent denotes the occurrence of a particular type of event in the system, and a set of workflow-dependent subtypes:(g)
For each activitya∈A, a new subtype sa is added to the entity type Activity (ActivityType is a powertype [11] for this set of generalizations). The name of the subtype is the name of a (e.g., in Figure 5 we introduced ProcessOrderLine, AskQuotation, ShipOrder, and so on). These subtypes record the information about the specific activities executed during a workflow case. For instance, the action of asking a quotation for the purchase X in a case C of a workflow W would be recorded in the system as an instance in the AskQuotation subtype related with the corresponding instance “C” in the Case type (in its turn related with the “W” instance in the Process type).(iv)
Relationships between Workflow, Subschema, and Domain Subschema. each subtype sa is related with a (possibly empty) set of entity types Ea⊆E. These new relationship types are useful to record the objects modified/managed during the execution of a certain activity. Also, they are required to evaluate conditions appearing in some process constraints. In the case study (see Figure 5), a set of relationship types are established: Quotations are associated with the activities Ask Quotation and Provide Quotation; QuotationLines are associated with the ProcessOrderLine activity; and Orders are associated with the activities Submit Order, Process OrderLine, Ship Order, Pay for goodsand so forth.  When necessary, these associations between the domain and the workflow subschemata may be automatically generated if the workflow specification includes auxiliary primitives for describing the data flow between activities and/or when the designer defines some pattern-matching among the names of the activities and of the entity types. Otherwise, they must be manually specified.Figure 5
Workflow-extended conceptual schema.


### 6.2. Complexity of the Workflow-Extended Conceptual Schema

Clearly, the workflow-extended schema is more complex than the original conceptual schema. However, we believe that this increased complexity is compensated by the fact that it may be automatically generated (with our method) and processed (for instance, with code-generation tools) and thus, the designer does not need to directly manipulate it. Moreover, the size of the extension is (1) constant regardless the size of the initial conceptual schema and (2) linear with respect to the number of activities in the workflow. Therefore, in most cases, the extension will be small when compared with the size of the initial conceptual schema.We would like to remark that when proposing our workflow-extended schema we opted for balancing the size of the workflow subschema with the complexity of the process constraints. Richer schemas with further relationship types and/or attributes could be defined, according to the requirements of the specific workflow application (for example, we could have used a more complex pattern for the specification of the role-user relationship [18]). Similarly, simpler extensions could be used instead but then, as a trade-off, the process constraints would become much more complex. To better illustrate this discussion, two other alternative workflow-extended models are provided in the Appendix A. All three alternatives share the same philosophy and provide the same kind of benefits, and thus, designer may choose any of them when applying our method.


## 6.1. Generation of the Workflow-Extended Conceptual Schema

The workflow-extended conceptual schema must include: (i) the original conceptual schema, (ii)user-related information, (iii)workflow-related information, (iv) a set of possible relationships between the conceptual schema, the workflow information and the user information, and (v) a set of process constraints guaranteeing a consistent state of the whole model with respect to the workflow definition (see Section 7). To illustrate the generation of these different parts of the workflow-extended conceptual schema we will use the workflow model of Figure 4 and we will assume that the initial conceptual schema is the one shown in Figure 2.More formally, we define a workflow-extended conceptual schema as follows. Given an initial conceptual schema with entity types (i.e., classes)E={e1,…,en}, representing the knowledge about the domain, and a workflow model w with activities A={a1,…,am}, the workflow-extended conceptual schema  is obtained in the following way.(i)
Domain Subschema. All entity types in E and their relationships (i.e., associations) and generalizations remain unchanged in the workflow-extended model (bottom part of Figure 5).(ii)
User Subschema.User-related information is added to the extended model by means of two entity types (see the top-left part of Figure 5): entity typeUser represents individual workflow actors; entity typeRole represents groups of users, having access to the same set of tasks. A user may belong to different roles.(iii)
Workflow Subschema.Workflow-related information (top-right part of Figure 5) includes several fixed types (i.e., independent of the particular workflow model):
(a)
Entity typeProcess represents the supported workflows. As an example, an instance of the Process type would be our Purchaseworkflow. Other instances would represent additional workflows over the same domain subschema.(b)
Entity typeCase denotes an instance of a process, which has a name, a start time, an end time, and a status, which can be: ready, active, cancelled, aborted, or completed [2]. Every execution of a process results in a new instance of this type. This new instance is related with the appropriate process instance.(c)
Entity typeActivityType represents the different activities that compose a process. Activity types are assigned to roles, which are responsible for executing them. In our case study, AskQuotation, ProvideQuotation, and so forth, would be instances of ActivityType.(d)
Entity typeActivity denotes the occurrence of a particular activity within a Case, described by the start time, the end time, and the current status, which can be: ready, active, cancelled, aborted, or completed. Only one user can execute a particular activity instance, and this is recorded by the relationship type Performs. The Precedes relationship keeps track of the execution order between occurred activities.(e)
Entity typeEventType represents the events that may affect the sequence or timing of activities of a process (e.g., temporal events, messages etc.). There are three different kinds of events (eventKind attribute): start, intermediate, and end. For start and intermediate events we may define the triggering mechanism (eventTrigger). For end events, we may define how they affect the case execution (eventResult).(f)
Entity typeEvent denotes the occurrence of a particular type of event in the system, and a set of workflow-dependent subtypes:(g)
For each activitya∈A, a new subtype sa is added to the entity type Activity (ActivityType is a powertype [11] for this set of generalizations). The name of the subtype is the name of a (e.g., in Figure 5 we introduced ProcessOrderLine, AskQuotation, ShipOrder, and so on). These subtypes record the information about the specific activities executed during a workflow case. For instance, the action of asking a quotation for the purchase X in a case C of a workflow W would be recorded in the system as an instance in the AskQuotation subtype related with the corresponding instance “C” in the Case type (in its turn related with the “W” instance in the Process type).(iv)
Relationships between Workflow, Subschema, and Domain Subschema. each subtype sa is related with a (possibly empty) set of entity types Ea⊆E. These new relationship types are useful to record the objects modified/managed during the execution of a certain activity. Also, they are required to evaluate conditions appearing in some process constraints. In the case study (see Figure 5), a set of relationship types are established: Quotations are associated with the activities Ask Quotation and Provide Quotation; QuotationLines are associated with the ProcessOrderLine activity; and Orders are associated with the activities Submit Order, Process OrderLine, Ship Order, Pay for goodsand so forth.  When necessary, these associations between the domain and the workflow subschemata may be automatically generated if the workflow specification includes auxiliary primitives for describing the data flow between activities and/or when the designer defines some pattern-matching among the names of the activities and of the entity types. Otherwise, they must be manually specified.Figure 5
Workflow-extended conceptual schema.


## 6.2. Complexity of the Workflow-Extended Conceptual Schema

Clearly, the workflow-extended schema is more complex than the original conceptual schema. However, we believe that this increased complexity is compensated by the fact that it may be automatically generated (with our method) and processed (for instance, with code-generation tools) and thus, the designer does not need to directly manipulate it. Moreover, the size of the extension is (1) constant regardless the size of the initial conceptual schema and (2) linear with respect to the number of activities in the workflow. Therefore, in most cases, the extension will be small when compared with the size of the initial conceptual schema.We would like to remark that when proposing our workflow-extended schema we opted for balancing the size of the workflow subschema with the complexity of the process constraints. Richer schemas with further relationship types and/or attributes could be defined, according to the requirements of the specific workflow application (for example, we could have used a more complex pattern for the specification of the role-user relationship [18]). Similarly, simpler extensions could be used instead but then, as a trade-off, the process constraints would become much more complex. To better illustrate this discussion, two other alternative workflow-extended models are provided in the Appendix A. All three alternatives share the same philosophy and provide the same kind of benefits, and thus, designer may choose any of them when applying our method.


## 7. Translation of Process Constraints

The structure of a workflow model implies a set of constraints regarding the execution order of the different activities, the number of possible instances of each activity in a given case, the conditions that must be satisfied in order to start a new activity, and so forth. These constraints are usually referred to asprocess constraints. The behavior of all enterprise applications must always satisfy these constraints. Thus, the generation of the workflow-extended model must consider all process constraints.Process constraints are translated into constraints over the population of thesa1,…,sam subtypes of Activity(see previous section). The generated constraints guarantee that any update event over the population of one of these subtypes (for instance, the creation of a new activity instance or the modification of its status) will be consistent with the process constraints defined in the workflow model.We specify process constraints by means of invariants written in the OCL language [8]. Invariants in OCL are defined in the context of a specific type, the context type. The actual OCL expression stating the constraint condition is called the body of the constraint. The body is always a boolean expression and must be satisfied by all instances of the context type, that is, the evaluation of the body expression over every instance of the context type must return atruevalue. For instance, a constraint likecontext A inv: conditionimplies that all instances of the typeA must verify condition.Constraints are defined to restrict only the execution of the workflow they are created for (the context type of the constraints is always a specific activity and not an entity type of the domain subschema). Therefore, no interferences among different workflows occur, even if they are defined over an overlapping subset of the conceptual schema.Even though some of the constraints may seem quite complex, we would like to remark that all of them are automatically generated from the workflow model, and thus, they do not need to be manipulated (nor even necessarily understood) by the designer but for other tools. However, to simplify its presentation in the extended model, we could easily define a stereotype for each constraint type, as done in [19].Next subsections define a set of patterns for the generation of the process constraints corresponding to the different typical constructs appearing in workflow models (sequences, split gateways, merge gateways, conditions, loops, etc.).  The patterns can be combined to produce the full translation of the workflow model.


### 7.1. Sequences of Activities

A sequence flow between two activities  (Figure6) indicates that the first activity (A) must be completed before starting the second one (B). Moreover, if A is completed within a given case, B must be eventually started before ending the case (we do not require B to be completed since, for instance, it could be interrupted by the trigger of an intermediate exception event). This behavior can be enforced by means of the definition of three OCL constraints.Figure 6
Sequence flow.The first constraint (seq1 constraint) is defined over the entity type corresponding to the destination activity (B in the example) stating that for all activity instances of type B the preceding activity instance must be of type A and that it must have been already completed. Its specification in OCL is the following:context B inv seq1: previous->size()=1 andprevious->exists(a|a.oclIsTypeOf(A) anda.status=‘completed’)This OCL definition enforces thatB instances (since B is the context type of the constraint) have a previous activity (because of the size operator over the value of the navigation through the role previous) and that such activity is of type A (enforced by the exists operator). B and A are Activity subtypes as defined in Section 6.The other two required constraints are the following.(i)
A constraintseq2 over the second activity to prevent the creation of two different B instances related with the same A activity instance context  B  inv  seq2:   B.allInstances()->isUnique(previous)(ii)
A constraintseq3 over the Case entity type verifying that when the case is completed there exists a B activity instance for each completed A activity instance. This B instance must be the only instance immediately following the A activity instancecontext Case inv seq3: status=‘completed’ impliesself.activity-> select(a|a.oclIsTypeOf(A) and a.status=‘completed’)->forAll(a|a.next->exists(b|b.oclIsTypeOf(B)) and a.next->size()=1)


### 7.2. Split Gateways

A split gateway is a location within a workflow where the sequence flow can take two or more alternative paths. The different split gateways differ on the number of possible paths that can be taken during the execution of the workflow. ForXOR-split gateways only a single path can be selected. In OR-splits several of the outgoing flows may be chosen. For AND-splits all outgoing flows must be followed.For each kind of split gateway, Table1 shows the process constraints required to enforce the corresponding behavior.Table 1
Constraints for split gateways.
Split gatewayProcess constraints- Only one of theB1⋯Bn activities may be started context A inv: next->select(a∣a.oclIsTypeOf(B1) or…or a.oclIsTypeOf(Bn))->size()<=1- IfA is completed, at least one of the B1..Bn activities must be created before ending the case context Case inv: status=‘completed’ implies activities-> select(a∣a.oclIsTypeOf(A) and a.status=‘completed’)-> forAll (a∣a.next->exists(b∣b.oclIsTypeOf(B1) or…or b.oclIsTypeOf(Bn)))- Since severalB1⋯Bn activities may be started, we just need to verify that if A is completed, at least one of the B1⋯Bn activities is created before ending the case (like in the XOR split above)- IfA is completed all B1⋯Bn activities must be eventually started
context Case inv:status=‘completed’ implies activity->select(a∣a.oclIsTypeOf(A) and a.status=‘completed’)->forAll(a∣a.next->exists(b∣b.oclIsTypeOf(B1)) and … and a.next->exists(b∣b.oclIsTypeOf(Bn)))Besides the process constraints appearing in the table, we must also add to all the activitiesB1⋯Bn the previous constraints seq1 and seq2 to verify that the preceding activity A has been completed and that no two activity instances of the same activity Bi are related with the same preceding activity A. We also require that the activity instance/s following A is of type B1 or … or Bn.


### 7.3. Merge Gateways

Merge gateways are useful to join or synchronize alternative sequence flows. Depending on the kind of merge gateway, the outgoing activity may start every time a single incoming flow is completed (XOR-Merge) or must wait until all incoming flows have finished in order to synchronize them (AND-Merge gateways). The semantics of the OR-Merge gateways is not so clear. If there is a matching OR-split, the OR-Merge should wait for the completion of all flows activated by the split. If no matching split exists, several interpretations are possible, being the simplest one to wait just till the first incoming flow. This is the interpretation adopted in this paper. For a complete treatment of this construct see [20].Table2 presents the different translation patterns required for each kind of merge gateway. Besides the constraints included in the table, a constraint over A should be added to all the gateways to verify that two A instances are not created for the same incoming set of activities (i.e., the intersection between the previous instance/s of all A instances must be empty).Table 2
Constraints for merge gateways.
Merge gatewayProcess constraints- AllA activity instances have as a previous activity instance a completed activity instance of type B1 or…or Bncontext A  inv: previous->size()=1 and previous->exists(b∣(b.oclIsTypeOf(B1) or…or b.oclIsTypeOf(Bn)) and b.status=‘completed’)- EachB1⋯Bn  activity instance is followed by an A activitycontext Case inv: status=‘completed’ implies activity->select(b∣b.oclIsTypeOf(B1) or…or b.oclIsTypeOf(Bn))-> forAll(b∣b.next->exists(a∣a.oclIsTypeOf(A)))- AnA activity instance must wait for at least an incoming flowcontext A  inv: previous->select(b|(b.oclIsTypeOf(B1) or…or  b.oclIsTypeOf(Bn)) and b.status=‘completed’)->size()≥1- An activity instance of typeA must wait for a set of activities B1⋯Bn to be completedcontext A inv: previous->exists(b∣b.oclIsTypeOf(B1) and b.status=‘completed’) and…and previous->exists(b∣b.oclIsTypeOf(Bn) and b.status=‘completed’)- Each set of completedB1⋯Bn activity instances must be related with an A activity instance context Case inv: status=‘completed’ implies not (activity->exists(b∣b.oclIsTypeOf(B1) and b.status=‘completed’  and not b.next->exists(a∣a.oclIsTypeOf(A)) and…and activity  ->exists(b∣b.oclIsTypeOf(Bn) and b.status=‘completed’ and not b.next->exists(a∣a.oclIsTypeOf(A)))


### 7.4. Condition Constraints

The sequence flow and theOR-split and XOR-split gateways may contain condition expressions to control the flow execution at run-time. As an example, Figure 7 shows a conditional sequence flow. In the example, the activity B cannot start until A is completed and the condition cond is satisfied. The condition expression may require accessing the entity types of the domain subschema related to B in the workflow-extended model. Through the Precedes relationship type, we can also define conditions involving the previous A activity instance and/or its related domain information.Figure 7
A conditional sequence flow.To handle these condition expressions we must add, for each condition defined in a sequence flow or in an outgoing link ofOR and XOR gateways, a new constraint over the destination activity. The constraint ensures that the preceding activity satisfies the specified condition, according to the following pattern:context B inv: previous->forAll(a∣a.cond)Note that these additional constraints only need to hold when the destination activity is created, and thus, they must be defined ascreation-time constraints [21].


### 7.5. Loops

A workflow may contain loops among a group of different activities or within a single activity. In this latter case we distinguish betweenstandardloops (where the activity is executed as long as the loop condition holds) and multi-instance loops (where the activity is executed a predefined number of times). Every time a loop is iterated a new instance of the activity is created. Figure 8 shows an example of each loop type.Figure 8
Loop examples.Management ofexternal loops does not require new constraints but the addition of a temporal condition in all constraints stating a condition like “an instance of type B must be eventually created if an instance of type A is completed”. The new temporal condition on those constraints ensures that the B instance is created after the A instance is completed (earlier B instances may exist due to previous loop iterations).Standard loops may be regarded as an alternative representation for conditional sequence flows having the same activity as a source and destination. Therefore, the constraints needed to handle standard loop activities are similar to those required for conditional sequence flows. We need a constraint checking that the previous loop instance has finished and another one stating that the loop condition is still true when starting the new iteration (again, this is a creation-time constraint). The loop condition is taken from the properties of the activity as defined in the workflow model. Moreover, we need also to check that the activity/ies at the end of the outcoming flows of the loop activity are not started until the loop condition becomes false. To prevent this wrong behavior we should treat all outgoing flows from the loop activity as conditional flows with the condition “not loopCondition”. Then, constraints generated to control the conditional flow will prevent next activity/ies to start until the condition “not loopCondition” becomes true.Multi-instance loop activities are repeated a fixed number of times, as defined by the loop condition, which now is evaluated only once during the execution of the case and returns a natural value instead of a boolean value. At the end of the case, the number of instances of the multi-instance activity must be an exact multiple of this value. Assuming that the multi-instance activity is called A, the OCL formalization of this constraint would be:context Case inv: (activity->select(a∣a.oclIsTypeOf(A))->size() mod loopCondition)=0.For multi-instance loops the different instances may be created sequentially or in parallel. Besides, we can define when the workflow shall continue. It can be either after each single activity instance is executed (as in a normal sequence flow), after all iterations have been completed (similar to theAND-merge gateways), or as soon as a single iteration is completed (similar to the basic OR-merge gateway).


### 7.6. Event  Management

An event is something that “happens” during the course of the workflow execution. There are three main types of events:Start, Intermediate and End (see Figure 9). A workflow schema may contain several start, intermediate, and end events.Figure 9
Examples of events.Start events initiate a new flow, while end events indicate the termination of a flow. Intermediate events are instead used to change the normal flow (for instance, to handle exceptions or to start additional activities). Intermediate events can be attached to an activity (the triggering of the event aborts the activity execution) or can be placed in the middle of a sequence flow between two activities (the flow does not continue until the event is issued).When a start event is issued, an instance of each activity connected to the event has to start afterwards. Conversely, no activity instance is created in a case before the occurrence of at least a start event. In particular, activity instances for activities connected only to flows coming from one or more start events (as activityA in the previous figure) cannot be created until one of those start events is issued. The formalization of these constraints is the following:(i)
context Event inv: eventType.name=‘StartEvent1’ and case.status=‘completed’  implies case.activity-> select(a∣a.oclIsTypeOf(A) and a.event=self)->size()=1(ii)
context Case inv: activity->notEmpty() implies event->exists(e∣e.eventType.eventKind=‘StartEvent’)(iii)
context A inv: self.event->exists(ev∣ev.eventType.name=‘StartEvent1’).For end events defined asterminate end events we must add a new constraint stating that no activity instances can be created in the case after the event has been issued. Assuming that EndEvent1 (Figure 9) is defined as a terminate event, the following constraint must be added to the workflow-extended model:context Event inv: eventType.name=‘EndEvent1’ impliescase.activity->forAll (a∣a.start< eventTime)For intermediate events, the target activity of the event must be executed after the triggering of the event (and it cannot be executed otherwise). Depending on the kind of intermediate event, the interrupted activity will change its status to cancelled or aborted (which, for instance, may prevent the next activity in the normal sequence flow to be started).The following process constraints are generated for theIntermediateEvent1 example in Figure 9:(i)
context  Event  inv:  eventType.name= ‘IntermediateEvent1’  and case.status=‘completed’  implies  case.activity-> exists(a∣a.oclIsTypeOf(B))(ii)
context  Case  inv:  activity-> exists(a∣a.oclIsTypeOf(B)) implies  event->exists(e∣e.eventType.name=“IntermediateEvent1”)Obviously, this last constraint is true as long asB has no other incoming flows. Otherwise, all incoming flows form an implicit XOR-Merge over B and we should generate the constraints according to the pattern for the XOR-Merge gateway.


### 7.7. Applying the Translation Patterns

As an example, Table3 summarizes the process constraints resulting from applying the translation patterns over the workflow running example (Figures 4 and 5).Table 3
Process constraints for the workflow running example.
ActivityConstraintsAsk Quotation- A newAsk Quotation activity must be created every time a start event occurs.Provide Quotation- A quotation cannot be provided until anAsk Quotation or a Change Quotation finishes. A single new Provide Quotation instance  must exist for each completed Ask Quotation or Change Quotation activity.- After providing a quotation we can either ask for a change in the quotation or submit the order, but not both (at least one of them must be executed).Change  Quotation- The previousProvide Quotation activity must have been completed (a single new ask quotation activity can be generated). Otherwise, it must have been created in response to the occurrence of a start event (due to the implicit XOR merge gateway corresponding to the two incoming arrows).Submit Order- The previousProvide Quotation activity must be completed. Besides, only a single Submit Order instance must be created for the same Provided Quotation instance.- After submitting an order, aChoose Shipment or a Standard Shipmentactivities must be executed (but not both).Standard Shipment- The previousSubmit Order activity must be completed. Besides, only a single Standard Shipmentinstance must be created for the same Submit Orderinstance.- Once the standard shipment is completed, a newShip Order activity must be created.Choose  Shipment- The previousSubmit Order activity must be completed. Besides, only a single Choose Shipmentinstance must be created for the same Submit Orderinstance.- After choosing the shipment, both theArrange Transportand Process Order Line activities must be executed.Arrange  Transport- The precedingChoose Shipmentactivity instance must be completed. Besides, a single Arrange Transportactivity instance must be executed for each Choose Shipmentactivity instance.Process OrderLine- The precedingChoose Shipmentactivity  must be completed.- The system must exactly execute as manyProcess OrderLine activity instances as the number of order (quotation) lines for the related order.Empty  Activity1- The newEmpty activity instance can be created (as completed) when the transport has been arranged and all order lines have been processed.- Then, a newShip Order instance must be executed before ending the case.Ship Order- Once aStandard Shipment xor an Empty Activity1 instance has been completed, the order can be shipped.- For each order shipped, an invoice must be sent and the reception of the goods must be acknowledged by the customer.Send  Invoice- The precedingShip Orderactivity instance must be completed. Besides, a single Send Invoiceactivity instance must be executed for each Ship Orderactivity instance.Receive Goods- The precedingShip Orderactivity instance must be completed. Besides, a single Receive Goodsactivity instance must be executed for each Ship Orderactivity instance.Pay Goods- An order cannot be paid until the invoice has been send and the good have been received. When both previous activities have been done, a singlepay goodsactivity shall be created in response.For the sake of brevity, in this section constraints are described in an informal and compact way. The complete set of constraints and their OCL specification is exemplified in Table4 only for the Provide Quotation activity. The translation of all the other constraints is provided in the Appendix B.Table 4
Constraint definitions for theProvide Quotation activity.
Constraints due to incoming XOR-merge–The preceding activity must be of typeAsk Quotation or Change Quotation and must be completedcontext ProvideQuotation inv: previous->size()=1 and previous->exists(a∣(a.oclIsTypeOf(AskQuotation) or a.oclIsTypeOf(ChangeQuotation) ) and a.status=‘completed’)–No two instances may be related with the sameAsk Quotation or Change Quotation instancecontext Provide Quotation inv: ProvideQuotation.allInstances()-> isUnique(previous)–AProvide Quotation instance follows each completed Ask QuotationorChange Quotation activitycontext Case inv: status=‘completed’ implies activity->select(b∣b.oclIsTypeOf(Ask Quotation) or…or b.oclIsTypeOf(ChangeQuotation))->forAll(b∣b.next->exists(a∣a.oclIsTypeOf (ProvideQuotation)))Constraints due to the outgoingXOR- split–The next activity must be either anotherChange Quotation instance or a Submit Order instance, but not bothcontext ProvideQuotation inv: next->select (a∣a.oclIs TypeOf(Change Quotation) or a.oclIsTypeOf (SubmitOrder))->size()<=1–If theProvide Quotation instance is completed, a Change  Quotation or a Submit Order must necessarily be created before ending the case.context Case inv: status=‘completed’ implies activity->select (a∣a.oclIsTypeOf  (ProvideQuotation) and a.status=‘completed’)->forAll (a∣a.next->exists (b∣b.oclIsTypeOf(ChangeQuotation) or b.oclIsTypeOf(SubmitOrder)))–OnlyChange Quotation activity instances or Submit Order instances may follow a Provide Quotation instancecontext ProvideQuotation inv: next->forAll (b∣b.oclIsTypeOf(ChangeQuotation) or b.oclIsTypeOf(SubmitOrder)TheProvide Quotation activity involves a set of constraints due to the incoming XOR-merge from Ask Quotation and Change Quotation activities and a set of constraints due to the subsequent XOR split with Submit Order and Change Quotation.


## 7.1. Sequences of Activities

A sequence flow between two activities  (Figure6) indicates that the first activity (A) must be completed before starting the second one (B). Moreover, if A is completed within a given case, B must be eventually started before ending the case (we do not require B to be completed since, for instance, it could be interrupted by the trigger of an intermediate exception event). This behavior can be enforced by means of the definition of three OCL constraints.Figure 6
Sequence flow.The first constraint (seq1 constraint) is defined over the entity type corresponding to the destination activity (B in the example) stating that for all activity instances of type B the preceding activity instance must be of type A and that it must have been already completed. Its specification in OCL is the following:context B inv seq1: previous->size()=1 andprevious->exists(a|a.oclIsTypeOf(A) anda.status=‘completed’)This OCL definition enforces thatB instances (since B is the context type of the constraint) have a previous activity (because of the size operator over the value of the navigation through the role previous) and that such activity is of type A (enforced by the exists operator). B and A are Activity subtypes as defined in Section 6.The other two required constraints are the following.(i)
A constraintseq2 over the second activity to prevent the creation of two different B instances related with the same A activity instance context  B  inv  seq2:   B.allInstances()->isUnique(previous)(ii)
A constraintseq3 over the Case entity type verifying that when the case is completed there exists a B activity instance for each completed A activity instance. This B instance must be the only instance immediately following the A activity instancecontext Case inv seq3: status=‘completed’ impliesself.activity-> select(a|a.oclIsTypeOf(A) and a.status=‘completed’)->forAll(a|a.next->exists(b|b.oclIsTypeOf(B)) and a.next->size()=1)


## 7.2. Split Gateways

A split gateway is a location within a workflow where the sequence flow can take two or more alternative paths. The different split gateways differ on the number of possible paths that can be taken during the execution of the workflow. ForXOR-split gateways only a single path can be selected. In OR-splits several of the outgoing flows may be chosen. For AND-splits all outgoing flows must be followed.For each kind of split gateway, Table1 shows the process constraints required to enforce the corresponding behavior.Table 1
Constraints for split gateways.
Split gatewayProcess constraints- Only one of theB1⋯Bn activities may be started context A inv: next->select(a∣a.oclIsTypeOf(B1) or…or a.oclIsTypeOf(Bn))->size()<=1- IfA is completed, at least one of the B1..Bn activities must be created before ending the case context Case inv: status=‘completed’ implies activities-> select(a∣a.oclIsTypeOf(A) and a.status=‘completed’)-> forAll (a∣a.next->exists(b∣b.oclIsTypeOf(B1) or…or b.oclIsTypeOf(Bn)))- Since severalB1⋯Bn activities may be started, we just need to verify that if A is completed, at least one of the B1⋯Bn activities is created before ending the case (like in the XOR split above)- IfA is completed all B1⋯Bn activities must be eventually started
context Case inv:status=‘completed’ implies activity->select(a∣a.oclIsTypeOf(A) and a.status=‘completed’)->forAll(a∣a.next->exists(b∣b.oclIsTypeOf(B1)) and … and a.next->exists(b∣b.oclIsTypeOf(Bn)))Besides the process constraints appearing in the table, we must also add to all the activitiesB1⋯Bn the previous constraints seq1 and seq2 to verify that the preceding activity A has been completed and that no two activity instances of the same activity Bi are related with the same preceding activity A. We also require that the activity instance/s following A is of type B1 or … or Bn.


## 7.3. Merge Gateways

Merge gateways are useful to join or synchronize alternative sequence flows. Depending on the kind of merge gateway, the outgoing activity may start every time a single incoming flow is completed (XOR-Merge) or must wait until all incoming flows have finished in order to synchronize them (AND-Merge gateways). The semantics of the OR-Merge gateways is not so clear. If there is a matching OR-split, the OR-Merge should wait for the completion of all flows activated by the split. If no matching split exists, several interpretations are possible, being the simplest one to wait just till the first incoming flow. This is the interpretation adopted in this paper. For a complete treatment of this construct see [20].Table2 presents the different translation patterns required for each kind of merge gateway. Besides the constraints included in the table, a constraint over A should be added to all the gateways to verify that two A instances are not created for the same incoming set of activities (i.e., the intersection between the previous instance/s of all A instances must be empty).Table 2
Constraints for merge gateways.
Merge gatewayProcess constraints- AllA activity instances have as a previous activity instance a completed activity instance of type B1 or…or Bncontext A  inv: previous->size()=1 and previous->exists(b∣(b.oclIsTypeOf(B1) or…or b.oclIsTypeOf(Bn)) and b.status=‘completed’)- EachB1⋯Bn  activity instance is followed by an A activitycontext Case inv: status=‘completed’ implies activity->select(b∣b.oclIsTypeOf(B1) or…or b.oclIsTypeOf(Bn))-> forAll(b∣b.next->exists(a∣a.oclIsTypeOf(A)))- AnA activity instance must wait for at least an incoming flowcontext A  inv: previous->select(b|(b.oclIsTypeOf(B1) or…or  b.oclIsTypeOf(Bn)) and b.status=‘completed’)->size()≥1- An activity instance of typeA must wait for a set of activities B1⋯Bn to be completedcontext A inv: previous->exists(b∣b.oclIsTypeOf(B1) and b.status=‘completed’) and…and previous->exists(b∣b.oclIsTypeOf(Bn) and b.status=‘completed’)- Each set of completedB1⋯Bn activity instances must be related with an A activity instance context Case inv: status=‘completed’ implies not (activity->exists(b∣b.oclIsTypeOf(B1) and b.status=‘completed’  and not b.next->exists(a∣a.oclIsTypeOf(A)) and…and activity  ->exists(b∣b.oclIsTypeOf(Bn) and b.status=‘completed’ and not b.next->exists(a∣a.oclIsTypeOf(A)))


## 7.4. Condition Constraints

The sequence flow and theOR-split and XOR-split gateways may contain condition expressions to control the flow execution at run-time. As an example, Figure 7 shows a conditional sequence flow. In the example, the activity B cannot start until A is completed and the condition cond is satisfied. The condition expression may require accessing the entity types of the domain subschema related to B in the workflow-extended model. Through the Precedes relationship type, we can also define conditions involving the previous A activity instance and/or its related domain information.Figure 7
A conditional sequence flow.To handle these condition expressions we must add, for each condition defined in a sequence flow or in an outgoing link ofOR and XOR gateways, a new constraint over the destination activity. The constraint ensures that the preceding activity satisfies the specified condition, according to the following pattern:context B inv: previous->forAll(a∣a.cond)Note that these additional constraints only need to hold when the destination activity is created, and thus, they must be defined ascreation-time constraints [21].


## 7.5. Loops

A workflow may contain loops among a group of different activities or within a single activity. In this latter case we distinguish betweenstandardloops (where the activity is executed as long as the loop condition holds) and multi-instance loops (where the activity is executed a predefined number of times). Every time a loop is iterated a new instance of the activity is created. Figure 8 shows an example of each loop type.Figure 8
Loop examples.Management ofexternal loops does not require new constraints but the addition of a temporal condition in all constraints stating a condition like “an instance of type B must be eventually created if an instance of type A is completed”. The new temporal condition on those constraints ensures that the B instance is created after the A instance is completed (earlier B instances may exist due to previous loop iterations).Standard loops may be regarded as an alternative representation for conditional sequence flows having the same activity as a source and destination. Therefore, the constraints needed to handle standard loop activities are similar to those required for conditional sequence flows. We need a constraint checking that the previous loop instance has finished and another one stating that the loop condition is still true when starting the new iteration (again, this is a creation-time constraint). The loop condition is taken from the properties of the activity as defined in the workflow model. Moreover, we need also to check that the activity/ies at the end of the outcoming flows of the loop activity are not started until the loop condition becomes false. To prevent this wrong behavior we should treat all outgoing flows from the loop activity as conditional flows with the condition “not loopCondition”. Then, constraints generated to control the conditional flow will prevent next activity/ies to start until the condition “not loopCondition” becomes true.Multi-instance loop activities are repeated a fixed number of times, as defined by the loop condition, which now is evaluated only once during the execution of the case and returns a natural value instead of a boolean value. At the end of the case, the number of instances of the multi-instance activity must be an exact multiple of this value. Assuming that the multi-instance activity is called A, the OCL formalization of this constraint would be:context Case inv: (activity->select(a∣a.oclIsTypeOf(A))->size() mod loopCondition)=0.For multi-instance loops the different instances may be created sequentially or in parallel. Besides, we can define when the workflow shall continue. It can be either after each single activity instance is executed (as in a normal sequence flow), after all iterations have been completed (similar to theAND-merge gateways), or as soon as a single iteration is completed (similar to the basic OR-merge gateway).


## 7.6. Event  Management

An event is something that “happens” during the course of the workflow execution. There are three main types of events:Start, Intermediate and End (see Figure 9). A workflow schema may contain several start, intermediate, and end events.Figure 9
Examples of events.Start events initiate a new flow, while end events indicate the termination of a flow. Intermediate events are instead used to change the normal flow (for instance, to handle exceptions or to start additional activities). Intermediate events can be attached to an activity (the triggering of the event aborts the activity execution) or can be placed in the middle of a sequence flow between two activities (the flow does not continue until the event is issued).When a start event is issued, an instance of each activity connected to the event has to start afterwards. Conversely, no activity instance is created in a case before the occurrence of at least a start event. In particular, activity instances for activities connected only to flows coming from one or more start events (as activityA in the previous figure) cannot be created until one of those start events is issued. The formalization of these constraints is the following:(i)
context Event inv: eventType.name=‘StartEvent1’ and case.status=‘completed’  implies case.activity-> select(a∣a.oclIsTypeOf(A) and a.event=self)->size()=1(ii)
context Case inv: activity->notEmpty() implies event->exists(e∣e.eventType.eventKind=‘StartEvent’)(iii)
context A inv: self.event->exists(ev∣ev.eventType.name=‘StartEvent1’).For end events defined asterminate end events we must add a new constraint stating that no activity instances can be created in the case after the event has been issued. Assuming that EndEvent1 (Figure 9) is defined as a terminate event, the following constraint must be added to the workflow-extended model:context Event inv: eventType.name=‘EndEvent1’ impliescase.activity->forAll (a∣a.start< eventTime)For intermediate events, the target activity of the event must be executed after the triggering of the event (and it cannot be executed otherwise). Depending on the kind of intermediate event, the interrupted activity will change its status to cancelled or aborted (which, for instance, may prevent the next activity in the normal sequence flow to be started).The following process constraints are generated for theIntermediateEvent1 example in Figure 9:(i)
context  Event  inv:  eventType.name= ‘IntermediateEvent1’  and case.status=‘completed’  implies  case.activity-> exists(a∣a.oclIsTypeOf(B))(ii)
context  Case  inv:  activity-> exists(a∣a.oclIsTypeOf(B)) implies  event->exists(e∣e.eventType.name=“IntermediateEvent1”)Obviously, this last constraint is true as long asB has no other incoming flows. Otherwise, all incoming flows form an implicit XOR-Merge over B and we should generate the constraints according to the pattern for the XOR-Merge gateway.


## 7.7. Applying the Translation Patterns

As an example, Table3 summarizes the process constraints resulting from applying the translation patterns over the workflow running example (Figures 4 and 5).Table 3
Process constraints for the workflow running example.
ActivityConstraintsAsk Quotation- A newAsk Quotation activity must be created every time a start event occurs.Provide Quotation- A quotation cannot be provided until anAsk Quotation or a Change Quotation finishes. A single new Provide Quotation instance  must exist for each completed Ask Quotation or Change Quotation activity.- After providing a quotation we can either ask for a change in the quotation or submit the order, but not both (at least one of them must be executed).Change  Quotation- The previousProvide Quotation activity must have been completed (a single new ask quotation activity can be generated). Otherwise, it must have been created in response to the occurrence of a start event (due to the implicit XOR merge gateway corresponding to the two incoming arrows).Submit Order- The previousProvide Quotation activity must be completed. Besides, only a single Submit Order instance must be created for the same Provided Quotation instance.- After submitting an order, aChoose Shipment or a Standard Shipmentactivities must be executed (but not both).Standard Shipment- The previousSubmit Order activity must be completed. Besides, only a single Standard Shipmentinstance must be created for the same Submit Orderinstance.- Once the standard shipment is completed, a newShip Order activity must be created.Choose  Shipment- The previousSubmit Order activity must be completed. Besides, only a single Choose Shipmentinstance must be created for the same Submit Orderinstance.- After choosing the shipment, both theArrange Transportand Process Order Line activities must be executed.Arrange  Transport- The precedingChoose Shipmentactivity instance must be completed. Besides, a single Arrange Transportactivity instance must be executed for each Choose Shipmentactivity instance.Process OrderLine- The precedingChoose Shipmentactivity  must be completed.- The system must exactly execute as manyProcess OrderLine activity instances as the number of order (quotation) lines for the related order.Empty  Activity1- The newEmpty activity instance can be created (as completed) when the transport has been arranged and all order lines have been processed.- Then, a newShip Order instance must be executed before ending the case.Ship Order- Once aStandard Shipment xor an Empty Activity1 instance has been completed, the order can be shipped.- For each order shipped, an invoice must be sent and the reception of the goods must be acknowledged by the customer.Send  Invoice- The precedingShip Orderactivity instance must be completed. Besides, a single Send Invoiceactivity instance must be executed for each Ship Orderactivity instance.Receive Goods- The precedingShip Orderactivity instance must be completed. Besides, a single Receive Goodsactivity instance must be executed for each Ship Orderactivity instance.Pay Goods- An order cannot be paid until the invoice has been send and the good have been received. When both previous activities have been done, a singlepay goodsactivity shall be created in response.For the sake of brevity, in this section constraints are described in an informal and compact way. The complete set of constraints and their OCL specification is exemplified in Table4 only for the Provide Quotation activity. The translation of all the other constraints is provided in the Appendix B.Table 4
Constraint definitions for theProvide Quotation activity.
Constraints due to incoming XOR-merge–The preceding activity must be of typeAsk Quotation or Change Quotation and must be completedcontext ProvideQuotation inv: previous->size()=1 and previous->exists(a∣(a.oclIsTypeOf(AskQuotation) or a.oclIsTypeOf(ChangeQuotation) ) and a.status=‘completed’)–No two instances may be related with the sameAsk Quotation or Change Quotation instancecontext Provide Quotation inv: ProvideQuotation.allInstances()-> isUnique(previous)–AProvide Quotation instance follows each completed Ask QuotationorChange Quotation activitycontext Case inv: status=‘completed’ implies activity->select(b∣b.oclIsTypeOf(Ask Quotation) or…or b.oclIsTypeOf(ChangeQuotation))->forAll(b∣b.next->exists(a∣a.oclIsTypeOf (ProvideQuotation)))Constraints due to the outgoingXOR- split–The next activity must be either anotherChange Quotation instance or a Submit Order instance, but not bothcontext ProvideQuotation inv: next->select (a∣a.oclIs TypeOf(Change Quotation) or a.oclIsTypeOf (SubmitOrder))->size()<=1–If theProvide Quotation instance is completed, a Change  Quotation or a Submit Order must necessarily be created before ending the case.context Case inv: status=‘completed’ implies activity->select (a∣a.oclIsTypeOf  (ProvideQuotation) and a.status=‘completed’)->forAll (a∣a.next->exists (b∣b.oclIsTypeOf(ChangeQuotation) or b.oclIsTypeOf(SubmitOrder)))–OnlyChange Quotation activity instances or Submit Order instances may follow a Provide Quotation instancecontext ProvideQuotation inv: next->forAll (b∣b.oclIsTypeOf(ChangeQuotation) or b.oclIsTypeOf(SubmitOrder)TheProvide Quotation activity involves a set of constraints due to the incoming XOR-merge from Ask Quotation and Change Quotation activities and a set of constraints due to the subsequent XOR split with Submit Order and Change Quotation.


## 8. Implementation of the Workflow-Extended Conceptual Schema

Once the workflow-extended schema is available, we may automatically generate an implementation of the system that ensures a consistent behavior of all enterprise applications with respect to the business process specification.Since a workflow-extended conceptual schema is a completely standard UML model (i.e., no new modeling primitives have been created to express the extension of the original model with the required workflow information) any method or tool able to provide an automatic model-to-code generation from UML models to a final technology platformP can also cope with the automatic generation of our workflow-extended schema in the same platform P, using general-purpose MDD techniques and frameworks.For instance, a tool able to generate a database schema from an UML/OCL model can follow exactly the same procedure to generate a database implementation for our extended schema that guarantees the satisfaction of all workflow constraints. As usual, classes (including also the classes in the workflow subschema) will be transformed into tables, while OCL constraints (either domain or workflow constraints) will be expressed as triggers (this is not the only option, see [22] for a discussion of the different mechanisms to implement OCL constraints in databases). Similarly, a tool able to generate Java schemas from UML/OCL models could be directly used to generate a Java-based implementation of the workflow-extended schema. In this case, classes will be expressed as Java classes while constraints could be implemented as method preconditions that prevent the execution of the method if the system is not in the right workflow state.As an example, Figure10 shows a possible (i) database implementation and (ii) Java-based implementation for two sequential activities A and B (Figure 6), performed by the same user. In the former, the constraint is implemented as a trigger over the table AtoB representing the Precedes relationship type (see Figure 5) between both activities (AtoB table has only two columns, a_id and b_id and records the information about which A activities precede each B activity; this is the typical database implementation for many-to-many associations in conceptual schemas). In the latter, the constraint is verified as part of the method AssignPreviousActivity redefined in the B class (corresponding to the B activity in the workflow-extended model). In both situations, when the user tries to create a new B activity and the previous A activity is not completed, an exception is raised since the B activity cannot start yet. The tables, triggers and/or Java classes and method bodies to implement the workflow-extended model translation (including the OCL constraints) can be automatically generated using current code-generation tools such as [23–25] among others.Examples of a sequence constraint implemented in particular technologies.
(a)(b)Note that the previous strategies to implement the sequence constraint betweenA and B activities are efficient ones since the constraint is only checked when linking a B activity instance with an A activity instance, regardless how many activities are part of the workflow (and the checking just compares that exact pair of instances, instead of checking all existing A and B instances). We can benefit from the fact that in our workflow-extended conceptual schema the process constraints are expressed in OCL and rely on existing methods for analyzing OCL expressions (as in [26])  to automatically compute the information about when and how checking the constraints in order to get an efficient implementation for all process constraints.For Web applications, an interesting alternative is to fully exploit MDD approaches, such as [23, 27]: an initial hypertext model can be derived from the workflow-extended conceptual schema so that the hypertext structure enforces some of the process constraints among activities assigned to the same user by means of driving the user navigation through the Web site. Process constraints involving activities belonging to different users must be enforced using one of the previous techniques, they cannot be controlled at the hypertext level (or group of users). This can be done by designing in the proper way the set of pages and links that can be browsed. For instance, Figure 11 shows a hypertext model that from the home page forces the user to go through the Web pages implementing A before starting B.The hypertext model is defined in WebML [23], a conceptual language for the specification of Web applications, already extended with workflow-specific primitives [28]. The operation units StartActivity and EndActivity are in charge of recording the information about the activities’ progress in the corresponding entity types of the conceptual schema. More complicated constraints appearing in the workflow-extended model can be enforced by means of appropriate branching and task assignment primitives.Figure 11
Example of a sequence constraint implemented within the hypertext model of a Web application.Usually, designers will be able to choose among different strategies/platforms when implementing the workflow-extended conceptual schema. For instance, assuming a typical three tier (or n-tier) architecture, designers can decide whether to check the process constraints in the presentation layer (for example, as shown in Figure11), in the business layer (as in Figure 10(b)) or in the persistence layer (as in Figure 10(a)). Each alternative may imply a slightly different behavior of the system at run-time in terms of its consistency, user experience, flexibility, reliability, and so forth. For instance, a database-based implementation represents a safer alternative in terms of the data consistency (regardless how users interact with the system to update the data, the data will be always consistent). Instead, enforcing the constraints at the hypertext level provides a better user experience since it reduces the probability that the user actions end up in an error due to a wrong activity selection.


## 9. Tool Support

To show the viability of the approach, we describe the tool framework we used for realizing the whole development process presented in Figure1. Our framework tries to reuse as many existing tools as possible. We directly developed only the pieces that were missing for covering all the design phases. Once the designer provides the initial models, the rest of the process is performed automatically. Figure 12 shows the tools we used for each step of the design.Figure 12
Tools used for the MDD generation of Workflow-extended conceptual schemas.The design of the conceptual schema has been done usingMagicDraw [29] that exports it as an XMI file [30].For workflow design and transformation, we have developed a visual editor prototype [31] that supports the design of BPMN diagrams and their automatic model transformations. This BPMN editor has been implemented as an Eclipse plugin and it is flexible and extensible. It covers the whole BPMN notation (including subprocesses) and can manage user-defined properties of objects and new transformations of the workflow models. The workflow schema is stored as an XML document according to an internal format, but proper transformations are available for importing and exporting in standard notations (e.g., to BPDM, XPDL, BPEL, etc.). The tool includes the normalization transformation, implemented as an XSLT transformation over the workflow XML representation.Given the XML representation of the normalized workflow model and the XMI representation of the initial conceptual schema, our main transformation generates a new XMI file containing the workflow-extended model and the process constraints, according to the guidelines presented in this paper. This XMI file can be imported back and used within theMagicDraw tool.


## 10. Related Work

With respect to traditional approaches to workflow management, implemented in a plethora of commercial WFMSs, our work takes a radically different point of view, by focusing on the business process modeling and on its transformation to a software engineering specification that integrates the domain information and that can be refined and exploited by automatic code generation tools.This approach allows for more control and personalization of the system implementation and presents a number of additional benefits as commented in Section2. As a downside, some aspects such as integration with legacy systems, monitoring and supervision, fault management and so forth, if needed, must be provided by the application that embeds the business specification itself, instead of relying on a WFMS for providing them.In the software engineering field, research on business process has mainly addressed the correctness of the design of the workflow model (see [32] as a representative example). Other works address  the direct implementation of business process models in specific final technology platforms: for instance, [5] proposes an implementation of process constraints over relational database structures, by exploiting event-condition-action rules; [6] implements workflow models using Web technologies by mapping the workflow specification to a DSL for Web design called WebML; and [7] exploits BPEL4WS for implementing them. All these approaches are hardly reusable when trying to implement our workflow schema in different technologies or when we want to migrate our current implementation to an alternative platform. Instead, since our method works at a platform-independent level, we are able to generate an implementation of the workflow-extended method in any final technology platform using current model-driven development (MDD) approaches, as seen in Section 8. Integrating the workflow and the domain information in a single schema also allows us to treat both dimensions in a homogeneous and consistent way (for instance, this enables the possibility of defining more complex business rules mixing domain and workflow information). This is not contemplated in the previous approaches.Up to now, integration of workflows and MDD approaches has only been explored from a general framework perspective. For instance, [33] proposes to transform the workflow model to a DSL specification. However, it only provides some general guidelines for the transformation and a comprehensive framework specifying the different components that lead from the design-time specification to the runtime execution of the workflow model. However, no details are provided on the transformation rules that map a workflow model to a specific DSL. The work in [34] proposes an approach for configuring generic process models depending on the domain information provided by the stakeholders by mean of filling questionnaires developed ad-hoc for that specific process. Questionnaires are created from the information in the initial domain model defined by the designers. Their goal is to generate, as a result, an adapted and individualized business process but not to integrate in a single conceptual schema both the process and domain information.Some proposals (as in [35, 36], or [37]) tried to extend and adapt the UML notation for workflow modeling purposes but they did not address the unification of the business process and the conceptual schema’s views of the system. As far as we know, ours is the first proposal where both workflow information and process constraints are automatically derived from a workflow model and integrated within the platform-independent conceptual schema.Moreover, ours is also the first translation of a workflow model into a set of equivalent OCL declarative constraints. An explicit definition of all the workflow constraints induced by the different workflow constructs is necessary regardless how these constraints are to be enforced and managed in the final workflow implementation. Very few examples of translations from process constraints to other declarative languages exist (e.g., see [38] for a translation to LTL temporal logics). In literature, OCL has only been used in relation with workflow models as an auxiliary tool for a better specification of the business process. For instance, in [39] OCL is used to manually specify workflow access control constraints and derive authorization rules, in [40] to express constraints with respect to the distribution of work to teams, in ArgoUWE [41] to check for well-formedness in the design of process models, in [42] to manually specify business models with UML, and in [7] to specify the contracts for the transformation of activity diagrams into BPEL4WS.


## 11. Conclusions

In this paper, we presented an automatic approach to integrate the semantics of business process specifications within conceptual schemas. The main advantage of using conceptual schemas to handle the workflow information is that we can develop workflow-based applications without requiring the use of a specific workflow management subsystem.Once the designer has specified both the workflow and the conceptual schemas, we build an integrated workflow-extended conceptual schema by adding to the conceptual schema (i) the definition of a set of new entity and relationship types for workflow status tracking and (ii) the rules for generating the integrity constraints on such types, needed for enforcing the business process specification. The integration of both the domain and the workflow aspects in a single extended conceptual schema permits a homogeneous treatment of both dimensions of the workflow-based application.The workflow-extended conceptual schema is a completely standard UML model. This provides additional benefits. For instance, we can apply the usual model-driven development methods over our extended model to generate its automatic implementation in any technology platform. As long as these methods are able to deal with UML/OCL models, they will be able to directly manage our workflow-extended schema. In the same way, we could reuse verification and validation tools for UML models and apply them to check our extended schema.As a further work, we would like to explore the possibility of using our extended schema as a bridge to facilitate reverse-engineering of existing applications into their original workflow models and to ease keeping them aligned. We also plan to develop a method that, from the generated process constraints, is able to compute the list of activities that can be enacted by a user in a given case (i.e., those activities that can be created without violating any of the workflow process constraints according to the case state at that specific time) to provide a better user-experience when executing the workflow-based applications. Instead of letting the user choose the desired activity and then check whether the activity can be started, we would directly provide the list ofsecure activities avoiding possible errors in the activity selection. Along this line, we also plan to investigate the different application layers (data layer, business logic layer, presentation layer) where the process constraints can be implemented, and define some recommendation framework for the developers (and the automatically generated code) for the best implementation strategy of constraints depending on the kind of experience the application is supposed to provide to the users.Future investigations will also address the empirical evaluation of our approach. In particular, we would like to compare the quality of manually developed applications with respect to the ones produced with our approach. For instance, we would like to compare the percentage of workflow constraints detected and included by programmers when manually developing the applications with the coverage of workflow constraints obtained when using our approach. We are confident that a manual application development will miss many workflow constraints since a manual detection of all relevant constraints and possible inconsistencies is an error-prone activity. We also plan to evaluate the effort required to develop this kind of applications with and without our approach.



---

*Source: 525121-2010-04-20.xml*