Pattern 4 (Vertical Modularization)

FLASH animation of Vertical Modularization pattern

Description

This pattern captures features to decompose a model into vertical modules, i.e. subprocesses, according to a hierarchical structure.

Purpose

To increase understandability of large process mod- els by "hiding" process details into sub-levels. To decrease redundancy and foster reuse by referring to a subprocess from several places within the same process model or from different process models in a repository. The maintenance of a process model (repository) is also decreased, as a change to a subprocess needs only be performed in one place.

Example

Fig. 5 shows the vertical modularization of the model in Fig. 3b in three hierarchical levels.

Metrics

Increases depth and models, and reduces module size by replacing a model fragment with a single element referring to that module. It may increase the overall model size if the fan-in of the module being introduced is one, because for each extracted module a node needs to be inserted in the root model to refer to that module. Modules overhead needs to be controlled (i.e. it is pointless to factor out single model elements or very small process fragments to subprocesses).

Rationale

Hiding process details into sub-levels increases understanding [99] and fosters reuse [5], [71]. Smaller models are less error-prone [79] and easier to maintain [81] than larger ones. Reducing redundancy helps avoid inconsistencies, since redundant fragments may be edited by different users simultaneously [113].

Realization

Most languages offer modeling constructs to cap- ture vertical modularization. UML ADs provide the notion of Activity to encapsulate subprocesses, as opposed to atomic Actions. In eEPCs models of different types can be assigned to different element types. For example, a Function can be decomposed into an eEPC capturing a subprocess, an Event can be decomposed into an Event diagram capturing more detailed sub-events, and an Organizational unit can be decomposed into an Organizational chart. In BPMN 2.0 a Task can be decomposed into a Collapsed Subprocess (the subprocess is available as a separate module) or as an Ex- panded Subprocesses (the subprocess is represented within the Task box itself). BPMN requires a different construct (the Collapsed Call Activity Task) if the subprocess to be invoked is external (i.e. it is a standalone process model), rather than an internal module. In YAWL, BPEL and Protos subprocesses can only be invoked internally via a Compound Task (YAWL), Scope Activity (BPEL) or Sub-process element (Protos). For correctness purposes, YAWL and BPEL only accept single- entry single-exit subprocesses. Tools offer different degrees of support for this pattern. Some simply allow the specification of pointers to subprocesses (e.g. the YAWL Editor), others allow process hierarchies to be traversed (e.g. Oracle JDeveloper, Signavio), and some also offer a tree-like representation of the hierarchy (e.g. Protos and ARIS). General recommendations are also available for modularizing a process model vertically: [70], [13] suggest to encapsulate only single-entry single- exit (SESE) fragments in subprocesses and [114] provides a method for automatically detecting SESE fragments based on the RPST decomposition. Moreover, [54], [105] suggest to introduce subprocesses in models with 5–15, resp., 5–7 nodes, while [81] suggests to decompose models with more than 50 nodes based on empirical evidence. The positive effects of vertical modularization on process model understanding have been studied in [99]. A mechanism to automatically extract cloned fragments in large process model repositories and capture them as globally available subprocesses, is envisaged in [117], while an algorithm to detect such clones is defined and implemented in [113].