Process languages such as the Business Process Model and Notation 2.0 or the Web Services Business Process Execution Language promise the portability of executable artifacts among diferent runtime environments, given these artifacts conform to the respective specification. However, due to the natural imperfectness and difering priorities of runtime environments, actual portability of process code is often hard to achieve. A first step towards tackling this problem is the quantification of the actual degree of portability of process code using software metrics. The ISO/IEC 25010 software quality model defines portability as a main software quality characteristic with several sub-characteristics. One of these is adaptability, the degree to which a piece of software can be adapted in order to be executed in a diferent environment. In this paper, we propose a mechanism for quantifying the degree of adaptability of BPMN 2.0 processes and demonstrate its computation.
A central part of process-aware applications is the runtime platform for executable process models. To run on such a platform, processes need to be tailored to it, thus often locking them into that particular platform. This lock-in efect is undesirable. Application portability addresses this issue.
A way to improve the portability of an application is by programming it
according to an open specification that promises the portability of the outcome.
This is the route taken for various process languages [
A first step towards tackling this problem is the ability to quantify it: to
be able to compute a degree of portability, or adaptability, for a given process
implemented in a particular language using software metrics. This could yield
several benefits, as for instance:
1. When integrated into a metrics suite, developers could continuously inspect
the portability or adaptability of the process during development. This would
allow them to get direct feedback for changes they introduce and make them
aware of changes that limit portability or adaptability [
As a basis for such a quantification, the ISO/IEC 25010 software quality
model [
We have to emphasize that the purpose of this paper is the proposal and
description of the mechanism and metrics. Due to this scope and the page limit,
we defer the important aspect of the validation of the metrics, for instance in
terms of measurement theory [
The remainder of the paper is structured as follows: In the next section, we discuss related notions of adaptability and adaptability metrics. In section 3 we introduce our approach and explain our proposed metrics. Thereafter, we evaluate the approach by computing the adaptability degree for a use case process. Finally, we draw a conclusion and point to future work.
The ISO/IEC quality model defines adaptability as the “ degree to which a product
or system can efectively and eficiently be adapted for diferent or evolving
hardware, software or other operational or usage environments” [7, p. 15]. Here,
we focus on adaptions to the software environment only. The scenario we have
in mind is a required change of a set of processes to a diferent runtime engine.
If the processes cannot be ported directly, they have to be adapted to preserve
their executability. This is diferent to other views of adaptability, as for instance
in autonomous systems, where adaptability refers to the ability of the system
to automatically cope with changing situations, such as an increased load, at
runtime [
In this paper, we try to quantify adaptability in an abstract,
runtimeindependent fashion. Hence, we base the following metrics on the BPMN
specification [
The metrics for adaptability of the new ISO/IEC quality model [
Such structural metrics do primarily exist for the architectural layer of a
software product and not the concrete source code [
In the terms of BPMN, an atomic process element is an activity, task, or gateway. Using the above approach, we need to assign an adaptability score to each of those elements. Our idea is to count the number of alternative representations for the functionality provided by the element that result in the same runtime behavior. In BPMN, there are typically multiple alternatives for each process element that can result in identical process behavior at runtime. The more alternatives exist for a given process element, the easier it is to replace this element with such an alternative, and hence the more adaptable the resulting code actually is.
A simple example for multiple alternative implementations of the same functionality in BPMN is repetitive execution of a task through a Loop marker for the task. Any of the following language constructs can be used to define repetitive execution of a task and hence can be used as an alternative to a Loop marker: 1. A combination of an Exclusive Gateway and Sequence Flows 2. Enclosing the task in a Loop Sub-Process 3. Enclosing the task in an Ad-Hoc Sub-Process 4. Enclosing the task in an Event Sub-Process It is likely that a BPMN engine will only support a subset of these options. For instance the Activiti engine1, currently does not support normal Loop markers (standardLoopCharacteristics). It does support the combination of Exclusive Gateways and Sequence Flows, as well as Event Sub-Processes, but no Loop or Ad-Hoc Sub-Processes. Given a process with a task that uses a Loop marker needs to be ported to the Activiti engine, the code needs be adapted to one of the versions Activiti supports. To summarize the above discussion, the adaptability score of a task with a Loop marker is equal to four. 3.1
We define the adaptability score for atomic process elements as:
AS(e) = | {alte1, . . . , alten} | (1) The adaptability score AS of element e is equivalent to the cardinality of the set of alternatives {alte1, . . . , alten} for the element that are available in the language. For the approach to work, such a score must be provided for every relevant atomic element of the BPMN specification. At the moment, we are fixing the appropriate score for every element, being activities (Tasks, Sub-Processes, Call Activities), Data Items, Events and Gateways. 1 For more information, see the Activiti user guide: http://www.activiti.org/ userguide/index.html.
The decision on what counts as a relevant atomic element is a design choice of
the approach. It is reasonable to exclude a certain set of language elements from
the computation. On the one hand, these are elements that are very basic and
also very common and, as a consequence, are supported by every implementation
of the standard. The inclusion of these elements in the adaptability computation
would only have a distorting efect. On the other hand, certain elements are
simply irrelevant to process execution and their implementation in a runtime
is unimportant. Lanes fall into the latter category, as they have no real impact
on the executability of a process, but are mainly relevant to visualization. The
ifrst category contains Sequence Flows and Exclusive Gateways. Sequence Flows
are very basic language elements and it is hard to build processes in BPMN
without using them. Ad-Hoc Processes in combination with Data Inputs and Data
Outputs can, to a limited degree, replace Sequence Flows, but fail for instance
when parallelism is involved. As they are typically very frequent, but cannot
really be adapted anyway, we exclude them from the computation. Exclusive
Gateways can be adapted to most other forms of gateways, such as an Inclusive
Gateway where only one expression will evaluate to true, a Complex Gateway,
or an Event-Based Exclusive Gateway. Nevertheless, they are the most basic
mechanism for controlling the program flow and normally available in every
implementation of the specification. Including them in the computation would
introduce noise into the metric value. To decide if an element belongs to the
basic subset, it could be helpful to look at its typical frequency in process models.
[
Finally, it is important to note that this approach rewards the availability of multiple equivalent constructs in a language. From a usability point of view, this is often considered as a drawback of the language, because its users can be confused on what syntax is best to be used. However, from the viewpoint of adaptability, it is positive, since multiple alternatives increase the likelihood of having at least one of them available in a given runtime. 3.2
Based on atomic adaptability scores, we now need a mechanism for aggregating
these scores to a global adaptability degree for the complete process. This is
necessary to allow for the comparison of diferent processes in terms of their
adaptability. Moreover, the aggregated degree should be normalized with respect
to the size of the process, to enable the comparison of processes of diferent size.
A straightforward way of aggregating adaptability scores is the following:
1. Normalize the score for every element.
2. Similar to [
This leads to the question of how to normalize scores on an atomic level. We propose to divide the score by a reference value. This reference value can be identified by the maximum adaptability score achieved by any of the elements in the language. That way, the most adaptable language element will have a normalized score of one, whereas other elements will have a value between zero and one. This results in the following equation:
AD(p) = AD(e1, . . . , en) = (AS(e1)/R), . . . , (AS(en)/R) (2) The adaptability degree AD of process p, which consists of the elements e1, . . . , en, is equal to the arithmetic mean of the adaptability scores AS for every element e divided by the reference value R.
For the choice of the reference value, which we currently determined to be six, diferent schemes are possible. The scheme we use here has several advantages with respect to the computation: 1. The resulting metric value always ranges in the interval of [0, . . . , 1] and thus resembles a percentage value. This scale is easy to understand and interpret, which is critical for the adoption of the metric. 2. The reference value is identical for processes of the same language. Using a reference value that is specific to a concrete process might output a more meaningful adaptability degree for that process, but it would no longer be directly comparable with diferent processes. That way, the metric would lose one of its primary purposes. 4
In the following, we use an example process2, depicted in Figure 1, to demonstrate the computation of the adaptability degree. The process consists of a Lane, two User Tasks and two Service Tasks, one of which has an Interrupting Error Boundary Event, two Exclusive Gateways, several Sequence Flows, as well as two End Events and a Start Event. Table 1 shows the adaptability scores we 2 The process is executable on Camunda BPM 7.0.0. The code and instructions on how to execute it are available at https://github.com/uniba-dsg/zeus2014. determined for the respective elements of the travel grant application process. As discussed in section 3.1, Lanes, Sequence Flows, and Exclusive Gateways are not considered in the computation. The BPMN specification lists seven diferent triggers for process start, and hence seven diferent types of Start Events [16, pp. 240/241] do exist. All except for the Timer Event are a suitable alternative for the None Start Event used in the process, resulting in an adaptability score of five. For End Events, nine diferent types do exist [16, pp. 247–249], five of which, including the None End Event, can be used to express orderly termination, resulting in four alternatives for it. Furthermore, there are seven diferent types of Tasks in BPMN [16, pp. 158–165]. Again, the idea is that Tasks which are not supported by an engine can be adapted to a diferent type of Task, for instance a Service Task could be adapted to a Script Task. All tasks actively perform an action, except for the Receive Task which is waiting for an action, so there are five alternatives for the tasks used in the process. If the Error Boundary Event is not supported, it might be possible to use a diferent interrupting boundary event which also changes the normal flow into an exception flow. Here, a Message, Escalation, Conditional, Signal, Multiple, or Multiple Parallel Interrupting Boundary Event could achieve the same result [16, pp. 254–257]. The reference value R is six, which results in the adaptability degree values depicted in Table 1. The resulting adaptability degree for the use case is computed in the following: AD(p) = ((1 ∗ AD(StartEvent)) + (4 ∗ AD(T ask)) + (2 ∗ AD(EndEvent)) + (1 ∗ AD(ErrorEvent)))/8 = ((1 ∗ 0.83) + (4 ∗ 0.83) + (2 ∗ 0.67) + (1 ∗ 1))/8 = 0.81. 5
In this paper, we proposed a mechanism for computing a degree of structural adaptability for BPMN processes that aims to quantify how easily a process can be adapted to a diferent form with the same runtime behavior. Furthermore, we demonstrated its computation in a use case. Such a degree can be helpful for quality assessment during development or decision support during migration.
Several aspects of the computation are still open: First, adaptability scores need to be fixed for every relevant element and they should be confirmed in peer review. Moreover, a validation of the proposed adaptability metrics is needed. On the one hand, validation should be considered from a theoretical point of view, for instance by clarifying the measurement-theoretic properties of the metrics or by conrfiming construct validity. On the other hand, the practical applicability of the metrics should be confirmed, for instance in an experiment with realworld processes. This could be used to evaluate if the adaptability degree can meaningfully discriminate between processes of diferent quality.