Pattern 6 (Orthogonal Modularization)

FLASH animation of Orthogonal Modularization pattern

Description

This pattern captures features to decompose a process model along the crosscutting concerns of the modeling domain, which are scattered across several model elements or modules. Examples of concerns are security, privacy and exception handling.

Purpose

To enable separation of concerns and distribution of responsibilities. To facilitate maintenance of individual, concern-specific process models.

Example

Fig. 7a shows a more detailed representation of the "Process loan" subprocess from Fig. 5, which includes further tasks to deal with the security aspect related to loan processing. Fig. 7b shows the orthogonal modularization of this process across its security aspect. The tasks related to this aspect have been extracted and captured in a separate model which is accessible by the first two activities of "Process loan". These activities are instantiated at the join point in the "Security aspect" model.

Metrics

Increases models, as "concern-specific" process mod- els are introduced. Decreases the model size when a concern is associated with several process models, as its specification is defined in a single place.

Rationale

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

Realization

Aspect-oriented modularization [24] is an appli- cation of this pattern. This approach is inspired by aspect- oriented programming and defines extensions to workflow languages in general [23], BPEL [24] and BPMN [22], to represent non-functional aspects of a business process such as security and logging, as separate, reusable modules. The notions of joint point, pointcut and advice used in aspect ori- ented programming, are adopted in this context. For instance, Fig. 7 shows a BPMN model extended with such notions. During process execution, when the task associated with a pointcut is reached, the module (i.e. advice) specified for the corresponding aspect is triggered. Its join point task is then substituted with the task triggering that advice. An advice can be executed before or after a join point, although more advanced mechanisms can be envisaged, e.g. in parallel to the join point. Various aspects can be associated with the same activity and a concern may include more than one module, e.g. different levels of security could be captured via different mod- ules. Orthogonal modularization is also applied to deal with exceptions. The basic idea is to avoid unnecessary cluttering of a process model by extrapolating those procedures to handle possible exceptions from the main process flow. In BPMN 2.0, exceptions can be handled outside the normal process flow via an Event Subprocess. These subprocesses are triggered by the occurrence of a given event, and can either run in parallel to the main process flow (Non-Interrupting Event Subprocess) or in alternative to the main flow (Interrupting Event Subprocess). In UML ADs exception routines are specified in separate Exception Handler activities which are connected to the main activities where exceptions may occur via an Interrupt Flow arc. Similarly, in BPEL Fault Handlers can be attached to a Scope activity or to a global process model. These features are generally provided by the respective tools. [8] proposes to capture exception handling routines via the notion of Exlet. An Exlet specifies how an exception influences a running task, process instance, or all instances of a process model, and can be assigned a compensating routine in the form of a Worklet to be performed when the given exception occurs. This approach is supported in the context of the YAWL language by the Rules Editor and the Exception Service available in the YAWL system.