Declarative approaches to process modeling promise a high degree of exibility. However, current declarative state-of-the-art modeling notations are, while sound on a technical level, hard to understand. To cater for this problem, in particular to improve the understandability of declarative process models as well as the communication between domain experts and model builders, Test Driven Modeling (TDM) has been proposed. In this tool paper we introduce Test Driven Modeling Suite (TDMS) which provides operational support for TDM. We show how TDMS realizes the concepts of TDM and how Cheetah Experimental Platform is used to make TDMS amenable for e ective empirical research. Finally, we provide a brief example to illustrate how the adoption of TDMS brings out the intended positive e ects of TDM for the creation of declarative process models.
In today's dynamic business environment the economic success of an enterprise
depends on its ability to react to various changes like shifts in customer's
attitudes or the introduction of new regulations and exceptional circumstances [
Especially declarative processes have recently attracted the interest of
researchers, as they promise a high degree of exibility [
The remainder of this tool paper is structured as follows: Section 2 brie y introduces TDM. Then, Section 3 discusses the software architecture and features of TDMS, while Section 4 illustrates the usage of TDMS by an example. Finally, Section 5 concludes with a summary and an outlook. 2
In this section we brie y sketch what constitutes a declarative process model
and how TDM is intended to support the creation of declarative process
models. Please note that we focus on TDMS and necessary backgrounds only. A
discussion of, e.g., related approaches, is out of scope and can be found in [
A declarative process model is characterized by a set of activities and a set of constraints. In contrast to imperative process modeling languages like, e.g., BPMN, the control- ow is not explicitly, but implicitly de ned through constraints which exclude forbidden behavior. For instance, a constraint in process model S might specify that activity A is not allowed to be executed more than once. Then, every process instance that contains not more than one execution of A is considered to be a valid instance of S |independent of when A has been executed. An exemplary declarative process model can be found in Fig. 4 (2).
While constraints focus on forbidden behavior, TDM introduces the concept of testcases to focus on desired behavior of the process model. In particular, a testcase consists of an execution trace (i.e., a sequence of activities that constitute a process instance) as well as a set of assertions (i.e., conditions that must hold at a certain state of the process instance) (cf. Fig. 1). The execution trace of a testcase thereby speci es behavior that must be supported by the process model, whereas assertions additionally allow to test for unwanted behavior, i.e., behavior that must be prohibited by the process model. A typical example for an assertion would be to check whether activity N is executable at time M.
Consider, for illustration, the testcase depicted in Fig. 1. It contains the execution trace <A,B> (1) as well as an execution assertion that speci es that A cannot be executed between the completion of A and the start of B (2) and termination assertions that specify that the process instance cannot be terminated before the completion of A (3), however, it must be possible to terminate after the completion of A (4). The times in Fig. 1 do not necessarily constitute real times, but rather provide a timeline to test for control- ow behavior, i.e., de ne whether activities can be executed subsequently or in parallel. Furthermore testcases are validated automatically, i.e., no user interaction is required to check whether the speci ed behavior is supported by the process model.
So far we have introduced the concept of testcases, in the following we will
sketch how their adoption intends to improve the communication between
do1 Freely available from: http://www.zugal.info/tdms
main expert (DE) and model builder (MB). Testcases provide information in a
form that is not only understandable to the MB, but also understandable to the
DE, who usually does not have the knowledge to read formal process models [
Domain (1) (4)
Test 1 Test 2 Test 3 (5) Domain Expert (DE) (2)
Model Builder (MB)
Besides improving the communication between DE and MB, testcases aim
at improving the MB's understanding of the process model by providing an
additional point of view. As pointed out in [
Testcase Editor. As mentioned before, testcases are a central concept of TDM,
have precise semantics for the speci cation of behavior and still should be
understandable to domain experts. To this end, TDMS provides a calendar-like
testcase editor as shown in Fig. 4 (1).
Declarative Process Model Editor. The declarative process model editor,
as shown in Fig. 4 (2), provides a graphical editor for designing models in
DecSerFlow [
Testcase Creation and Validation. In order to create new testcases or to delete existing ones, Fig. 4 (3) provides an outline of all testcases. Whenever a testcases is created, edited or deleted, or, on the other hand, the process model is changed, TDMS immediately validates all testcases and provides a detailed problem message in Fig. 4 (4) if a testcase failed. It is important to stress that the validation procedure is performed automatically, i.e, no user interaction is required to validate the testcases.
In order to ensure that all components work properly, TDMS has been
developed using Test Driven Development, where applicable. In addition, researchers
with di erent backgrounds, e.g., economics and computer sciences, have been
included to develop an intuitive user interface. In a recent application of TDMS
in a controlled experiment [
Integration of Test Driven Modeling Suite
TDM, as introduced in Section 2, focuses on the modeling of declarative
processes, TDMS provides the necessary operational support, i.e., tool support. To
this end, TDMS makes use of Cheetah Experimental Platform's (CEP) [
Cheetah Experimental Platform as Basis. One of the design goals of TDMS was to make it amenable for empirical research, i.e., it should be easy to employ in experiments; data should be easy to collect and analyze. For this purpose, TDMS was implemented as an experimental work ow activity of CEP, allowing
Tests
+ Model
Test Driven Modeling
Suite Cheetah Experimental
Platform
Export and Deploy
Declare Framework (Worfklow Engine)
Execute Process
Instance
Declare Worklist (Worfklow Client) Process Modeling
Process Execution
TDMS to be integrated in any experimental work ow (i.e., a sequence of
activities performed during an experiment, cf. [
A preliminary empirical evaluation shows the positive in uence of TDM on
cognitive load and perceived quality during model maintenance [
Starting from an empty process model, the DE lines out general properties of the process: \When supervising a master thesis, at rst the topic needs to be discussed with the student. While the student works on his thesis, feedback may be provided at any time. Finally, the thesis needs to be graded.". Thus, possibly with help of the MB, the DE inserts activities D, P and G in the testcase's execution trace (cf. Fig. 6); TDMS automatically creates respective activities in the process model. Now, the DE and MB run the testcase and the test engine reports that the testcase passes.
Subsequently, the DE and MB engage in a dialogue of questioning and
answering [
Again, the MB challenges the model and asks: \Can the supervisor grade a thesis multiple times?". The DE replies: \No, of course not, each thesis must be graded exactly once." and together they specify a third testcase that ensures that G must be executed exactly once. By automatically validating this testcase, it becomes apparent that the current model allows G to be executed several times. Thus, the MB introduces a cardinality constraint on G (cf. Fig. 8).
While this example is kept small for the sake of brevity, it illustrates the
bene ts of using TDMS for modeling. First, the DE, who is usually not trained
in reading or creating formal process models [
TDMS, as described in this tool paper, provides operational support for the TDM methodology. More speci cally, TDMS allows for a tight integration of declarative process models and testcases, thereby aiming at improving the communication between domain expert and model builder as well as resolving hidden dependencies. In addition, we sketched how we employ CEP as basis to make TDMS amenable for empirical research and showed how the Declare system is employed for the execution of declarative processes modeled in TDMS. Finally, we illustrated the intended usage of TDMS, in particular the iterative development of testcases and process model, with the help of a small example.
Future work focuses on further empirical validation: TDMS will be used in case studies to investigate whether the proposed methods are feasible in practice. In addition, TDMS will be employed in further controlled experiments to complement the case studies' results with quantitative data.