The adoption of formal models by process specialists has faced two challenges: First, it requires process specialists to get training in formal modeling. Second, the resulting speci cations bear little resemblance wrt. the original descriptions. We introduce a tool that supports translations between natural language descriptions and declarative process models. The resulting models are given in a graphical formalism, DCR Graphs. Traceability is at the core of the tool: Later changes in the process model due to, e.g., ambiguity resolution are traced back into the text. This allows users to either correct and complete their descriptions, or to derive models more re ned than the text. In this paper, we describe the mechanics of the tool and provide examples of its use. Finally, we report on experiences using the tool in a Danish Municipal government.
This paper describes an implementation of tool support for a method for extracting declarative process models from textual process descriptions. The tool aims at reducing the gap between textual descriptions of processes and their interpretations in a declarative process model. The tool is particularly aimed at supporting users who are not trained in formal methods.
Both the tool and the method exploit the regularity of contemporary
constraintbased process notations with trace semantics such as DECLARE [
The purpose of the tool is to allow domain experts with some familiarity with the modelling notation, to easily construct and maintain declarative models. The tool is currently being used at both industrial and academic environments, and user feedback indicates that both the development method and the tool are e ective in establishing and maintaining a correspondences between a textual process descriptions and a formal constraint-based process models. 2
We illustrate the tool via an example process description from the BPM Academic Initiative4, presented in Fig. 1:
The process includes two major roles, agents (supporting customers outdoor) and clerks
(work indoors). When the insurance company receives a new claim, the clerk calls the
agent to actually check the claim, and creates a new case. As both tasks are executed
by di erent roles (that are mapped to di erent people), the activities are scheduled in
parallel. After the agent has con rmed the claim to the clerk, he supports the customer
with additional assistance (e.g. getting a new id-card from the public authority). After
the clerk has received the con rmation from the agent, she issues a money order for the
claim. If the agent has completed his additional support and the clerk has issued the
money order, the claim is closed.
DCR Graphs are the formal foundations of the process engine developed by
DCR Solutions. For sake of space, we do not provide formal de nitions, referring
the reader to [
CreateProcessModels/ex2_insurance_process.pdf
Advanced use. Constraints may be explicit (e.g. \after", \and", \if-then"), or implicit (i.e.: the rst highlighted comma). Other aspects may hinder the mapping between texts and DCR graphs: i. A sentence might denote the re nement of an activity. i.e.: \The evaluation process might contain evaluations regarding chronic and lifelong conditions of the patient". Here, activity (evaluation) needs to be re ned into several (separate assessments for lifelong and for chronic diseases). ii. A sentence might denote internal activities (performed by a single role) as well as communication activities (i.e.: lines 2{3 in Fig. 1). iii. Elements identi ed in textual paragraphs might be referenced later. iv. Relations might include one-to-one, many-to-one and one-to-many cardinality between activities.
The tool supports these scenarios. First, multiple markings of the same text will denote groups (abstractions) and re nements (nested activities). Second, multiple highlights denote communication activities, one role per marked text. Third, the tool allows the creation of references to existing elements. Finally, the creation of relations within the text allows users to include more than one relation per marked text, with possibly di erent actors and types involved. 2.1
: : : \and back": Support for Model Changes In practice, both models and texts may evolve over time. These changes do not break correspondences with the model. The lter view (c.f.: Fig. 3) shows the mapping between components and highlighted texts. Elements in the model that do not have a mapping to the text are shown in red. In the example, those elements are the new activities that re ne additional support. This distinction helps users identify deviations from the model, and to correct them either by linking the model components to the text, or by updating the text description. 3
Despite a raising interest in the alignment of process models and textual
descriptions [
The highlighter tool has been validated in industrial and academic environments. First, the tool has been introduced to a small number of end-users from the Syddjurs municipality in Denmark, who have used it to build models corresponding to the municipal governments internal guidelines on processes for implementing Section 42 of the Danish Consolidation Act on Social Services, which describe rights to compensation for loss of earnings awarded to parents of children with long-term illness or disabilities. Users had a background in law and social work, and had previously received training in process modelling using DCR graphs. Users' interaction with the tool resulted in their independent process models5 End-users reported that the highlighter was e ective and easy to use for the intended purpose6. Finally, the highlighter tool is currently being used in B.Sc. and M.Sc. courses on business process modelling at the ITU. 3.1
Availability, Documentation and Screencast
The tool has been implemented by DCR Solutions A/S as part of their set
of tools for declarative process modelling and execution, and is part of their
commercial on-line o ering [
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. 5 http://www.dcrgraphs.net/Tool?id=7119 6 However, they did report that some aspects of the guidelines, e.g., the criteria an assessment of a child's special needs must meet to be lawful, were not straightforward to map to the BPM concepts of \Activity". This concern is orthogonal to the tool itself: such di culty would manifest also in a pen-and-paper model. 7 http://wiki.dcrgraphs.net