Pattern 5 (Horizontal Modularization)

FLASH animation of Horizontal Modularization pattern

Description

This pattern captures features to partition a pro- cess model into peer modules.

Purpose

To increase maintainability by breaking down a process model into smaller and more easily manageable parts, the ownership of which may be assigned to different users. Hence, to facilitate collaboration. To reduce clutter in those models where long or crossing edges cannot be avoided. To foster reuse of modules within the same process model or across different process models.

Example

Fig. 6a shows how the model in Fig. 3b has been decomposed into two parallel modules: "Home Loan" and "Sign", which communicate via message exchange. Process model "Sign" can now also be used by a third model, namely "Student Loan", thus increasing reusability. The model in Fig. 3b actually focuses on the loan registration part of a larger, end-to-end process model for handling loans, where "Register Loan" is preceded by "Merchandize" and followed by "Handle Loan". This model can thus also be decomposed into multiple sequential modules, e.g. one per logical part. Fig. 6b shows the "Register Loan" module which is connected to the other modules via Link Events. Moreover, the "Sign Loan" part has been extracted from "Register Loan" and modeled separately.

Metrics

Reduces module size (by replacing a model fragment with a single element referring to that module), and increases models. It may also increase model size if the fan-in of the module being introduced is one.

Rationale

Reducing model size positively affects model un- derstanding [80]. Decomposing a process model into modules fosters reuse of shared modules [5], [71].

Realization

UML ADs, BPMN and BPEL offer features to represent parallel process modules via message exchange. UML ADs offers the concept of Partitions to divide a process model in peer modules. BPMN provides Pools to create peer modules and Message Flows to connect a source node in one Pool to a target node in another Pool. BPEL supports synchronous and asynchronous inter-process communication via the Invoke, Receive and Reply activities, which link to a BPEL process counterpart via a PartnerLink. BPMN also offers the Signal event to synchronize the control-flow in dif- ferent modules. The different between these languages is that only in BPEL the modules are completely independent, while in UML ADs and BPEL reuse of a module is limited within the same process model. Other languages such as eEPCs and Protos provide constructs to capture external connections (e.g. Events in eEPCs and Triggers in Protos) but these cannot be used to formally link two process modules. Sequential modules can be obtained in BPMN via the Link Event which interrupts the flow after a source node and before a target node. The corresponding construct in UML ADs is the Activity Edge Connector, in eEPCs it is the ProcessInterface while in Protos it is the Off-Page Connector. Generally, the above concepts are supported by tools. For example, both Signavio and Protos allow users to jump from two corresponding Link Events, resp., Off-Page Connectors. In the literature, [34] defines a mechanism to partition large BPMN models sequentially by cutting those edges with numerous bends and crossings and inserting two pointers at the two ends of each cut edge. The objective is to obtain subgraphs of nearly equal size while keeping the number of cut edges low. Worklets [9] are a mechanism to deal with highly-flexible process models. A Worklet is a process fragment capturing a specific process scenario, i.e. variant within a given process model. Various Worklets can exist for a given variation point and one of them will be activated at run-time based on the evaluation of a set of ripple-down rules. This approach has been implemented in the YAWL system where Worklets can be defined to tasks via the Rules Editor, and instantiated via the Worklet Service. A similar mechanism is provided in [38], where a large, unstructured Petri net can be represented as a set of partially- ordered, acyclic process fragments called Oclets. Each Oclet captures a specific scenario of a given process together with information indicating when the scenario occurs. This idea of capturing a process model as a set of partially-ordered runs is also put forward in [31], [15]. Proclets [6] are lightweight Workflow nets which interact via message exchange and have knowledge of previous interactions. A process model is a set of Proclets that are instantiated and coupled according to an underlying business object model. This approach is introduced to deal with highly-interactive business processes.