This paper reports preliminary experiences using the Dynamic Condition Response (DCR) graphs declarative process notation to specify dynamic evaluation forms, and using an execution engine for that notation to subsequently \run" the form. The DCR notation was able to express all the patterns of behaviour necessary for a real case: a post-hoc evaluation form for a Danish arbitration court, \Voldgiftsn vnet for Anl g og Byggeri". However, some patterns were somewhat cumbersome to express.
This paper presents a preliminary experience report using the DCR Solutions
declarative process engine [
Related work Forms have strong similarities with declarative process notations
explored [
The premiere extant commercially/freely available services for constructing on-line evaluation forms are provided by SurveyMonkey and Google Forms. Both products emphasize ease-of-use, both for the form constructor and the end-user.
A SurveyMonkey form is speci ed as a list of elds. Each eld has a type (e.g., multiple choice, number, text, etc.), and the form designer may choose the ordering of elds. Both SurveyMonkey and Google Forms o er dynamically changing behaviour: 1. SurveyMonkey has so-called \skip page logic". This feature allows the form designer to set conditions to control the sequence ow of the form. In SurveyMonkey this is done by grouping questions in pages, and using conditional statements on questions to control whether or not the group of questions will be shown. 2. Randomized sequence features, which shu es the evaluation question 3. Dynamic labeling, which SurveyMonkey calls \Question & Answer Piping". This feature allows the form designer use text variables in question labels; the value of the variable is set to the answer of a given previously answered question. 2
In this section, we give a brief introduction to the Dynamic Condition Response
(DCR) graph process notation [
DCR is a declarative notation: processes are speci ed not by explicit sequence ows, but by the rules (relations) governing which sequence ows are admitted and which are not. Relations between activities indicate (1) constraints on whether an activity may be executed depending on the states of other activities, and (2) how executing one activity may a ect the state of another.
E.g., suppose (a) that an activity \Payout" is constrained to not happen unless \Approve payout" happened rst; and (b) that executing \Payout" changes the state of itself to be \no longer relevant" (to prevent a second payout).
DCR Solutions provides an on-line process portal4, for creating and
simulating DCR graphs [
In order to use DCR Graphs to build a form, we interpret activities as elds in the form, then we use relations to de ne the dynamic behaviour, e.g., to turn on and o one form eld/activity depending on the value of another eld.
Fig. 1 provides an example of a form in DCR graphs. There are six activities. The title of the activity corresponds to a eld text question in the form. An activity is executed with a green tick, and solid (resp. dashed) borders in an activity denote whether it is included (resp. excluded). A pending activity has a blue exclamation mark. Colored arrows denote relations in Sec. 2.
Notice how states of activities are drawn in Fig. 1, with three activities initially excluded. Two activities have pending states, indicating that they must be executed or excluded in the form to be deemed complete.
Each activity has a role and a label onto it. The green relation arrow from \Activity 2" includes a parent activity, including the nested activities \Activity 3 $(var)" and \Activity 4". Relations may have guards, as exhibited in the arrows between \Activity 4" and \Activity 5". They are used to constrain behaviour based on input.
Fig. 1 uses some modelling techniques for creating forms using DCR graphs: 1. Mandatory elds as pending activities: The pending state of \Activity 2" indicates that it must be executed before the work ow is complete. For forms, we interpret this as the eld \Activity 2" being mandatory: The form cannot be submitted unless \Activity 2" has received a value. 2. Guarded inclusions/exclusions: Dual, guarded include/exclude arrows from \Activity 4" to \Activity 5" represent a common pattern that includes or excludes \Activity 5" in the work ow/form depending on the value of \Activity 4". 3. Self-responses as content-control: A self-response on \Activity 6" is guarded by \Activity 6 = null". Since \Activity 6" is already a mandatory eld because of the blue exclamation mark, it ensures that if the eld is lled, and it is cleared at a later stage, it goes back to a pending/mandatory state.
The following new features in the DCR process portal were useful for the development of declarative forms: Sequence Editor and Form Preview The DCR process portal allows setting sequencing and grouping elds by drag-and-drop order controls. Fig. 2 shows on the left side the order of the sequence editor tool. When the form is shown in the preview (right side), it simulates what the recipient will see. Notice that only the included activities of Fig. 1 are shown.
Dynamic Labels. DCR process portal supports dynamic labels. In Fig. 1 the activity \Activity 3" has label \Activity 3 $(var)". At run-time this label will evaluate the contents of variable \var". This variable is bound to the input given at \Activity 2". The variable can be used for both roles and activity labels. 4
We now report on using the above mechanisms to specify a real-life for the VBA case. The initial requirements for VBA's evaluation form were simple: After an arbitration, VBA would send an evaluation form to the involved parties. The evaluation questions included how satis ed parties were with VBA as arbitrators, with the process followed, and with the outcome of the proceeding. The exact questions were outlined by VBA, and Exformatics produced from this speci cation a DCR graph to be interpreted as a web form.
The VBA speci cation actually called for evaluation of ve di erent types of arbitration proceedings, called (A), (G), (P), (Q), (C). An evaluation comprised both a set of general questions and a set of type-speci c questions. The (C) type was a special case, and had choices which would include other proceeding types. Some of the proceeding types shared speci c questions e.g. (P) and (G). The structure of the model is given in Fig. 35. Exformatics used roles to denote the arbitration proceeding type, and colors to ease the readability of the graphical presentation. The choice of which evaluation form to present was made using the guarded include/exclude pattern: A choice eld allowed the user to pick a type of proceedings, who will control the remaining content to be shown.
Exformatics and VBA lled the evaluation structure with the questions outlined, see Fig. 4. The model uses guards to impose the desired behaviour; e.g.: activity C will be only included if the case type (\Sagstype" in Danish) required is \C", and will be excluded otherwise.
Robotic support: Activities in Fig. 4 that correspond to the 'Exformatics' role are executed automatically. The data required for such activities is collected from the VBA database. The data was used to set variables for use as dynamic labels. 4.2
Adaptation VBA intended to continuously improve the form after its initial development, and they needed to collect statistics on the answers collected. It was therefore vital that (1) the DCR graph could be accessed and modi ed by VBA sta ; (2) that VBA sta could in fact understand and modify the graph; and (3) that VBA could have a data-extraction process that was stable under graph updates.
A key challenge was that VBA sta on the project did not have prior programming experience. However, the sta quickly acquired basic modelling competences, and contributed to model development. Nonetheless, understanding elements of the DCR Graph remained cumbersome for some sta . 5 The full graph is accessible at http://www.dcrgraphs.net/tool/main/Graph?id= da7c4489-578c-4b94-b17c-66ceb214692c 5
Unlike the previous use cases for DCR as declarative processes [
Mapping some standard behaviour of forms into DCR models proved to be challenging. That was the case of mandatory elds: One must add a pending activity combined with a self-response guarded by null, as discussed above. As seen in Fig. 4 most activities use this technique. In further work, we will consider adding process templates to the DCR portal to encapsulate this kind of behaviour, especially for readability.
In the forms case, include/exclude relations tend to come in pairs corresponding to the true and false branches of a condition. It would be helpful to express such choices in a single relation. The image below (Fig. 5) illustrates how the VBA evaluation graph might look had such a relation been available.
One of the main di erences between DCR and SurveyMonkey is the control of the sequence ow. Compared to DCR, SurveyMonkey o ers only a limited version of declarative conditional rules. SurveyMonkey only supports one condition for each question and SurveyMonkeys \skip" logic is bound to page breaks, in contrast to DCR which responds with change every time the user engage with a eld. The exibility of DCR was in fact instrumental to satisfy the requirements made by the customer. For instance, without the inclusion of DCR relations, it would have been challenging in SurveyMonkey to model VBAs evaluation, whereas this comes more naturally in DCR.
The second di erence was economy: by using DCR Graphs's declarative notation we were able to minimize the number of elds produced, enabling them depending on the type of proceeding. As a consequence (1) From a maintenance perspective, new changes to the forms have become agile; change is done to one activity, not to several. (2) From a data analysis perspective, the data from the di erent types were directly compatible on extraction, not having to merge data from the di erent proceeding types.
As mentioned in Sec. 4.2, one of the challenges remaining is to bridge the
adoption gap between declarative models and users with no experience in
declarative modelling, for instance, lawyers. In future iterations we would like to
explore how tools that maintain the correspondences between natural language
speci cations and DCR graphs (i.e.: [
The DCR graphs formalism successfully expressed the required dynamic behaviour of the VBA evaluation form. However, the modelling was not entirely straightforward, as the addition of Dynamic Labels and new a eld type was introduced, and expressing dynamic behaviour via DCR relations remain in some cases arti cial. In the future, DCR Solutions will study the inclusion process templates in order to facilitate abstraction and process reuse in the tool. Acknowledgments Work supported by the Innovation Fund Denmark project EcoKnow.org (7050-00034A). This project has received funding from the European Union's Horizon 2020 research and innovation programme under the Marie Sklodowska-Curie grant agreement BehAPI No.778233.