Automatic Generation of Workflow-Aware Domain Models

Every Information System needs to be consistent with its organization’s business processes. Sometimes the process is enforced by means of using a full-blown workflow management system. This is the obvious solution for large and complex processes but it comes with a cost (monetary but also due to the additional complexity of adding a new layer in your system that should be now the only entry point to all your services, forbidding any other more direct access or backdoor that could violate the process constraints).

We would like to present a more lightweight alternative: adding a set of constraints to your domain model that guarantee that your system is modified according to the workflow rules.  With our approach, the domain model becomes “process-aware” and is able to comply with your business processes without introducing new elements/components to your architecture.

This work was presented a long time ago but it’s still perfectly valid nowdays. It’s one of those papers that never got too much attention but that I still like (I do have examples of the opposite, papers that I’m not really proud of but that seem to be quite popular 😉 ). And since I recently realized that I had never presented the work here, I thought “better than never” so where we go with our approach to extend simple models (and by transitivity, database schemas) with business process information to easily enforce your business rules.

As usual, you can download the paper for free (M. Brambilla, J. Cabot, S. Comai: Automatic Generation of Workflow-Extended Domain Models, MoDELS 2007: 375-389, see also the extended version ) or keep reading for an extended summary.

1. Introduction

All software systems must include a formal representation of the knowledge 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 lightweight 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 implemented ad 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 a unified 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.).

2. Overview of the Proposed Approach and of its Benefits

Our MDD approach for developing workflow-based applications is sketched in Figure 1: 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.

 

The workflow model may need a normalization transformation for homogenizing the notation and making it fit for the next (automatic) steps. Then, the domain model and the workflow model undergo an integration transformation phase that produces the workflow-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 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 tool.

3. Benefits of our lightweight approach to process enforcement

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, a unified 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 a platform-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 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.

4. 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.

The next figures show an example of a domain model, a workflow model and the resulting process-aware model that stores all the process-related information (to be then evaluated with the also automatically generated OCL constraints).

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.

5. 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 as process 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 the 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.

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].

As an example we list the constraints to control the sequence flow between two activities (refer to the paper for the full set of translation mappings for all major BPMN modeling primitives).

A sequence flow between two activities A->B indicates that the first activity must be completed before starting the second one. 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:

The first constraint is defined over the entity type corresponding to the destination activity ( in the example B) 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 seq₁: previous->size()=1 and previous->exists(a | a.oclIsTypeOf(A) and a.status=‘completed’)

The other two required constraints are the following: (i) A constraint  over the second activity to prevent the creation of two different B instances related with the same A activity instance

context  B  inv  seq₂:   B.allInstances()->  isUnique(previous)

and (ii )A constraint 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 instance

context Case inv seq₃: status=‘completed’ implies self.activity-> select(a a.oclIsTypeOf(A) and a.status=‘completed’)->forAll(a| a.next->exists(b | b.oclIsTypeOf(B)) and a.next->size()=1)

6. 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 platform  can also cope with the automatic generation of our workflow-extended schema in the same platform , 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.