Introduction

This is Part 3 of a four-part series introducing IBM Pattern-based Process Model Accelerators V2.0 for WebSphere Business Modeler (hereafter referred to as the accelerators). These accelerators provide a set of plug-ins for IBM WebSphere Business Modeler (Modeler) that add patterns, transformations and refactorings to your business process modeling environment. The plug-ins also include a feature to automatically detect and correct control-flow errors

By using the accelerators you move away from a traditional business process modeling approach where process models are drawn by dragging and dropping elements on the drawing canvas that are then manually connected. The accelerators enable you to create business process models of higher quality by composing them from larger building blocks or by applying semantically correct change operations to your entire model with a single click. Your models will contain significantly less modeling errors, modeling becomes a much more fun exercise and you will experience productivity gains of about 70% compared to the traditional approach.

In this Part 3, we'll discuss the transformations provided in this release of the accelerators. A transformation is a complex change to a business process model that you can apply with a single click. You can think of it as a macro-editing operation that contains a sequence of several editing steps that add, delete, or modify elements in your process model.

The following transformations are available in this release of the accelerators:

• Duplicate Element
• Merge Elements
• Replace Global Process
• Remove Region
• Associate Data
• Autolink Elements
• Toggle Gateways
• Reorder Sequence
• Convert to Alternative Compound
• Convert to Sequence

Back to top

Prerequisites

It is assumed that you have completed Part 1 of this series, which means that you have done the following:

• Installed WebSphere Business Modeler V6.2.0.1 with Fixpack 1
• Installed the accelerators and worked through the example modeling project HiringExample.mar

We also assume that you have basic familiarity with using Modeler to create business process models. You should also be familiar with the basic model elements such as gateways, tasks, subprocesses, and start and terminate events from the Business Process Modeling Notation (BPMN) available in WebSphere Business Modeler. For more information, refer to the Modeler Information Center.

Part 1 of this series gave you detailed information on downloading the accelerators and how to install them as well as how to validate your installation. Part 1 also introduced you to five of the available transformations: Autolink Elements, Convert to Alternative Compound, Merge Elements, Associate Data, and Toggle Gateways. In addition, it introduced you to the Control-Flow Analysis that allows you to easily locate modeling errors in your process model. Part 2 described the available process patterns and explained how to configure the Accelerators palette.

Back to top

General hints on how to use the transformations

In this article, we describe in detail all available transformations. Following Fowler and the common guidelines for the description of patterns, we describe a transformation (and, in Part 4, a refactoring) using the following information:

• Transformation Name: A descriptive name that helps to identify and refer to the transformation.
• Intent: A description of the goal behind the transformation.
• Motivation: Reasons for using the transformation and circumstances under which it is not applicable.
• Mechanics: A concise step-by-step description of how to apply the transformation. As our transformations encode a complex editing operation in a single click, we focus on describing the preconditions, i.e., how to correctly select the model elements to which the transformation is applicable, and the effects, i.e., the change that happens to your model.
• Samples: One or more examples showing how the transformation works.
• Related transformations: If applicable, we point you to selected patterns, transformations, and refactorings in this release of the accelerators that are especially useful when being combined with the described transformation.

A transformation is usually applied to a selected set of model elements, which can be connections, activities, gateways, and events. When you have nothing selected, a transformation is either applied to your whole model or is not applied at all, depending on what the transformation does.

After selecting your model elements, you have two choices to invoke a transformation, as described in Part 1:

• Click on the drawing canvas of your business process model diagram and then invoke the transformation at the bottom of the pull-down menu, or
• Click on the corresponding graphical symbol in the Accelerators palette.

We recommend that you save your model before applying a transformation. This makes it easier for you to undo unwanted changes by simply discarding a model and reopening it again in its last saved state. Alternatively, you can use the Modeler undo function to undo each of the individual editing operations applied by a transformation..

Back to top

Duplicate Element transformation

Transformation Name: Duplicate Element

Intent: Creates a copy of a selected activity that inherits the attributes of the activity and its outgoing connections. Between the selected activity and its copy a new control-flow connection is added.

Motivation: Use this transformation to duplicate a selected local or global task, human task, business rules task or service, and to connect the selected activity with an outgoing connection to its copy. The copy inherits all attributes of the selected activity. Use the transformation when you are refining the activities in your model; for example, when you want to split the functionality that is encapsulated in one activity of your current model across two activities, but the two new activities will still share a large subset of attributes.

Mechanics: Select exactly one activity (local or global task, human task, business rules task, or service), but not a local or global subprocess or loop model element (While-Loop, Do-While Loop and For Loop in Modeler) and invoke the transformation. A copy of the selected activity is placed on the canvas to the right of the selected activity. All outputs of the selected activity are removed and added to the copy. Only a single control-flow output remains for the selected activity that is connected to the single control-flow input of the copy. Attributes, such as an associated organization or classifier, are inherited by the copy.

If you try to apply the transformation to a local subprocess, the following error message displays.

Samples: Our first example shows a selected business rules task at the left and the result of applying this transformation to this task on the right.

Our second example shows a human task named Review Application with a business item input and two business item outputs. The task is colored by organization unit.

The result of applying the Duplicate Element transformation to this human task is shown here:

The associated organization unit is inherited by the copy of the task.

Related transformations: This transformation is similar to the Insert Task pattern, but creates a new activity by reusing the attributes of an existing activity. In contrast to Insert Task, which only creates a task, this transformation can create human tasks and business rules tasks. The inverse transformation is Merge Elements.

Back to top

Merge Elements transformation

Transformation Name: Merge Elements

Intent: Takes two model elements of the same type that are directly connected and merges them into a single element of this type.

Motivation: Use this transformation when you want to simplify your model and the intended simplification implies to delete elements, while preserving the existing flow. The transformation is especially useful when you want to simplify branching flows by combining several gateways into a single gateway.

Mechanics: The Merge Elements transformation is applicable to pairs of directly connected gateways, local or global tasks, human tasks, business rules tasks, or services, but not to local or global subprocesses and loop model elements. To apply the transformation, you must select exactly two elements of exactly the same type, and these elements must have a direct connection. The transformation deletes the second element in the flow and reconnects all its outgoing connections by modifying the outputs of the first element.

When you select elements of different types, elements to which the transformation is not applicable, elements that are not directly connected, or more than two elements, the following error message displays:

Samples: Our first example reverses the effect of the Duplicate Element transformation described in the Duplicate Element transformation example. Select the two human tasks as shown in Figure 6.

Then invoke Merge Elements. The two human tasks are recombined by deleting the second task and adding any outputs of it to the first task as shown in Figure 7.

Our second example illustrates the effect of the transformation on connected decision gateways as shown in Figure 8. When merging two connected decisions as shown in Figure 9 , the second decision is removed, but its branches are combined with the branch of the first decision. The branch names and conditions are combined by "and," and the name of the first decision is preserved.

Note that any expressions that were defined for a branch are removed by the transformation, because they are not valid in the context of the combined gateway. We recommend that you verify the output conditions and their percentages after you apply the transformation to decision gateways, because the transformation cannot imply your intended decision logic.

Related transformations: The inverse transformation is Duplicate Element, but this transformation is applicable only to activities, not to gateways.

Back to top

Replace Global Process transformation

Transformation Name: Replace Global Process

Intent: Replaces a selected global process with another global process chosen by the user from the available processes in the current modeling project or its reference group.

Motivation: Reusing processes across several models is a common practice. When changing a process model A that is reused in a process model B, a change in A may make its reuse in B obsolete, requiring you to replace A by some other process (such as C) in model B. The Replace Global Process transformation allows you to easily perform such replacements.

Mechanics: Select a global process and invoke the transformation. A window displays that allows you to browse to the available process models in your workspace as is shown Figure 10.

Select a process from the list and click OK. The selected process replaces the process in the diagram and is connected to the existing flow by adding any missing inputs or outputs to the process. This modification of the inputs and outputs can make the occurrence of the global process in the current process model inconsistent with the global process definition in the workspace. This inconsistency is shown in the Errors view when saving the transformed model. In the example below, we'll show you how to address such an inconsistency. If you want to avoid any inconsistencies, replace processes only with other processes that have exactly the same inputs and outputs.

Samples: In our example, we show what happens if a global process is replaced by another global process that does not have all inputs and outputs defined to re-establish the existing connections in the process model.

The process model shown in Figure 11 reuses a Verify Goods process that has Bill, Order, and Package business items as inputs and outputs. Our goal is to replace the Verify Goods process with a simpler Verify Bill process that has only the Bill business item as an input and output.

The transformation adds the missing Order and Package business items to the Verify Bill process to reconnect it to the existing flow in the model. When saving the transformed model, an error is displayed that the process invocation of Verify Bill is no longer consistent with its global process definition, as shown in Figure 12.

You have two choices to address this error:

1. You can modify the global process definition of Verify Bill and add the required inputs and outputs. This will affect other process models that use this process, because you adjust a global process definition to the local requirements of one reusing process.
2. You can right-click on the process invocation of Verify Bill in the diagram and select Update Global Element from the menu, then save your model. The error is eliminated and only those inputs and outputs provided by the global process definition remain connected. With this second option, you adjust your local usage of a process to its global process definition. The resulting model is shown in Figure 13.

You should consider how any dangling inputs and outputs of a reused process are handled by your process model. In Figure 13, the Ship Goods task cannot execute because it does not receive the required Order and Package inputs anymore. In Figure 14, we've decided that these inputs are directly provided by the Provide Goods task.

Related transformations: None.

Back to top

Remove Region transformation

Transformation Name: Remove Region

Intent: Cuts out an entire connected region containing an arbitrary selection of connected model elements and reconnects the remaining flow.

Motivation: Use this transformation when parts of your model are no longer valid and you want to discard them, but you would like to reconnect the remaining flow in the model. The transformation behaves like a smart delete that removes elements from the model, but is capable of reconnecting the remaining ones.

Mechanics: Select an arbitrary but connected region of your model by clicking on one or more model elements or holding the left mouse button and dragging over an area to select all model elements in the area. Invoke the transformation. This deletes all selected elements and tries to reconnect the remaining flow by connecting those connections entering and leaving the region removed by the transformation. The automatic reconnection may not always lead to a correct control flow when the process model contains complicated flow logic involving parallel and alternative flows that are opened by forks and decisions and end in joins and merges. Figure 15 illustrates five possible situations, from left to right.

Note: Situation 1 is on the far left, situation 5 on the right.

Situation 1: If only a single control-flow input and output connection exist for the selected region, a so-called fragment is removed from the model (see Part 2). Removing a fragment always leads to a correctly reconnected flow.

Situations 2 and 3: If several control-flow input connections enter the selected region, but only one output connection exists or vice versa, a fork or join is added between the connections to reconnect them.

Situation 4 (combines Situations 2 and 3): Several control-flow input and output connections enter the selected region. Input connections are combined with a join, output connections are combined with a fork and the join and fork are connected with each other.

Situation 5: A single data-flow connection enters the selected region and a single data-flow connection leaves the selected region, and both data-flow connections have the same business item associated. The two connections are reconnected. In the case of several data-flow connections that enter or leave the selected region or if different business items are associated with the connections, the model becomes disconnected.

The reconnected flow can become incorrect in Situations 2, 3, and 4. For example, when incoming connections are opened by a decision gateway, they are now connected with a join introducing a deadlock into the model. See Part 1 for a discussion of control-flow errors and how to easily detect them using the Control-Flow Analysis provided with the accelerators. We recommend you run the Control-Flow Analysis whenever a region that has several incoming and outgoing connections is removed from the model.

In Situations 2, 3, and 4, the transformation won't always remove all gateways to allow the user to inspect the structure of the control flow that crosses the region borders and make manual changes if desired. We'll illustrate this in the example.

Samples: In our first example, we select and remove a fragment with a single incoming and outgoing connection as shown in Figure 16.

Following Situation 1, the fragment is removed and the two connections are merged into a single one as shown in Figure 17.

In our second example, we select a region of two tasks that are located on two separate flows, which are not connected to each other as shown in Figure 18.

The two tasks are removed, but the gateways remain in the flow connecting the empty branches with each other, as shown in Figure 19.

To remove both gateways, they must both be selected. This selection determines a fragment with a single incoming and a single outgoing connection, which is removed by the transformation.

Figure 20 shows the result of removing the merge gateway. The selection of the single merge gateway in Figure 19 determines a region with two incoming connections and one outgoing connection that is not a fragment. Situation 2 applies and a join is added to the model to reconnect the two incoming connections with the single outgoing connection. A deadlock is introduced into the model that must be manually resolved by, for example, applying the Toggle Gateways transformation to the join gateway, which changes it to a correct merge.

Related transformations: Apply the Control-Flow Analysis to validate your process model when a region with more than one incoming or outgoing connection was removed. See Part 1 for details on how to use the Control-Flow Analysis. Use the Toggle Gateways transformation to change any forks or joins to decisions and merges in case of a detected control-flow error.

Back to top

Associate Data transformation

Transformation Name: Associate Data

Intent: Assigns a new business item to selected connections or to all connections in a process model or removes an existing business item.

Motivation: Use this transformation when you want to change control-flow into data-flow and vice versa or if you want to modify existing data flow.

Mechanics: Select an arbitrary region of your process model or specific connections and invoke the transformation. A window displays that allows you to browse the business items that are available in your modeling project, as shown in Figure 21.

Select either No type, Basic type or Complex type. If you select Complex type, select one of the available business items. Then click OK. If you select No type, all business items that are associated with the selected connections are removed, leaving only control flow in the selected region of your model. If you select Basic type or Complex type, the selected business item is associated with the selected connections changing or adding data flow in your process model. The types of inputs and outputs of tasks or gateways involved in the selected connections are modified accordingly.

If no model element or connection is selected, the transformation is applied to the entire model.

If control flow is changed to data flow on connections that include start and end or terminate events, the transformation adds an input and output for the associated business item to the process model. It reconnects the flow to this input and output and the events are removed from the model. If data flow is changed to control flow, new start and terminate events are added to the model. The data inputs and outputs of the process mode are not removed in order to preserve the existing process interface.

When associating data with connections that involve global processes, the interface of the global process is modified. This can lead to inconsistencies that are reported in the Errors view when saving the model. See the example provided with the Replace Global Process transformation for information on how to address and resolve such inconsistencies.

Note that you cannot use the Associate Data transformation to change the data flow in and out of repositories because this flow should remain consistent with the type of the business item associated with the repository.

Samples: The example in Figure 22 shows an application of the transformation to an entire process model with no elements selected. The Application business item is chosen as the parameter of the transformation. It is applied to all connections in the example model except the one connecting to the repository.

Note that the start event is removed and that the Application business item becomes an input of the process. The Text business item on the repository connection remains unchanged.

Related transformations: None.

Back to top

Autolink Elements transformation

Transformation Name: Autolink Elements

Intent: Automatically connects model elements that are placed on the canvas following simple layout guidelines.

Motivation: Eliminates manually clicking on inputs and outputs and drawing a connection between them. Instead, you can place activities on the canvas following simple layout guidelines and let the Autolink Elements transformation connect these elements for you and even insert the right gateways between them.

Mechanics: The transformation can be applied to both unconnected and partially connected models to quickly create complex business processes. If no model elements are selected, the transformation tries to connect all model elements on the canvas, otherwise, it connects only the selected elements.

The following simple rules are applied by the transformation:

• If tasks are to be connected in a sequence, they should be placed close to each other in an approximate row.
• If tasks are to be connected such that they occur on different branches of a decision, they should be placed in an approximate column.
• A gateway is added to the model when there is sufficient space between a row and a column of tasks.

The Autolink Elements transformation may result in a partially connected model when the transformation cannot clearly determine which layout rules apply to the model elements.

Samples: The example shown in Figure 24 illustrates the layout rules. Note that the start event, the Receive Order task, the Ship Order task, and the terminate event are placed in an approximate row. Between the Receive Order task and the Ship Order task, three more tasks are placed in an approximate column. Notice that we left sufficient space between the Receive Order task on the left and this column of tasks and the Ship Order task on the right such that a gateway fits between them.

Invoking the Autolink Elements transformation with no model elements selected, then applying the Auto-Layout, results in the process model shown in Figure 25. A decision and merge gateway are added to the model such that the tasks in the column are placed on three branches that are connected by these gateways. All model elements are connected.

By default, the transformation only adds decision and merge gateways to create alternative branches. It doesn't know whether the user wants to create alternative or parallel flow. Use the Toggle Gateways transformation to change decision and merge gateways to forks and joins.

The next example shows how to apply the Autolink Elements transformation to partially connected models. We'll reuse the example from Figure 25, but remove its start and terminate events as shown in Figure 26.

Next we'll place the Approve Order task above the existing column of tasks. Our goal is to add another branch to the existing decision and merge. Select the new task and both gateways as shown in Figure 27, and invoke the Autolink Elements transformation.

A fourth branch is added to the decision and merge gateways. Note that selecting the gateways is critical for the transformation to correctly connect the new task. More than one task can be placed on a single branch by arranging several tasks on a row.

Next we'll place this entire process fragment on a branch within another decision. Add the tasks Create Order, Suspend Order, and Print Order Information on the canvas as shown in Figure 29.

Then invoke the transformation again with no model elements selected. A new decision and merge gateway are added, as shown in Figure 30. (See a larger version of Figure 30.)

Note that a gateway is only added if there is at least one task placed before or after a column of tasks. In our example, this means that the Create Order and Print Order Information tasks are essential – they are placed before and after a column of tasks made up of the Suspend Order task and the fragment delimited by the Receive Order and Ship Order tasks. The Autolink Elements transformation therefore recognizes the new branch that is intended for the Suspend Order task and the need to connect this new branch with a newly introduced decision and merge.

Related transformations: The Toggle Gateways transformation is very useful to change a decision to a fork and a join to a merge and vice versa. To place more activities on a created connection, use the Insert Task, Insert Process or Sequence pattern (see Part 2). To add data flow to your model, use the Associate Data transformation.

Back to top

Toggle Gateways transformation

Transformation Name: Toggle Gateways

Intent: Toggles a selected gateway, that is, it converts a fork to a decision and vice versa and converts a join to a merge and vice versa.

Motivation: Use this transformation to convert parallel branches into alternative branches and vice versa. Use it also to correct modeling errors that are caused by incorrectly paired gateways, for example, to change an incorrect decision/join pair to a correct decision/merge pair.

Mechanics: To apply the transformation, select a single gateway that you want to toggle. The transformation is applied to this gateway and to all correctly matching gateways. This means that, when you apply the transformation to a merge that pairs with a decision, the decision and the merge are changed to a fork and join. To detect matching pairs (or more generally matching sets of parallel and alternative gateways), the transformation analyzes the structure of the process model and toggles all those gateways that must be toggled for the control flow to remain correct. When a control-flow error exists in the model involving the selected gateway (see Part 1), only the selected gateway is toggled, helping the user to change incorrect gateways.

When no gateway is selected, the transformation is applied to the whole model if no control-flow errors are detected. Otherwise, no toggling of gateways takes place.

Samples: The first example illustrates the toggling of matching gateways in a correct process model. We start from a part of the Evaluate Candidate process that we used in Part 1,as shown in Figure 31. In this part of the process, two decisions are paired with a single merge.

Select the merge gateway and invoke the Toggle Gateways transformation. The merge and both decisions are toggled in order to preserve the correctness of the process model as shown in Figure 32. The three alternative branches are converted into corresponding parallel branches. Toggling only the merge would have introduced a deadlock into the process model.

The second example illustrates the behavior of the Toggle Gateways transformation on a model with a control-flow error. In this example, two forks are incorrectly paired with a closing merge, which leads to a process model with a lack of synchronization error. Select the merge as shown in Figure 33.

Invoke the Toggle Gateways transformation. Only the merge is toggled to a join correcting the error in the model as shown in Figure 34.

Our third example illustrates that the Toggle Gateways transformation does only affect matching gateways in a model. For this purpose, we embed the example in Figure 34 into a decision/merge pair and select the second fork as shown in Figure 35.

Now invoke the Toggle Gateways transformation. It only toggles the matching forks and their join, but leaves the outermost decision and merge unchanged as shown in Figure 36. Similarly, when toggling the first decision, Evaluate Candidate, only its matching merge (on the far right in Figure 36) is be toggled.

Related transformations: The Activity to Gateway Form refactoring can be applied to transform multiple incoming and outgoing connections of an activity to the corresponding gateway structure, which then allows you to toggle this gateway. The Merge Elements transformation is useful in combining several gateways into a single gateway. To add missing closing gateways to a model, use the Merge or Join Process Ends and the Close Branches refactorings. We'll describe refactorings in more detail in Part 4 of this series.

Back to top

Reorder Sequence transformation

Transformation Name: Reorder Sequence

Intent: Reorders selected activities in a sequence based on a new order that is provided by the user clicking on the model elements.

Motivation: Reordering the steps in a process model is a common change. Either the order of activities that are already in sequence must be changed or activities must be moved elsewhere in the process flow. Such a reordering is a very time-consuming step, requiring users to manually delete and redraw connections. The Reorder Sequence Transformation facilitates this change.

Mechanics: The Reorder Sequence transformation is applicable to all activities, including tasks, local and global processes, business rules tasks, and human tasks, as well as loop model elements that don't have more than one incoming and one outgoing connection. Press and hold the Shift key and click on the elements in the order you want to create, then invoke the Reorder Sequence transformation on the selected elements. The selected elements are moved after the first element you selected and control-flow connections are created between them. When elements are connected with a single data-flow connection, the associated business items are preserved and any required but missing inputs and outputs are added to the reordered activities to establish a new connection. The positioning of the model elements on the drawing canvas is not changed. Use Auto-Layout to properly lay out the modified process model.

If only a single element is selected or elements to which the transformation is not applicable occur in a selection, the following error message is displayed.

Activities can't be reordered if they're connected with multiple connections. In this case, the following error message is displayed.

Samples: Our example shows a sequence of model elements of different types that we want to order alphabetically.

To define the new order, press and hold the Shift key then click the following model elements in order: Business Rules Task, Process 2, Subprocess, Task, While Loop. The sequence of clicks determines the new order. Apply the Reorder Sequence transformation to reconnect the elements in the specified order as shown in Figure 40.

The positioning of the elements on the canvas is not changed by the transformation. Invoke Auto-Layout from Left to Right to adapt the positioning to the new sequential order. The result is shown in Figure 41.

The second example illustrates a scenario of moving a task to the beginning of an alternative branch. We use the initial part of the Handle Signed Contract process from Part 1. After the merge gateway, we added a Confirm Receipt task that we would like to move to the beginning of the Yes branch before the Verify Necessary Signatures task. To make this change, press and hold the Shift key and click on the Yes branch first, then on the Confirm Receipt task as shown in Figure 42. Note that you must have the output branch selected, not the connection from the decision gateway to the first model element on the branch.

Invoke the Reorder Sequence transformation. The desired change is applied to the model as shown in Figure 43.

Apply Auto-Layout to adjust the layout to the change.

Related transformations: The Convert to Alternative Compound transformation takes a set of selected model elements that occur in a sequence and places them on several alternative branches. The Convert to Sequence transformation removes alternative branches from a model and arranges the model elements in a sequence.

Back to top

Convert to Alternative Compound

Transformation Name: Convert to Alternative Compound

Intent: Takes a set of model elements that are connected in a sequence and places them on different alternative branches embedded within a decision and a merge gateway.

Motivation: An initial version of a business process model is often created by defining a sequential process flow. When later refining the model, one realizes that certain activities should occur on different branches of the flow and that gateways must be added to the model. The transformation allows a user to split sequences of tasks across alternative branches that are automatically added to the model.

Mechanics: The Convert to Alternative Compound transformation is applicable to all activities, including tasks, local and global processes, business rules tasks, and human tasks, as well as loop model elements that have not more than one incoming and one outgoing connection. To apply the transformation, click on the activities in a connected sequence that should begin the new alternative branches in the model, then invoke the Convert to Alternative Compound transformation. For each selected activity, a new branch is created. The selected activity becomes the first activity of this branch. All activities that follow this selected activity and that have not been selected are also added to this branch. All non-selected tasks that precede the first selected task are moved before the decision gateway. This means that by selecting activities in a sequence the user specifies subsequences for each of the alternative branches.

If activities are selected that occur on different alternative or parallel branches, the following error message is displayed.

Samples: In the example process shown in Figure 46, the Review Order and Check if Available tasks have been selected.

As a result, two branches are created, as shown in Figure 47. The selected tasks are placed on these branches as the first tasks followed by their successor subprocesses or tasks. The Receive Order task that precedes the first selected task is placed before the decision.

Related transformations: The Toggle Gateways transformation can be used to change the created alternative compound to a parallel compound. The Reorder Sequence transformation makes it easy to reposition activities within a newly created branch. Convert to Sequence is the dual transformation that takes a set of selected activities that occur on different branches in a model and orders them in a sequence.

Back to top

Convert to Sequence

Transformation Name: Convert to Sequence

Intent: Transforms an alternative or parallel fragment of a process model into a sequence of activities deleting all gateways.

Motivation: The Convert to Sequence Transformation removes alternative or parallel branches from a model, but keeps all activities on these branches. The activities are arranged in a new sequence. Such a change occurs when, for example, the branching structure in a model is obsolete and must be changed completely or when branches have been removed and only a single or a few branches are left that a user wants to turn into a sequence. Making such a change manually would require the step-by-step deletion of all gateways and the manual reconnection of the affected activities.

Mechanics: The user selects a single task or gateway. The selected model element determines a fragment that encloses this element. A fragment is a part of the process model that is connected with one incoming and one outgoing connection to the remaining model (see Part 2). All gateways in this fragment are removed and the activities contained in the fragment are ordered within a sequence. Each activity in the fragment must have only one incoming and one outgoing connection, otherwise the transformation is not applicable. The sequence is built by joining the individual branches starting from the top-most branch in the diagram and proceeding until the lowest branch is reached.

The positioning of the activities on the canvas is not changed by the transformation. Apply Auto-Layout to improve the layout of the model.

If you select a model element that is not a gateway or an activity, or select more than one model element, the following error message is displayed.

In a complex model, large fragments can contain smaller fragments. When applied to a fragment, the transformation won't affect the structure of any of the contained smaller fragments; in other words, these nested fragments preserve their gateway structures. We'll illustrate this in the examples.

Samples: This example illustrates the behavior of the Convert to Sequence transformation on a model with several nested fragments. Figure 49 shows an example model with two highlighted fragments. We want to apply the Convert to Sequence transformation to the Fullfill Order task, so the Fulfill Order task is selected. It is contained within a fragment that begins with a decision and ends with a merge. Within this fragment, we highlighted a smaller fragment that starts with a fork and ends with a join.

Invoke the Convert to Sequence transformation with the Fulfill Order task being selected. The decision and merge are removed and the Fulfill Order and Reject Order tasks are placed within a sequence beginning with the Receive Order task. The result is shown in Figure 50. The inner fragment of this process model is not affected by the transformation--its fork and join gateways are preserved.

If we had selected one of the tasks in the fragment delimited by the fork and join gateway, such as Check Payment, Order From Stock or Determine Shipping, the fork and join would have been removed and the three tasks would directly follow the Fulfill Order task. The decision and merge gateways of the outer fragment would not be affected. Figure 51 shows the result of the Convert to Sequence transformation applied to the Check Payment task before the Auto-Layout.

Related transformations: The Reorder Sequence transformation can be used to change the order of the activities in the sequence that is created by the Convert to Sequence transformation. Additional activities can be added to the sequence by using the Insert Task, Insert Process, or Sequence patterns. (See Part 2.) To remove any part of the process model, use the Remove Region transformation. Convert to Alternative Compound is the dual transformation that takes a set of model elements that are connected in a sequence and places them on different alternative branches embedded within a decision and a merge gateway. To change an Alternative Compound to a Parallel Compound, use the Toggle Gateways transformation.

Back to top

Summary

In this article, you learned about the business process model transformations available in Release 2.0 of the IBM Pattern-based Process Model Accelerators for WebSphere Business Modeler. Each transformation encapsulates a complex change in a single click. We described the purpose and usage of each transformation, how to correctly apply each transformation to selected model elements, and what effects the transformation has. We provided examples illustrating the power of each transformation.

By using the transformations and combining them with the patterns that we described in Part 2 and the refactorings (that we will describe in greater detail in Part 4), you can apply changes to process models in a more efficient manner.

Resources

Learn

• IBM Pattern-based Process Model Accelerators for WebSphere Business Modeler Part 1: Understand Process Patterns and Quality & Change Management during Process Modeling (developerWorks,June 2009): This tutorial teaches how to compose your business process model by instantiating predefined patterns, and how to apply complex changes to your model with a single click by invoking a transformation or refactoring.
  
  
• IBM Pattern-based Process Model Accelerators for WebSphere Business Modeler Part 2: Patterns advanced usage and accelerators palette configuration (developerWorks,June 2009): Part 2 shows you how to apply patterns with business items and business item states to create pattern-based process models with data flow. It also describes how to configure the accelerators palette to suit your needs.
  
  
• N. Russell, A.H.M. ter Hofstede, W.M.P van der Aalst, and N. Mulyar: Workflow Control-Flow Pattern Library: A revised View. BPM Center Report BPM-6-22, BPMcenter.org, 2006.
  
  
• M Fowler: Refactoring: Improving the Design of Existing Code, Addison-Wesley. 2008.
  
  
• Tutorials and Samples for WebSphere Business Modeler Version 6.2: Learn about business process modeling with WebSphere Business Modeler V6.2 and download additional example models.
  
  
• WebSphere Business Process Management V6.2 Information Center: Access more information about Business Process Management with WebSphere V6.2
  
  
• T. Gschwind, J. Koehler, J. Wong: Applying Patterns during Business Process Modeling. Proceedings of the 6th Intern. Conference on Business Process Management, Springer 2008.This article describes the scientific foundations underneath the capabilities described in this article.
  
  
• R. Kong: Modeling business processes in WebSphere Business Modeler for BPEL transformation, IBM developerWorks, January 2008. Modeling business processes in WebSphere Business Modeler for BPEL transformation IBM developerWorks, January 2008.
  
  
• J. Koehler, J. Vanhatalo: Process anti-patterns: How to avoid the common traps of business process modeling, Part 1 (developerWorks, Feb 2007): This article describes typical modeling errors in process models and how to recognize them.
  
  
• J. Koehler, J. Vanhatalo: Process anti-patterns: How to avoid the common traps of business process modeling, Part 2 (developerWorks, April 2007): Part 2 of this series further describes data-flow modeling errors commonly found in process models.
  
  
• developerWorks BPM zone: Get the latest technical resources on IBM BPM solutions, including downloads, demos, articles, tutorials, events, webcasts, and more.
  
  

Get products and technologies

• Trial: IBM WebSphere Business Modeler Advanced: Download a free trial version of IBM® WebSphere® Business Modeler Advanced V6.2, IBM’s premier business process modeling and analysis tool for business users that offers process modeling, simulation, and analysis capabilities to help business users visualize, understand, and document business processes for continuous improvement. .
  
  
• Download: Process Model Accelerators for WebSphere Business Modeler: Download ta set of plug-ins for IBM WebSphere Business Modeler V6.2 that add patterns, transformations and refactorings to the business process modeling environment.
  
  

Discuss

• Forum: WebSphere Business Modeler and WebSphere Business Modeler Publishing Server : This forum is for WebSphere Business Modeler and WebSphere Business Modeler Publishing Server customers to post questions and share experiences and solutions .
  
  

About the authors

Thomas Gschwind is a research staff member at the IBM Zurich Research Laboratory and a lecturer at the university of Zurich. His research interests are business process modeling and software engineering. Thomas has developed the software technology foundations underlying the patterns, and led the conceptual design and implementation of the refactoring and transformation operations. You can reach Thomas at thg@zurich.ibm.com.

Jana Koehler is a Research Staff Member and manager at the IBM Zurich Research Laboratory. She works on technologies for business process management and distributed systems, and leads the Business Integration Technologies team at the lab. Jana has contributed to the conceptual design of the patterns, refactoring, and transformation operations, and has authored the technical documentation. You can reach Jana at koe@zurich.ibm.com.

Janette Wong is a Senior Technical Staff Member at IBM. She leads patterns work in the BPM area. Currently she focuses on process patterns and collaborates with other subject matter experts in patterns areas such as connectivity and integration.

Cedric Favre is a graduate of the Ecole Polytechnique Fédérale de Lausanne, Switzerland, and a PhD student at the IBM Zurich Research Lab. He designed and implemented the Control-Flow Analysis as part of his Master's thesis during an internship at the IBM Zurich Research Lab. You can reach Cedric at ced@zurich.ibm.com.

Wolfgang Kleinoeder is an IBM Research emeritus at the IBM Zurich Research Laboratory working on implementing and testing the Pattern-based Process Model Accelerators. You can reach Wolfgang at wbk@zurich.ibm.com.

Alexander Maystrenko is a graduate of the Kiev Polytechnic Institute, Ukraine, and PhD student working at the IBM Zurich Research Laboratory. He helped implement the refactoring and transformation operations during an internship at the IBM Zurich Research Laboratory. You can reach Alexander at oma@zurich.ibm.com.

Krenar Muhidini is a student at Jacobs University Bremen and was a summer intern in the IBM Zurich Research Laboratory helping to implement the Pattern-based Process Model Accelerators.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Prerequisites
• General hints on how to use the transformations
• Duplicate Element transformation
• Merge Elements transformation
• Replace Global Process transformation
• Remove Region transformation
• Associate Data transformation
• Autolink Elements transformation
• Toggle Gateways transformation
• Reorder Sequence transformation
• Convert to Alternative Compound
• Convert to Sequence
• Summary
• Resources
• About the authors
• Comments

Next steps from IBM

• Try: WebSphere Business Modeler Advanced
• Briefing: Building SOA solutions and managing the service lifecycle
• Buy: WebSphere Business Modeler Advanced

My developerWorks community

Dig deeper into WebSphere on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers