We've taken the liberty to copy chapter 2 of the article Web-Based Modelling and Collaborative Simulation of Declarative Processes to this example.
2. Hierarchical DCR Graphs
In this section we exemplify DCR Graphs and their semantics using an abstracted version of the main case management process of the Exformatics ECM system.
In figure 1 we start with the root process. The main building blocks of a DCR Graph are the events (or activities), drawn as a box with a bar on top. The box contains the name of the activity and the bar contains the roles that are able of executing it. Our process has a single role: the case manager. Activities can be grouped together by nesting them under a super-activity, in which case only the atomic activities are executable. Suchgrouping are a graphical shorthand for applying constraints or properties to multiple activities at once: in our process the super-activity Casehaving the roleCase Managermeans that the casemanager is able of executing every atomic activity nested under it.Constraints or busi-ness rules can be added to the model by adding one of five rules, drawn as directional arrows between activities. The root process contains a single rule, the exclusion rule (
) from Archive Case to Case. The exclusion rule is used to remove activities from the process, for example to close tasks that should no longer be executable, or to model an exclusive choice between two activities. Because the super-activity Case acts as a grouping the exclusion rule applies to all five of the underlying activities. This means that after archiving the case no further actions can be taken as it removes all activities from the process. Following the declarative paradigm unconstrained activities can be done at any time and any number of times, therefore the process supports many different runs: one could for example upload two documents, create a meeting, upload another document and finally archive the case. Note that while Archive Case closes the process by removing all activities, it is not required to happen and the previous example run would also have been valid if it had not ended by archiving the case.
Figure 2 shows the process for organizing a meeting. Similarly to the previous example we use the exclusion rule to remove activities from the process when they are no longer relevant: the activities Invite Participants, Change Date, HoldMeeting and Cancel Meeting are grouped together and removed by either holding or cancelling the meeting. Only after holding the meeting is it possible to upload the minutes of the meeting, this is modelled by the condition rule (
) which states that before Upload Minutes can be done we first need to have done Hold Meeting, Cancel Meeting excludes this activity since it does not make sense to upload minutes for a meeting that was cancelled. Finally the goal of the meeting sub-process is that we either eventually hold the meeting or cancel it. This is modelled by making Hold Meeting a pending response, drawn by adding a blue exclamation mark to the activity box. A pending response denotes that an activity should either happen or be removed from the process before we can finish or close the process; in our example either Hold Meeting needs to be done or Cancel Meeting needs to exclude it.
Figure 3 shows the process for managing a document in the ECM. To edit the documenta user needs to check it out, the file is then locked until it is checked in again. This is modelled using first the exclusion rule to exclude each activity when they happen (meaning they can only bedone once at a time) and the two new include rules (
) between the two events. The include rule is used to add removed activities back into the process, so in this case, when Checkout happens, it removes itself and add Checkinto the process and vice versa. Finally when a file is checked out we always want it to be checked in again before the process can finish. We model this through the response rule (
) whichis a dynamic version of the pending response that we introduced earlier. It denotes that after Checkout is executed we require Checkinto be executed (or excluded) at least once before we can close the process. It is always possible to download the document through the unconstrained Downloada ctivity. Finally we would like to tie all these process together into a single process describing the handling of a case in the ECM system. For this we use an extension called hierarchical DCR (Hi-DCR) Graphs, which adds a notion of spawnable multi-instance sub-processes.
Figure 4 shows the case management process as a Hi-DCR Graph. The main new concept are the two new sub-processes Meeting and Document Handling, drawn as a box without a bar on top of it. These are essentially DCR Graphs inside the root process that need to be initialized through the new spawn rule (
), creating a new copy of the sub-process for each time it is spawned. In the example the activity Create Meeting spawns a new copy of Meeting each time it is executed and Create Document and Create Minutes create a new Document Handling process each time they are executed. When one has a rule between an event of a sub-process and an event of its parent, the rule will apply to each instance of the event. For example a case can not be archived while there are pending meetings; this is modelled by adding a condition from Hold Meeting to Archive Case, meaning that while there is at least one HoldMeeting-activity that has not yet been executed or excluded (by cancel meeting), it is impossible to execute Archive Case. In a similar manner it should not be possible to archive the case while documents are checked out. We model this through the milestone rule (
), which blocks an event as long as some other event is pending. Because of the response rule from Checkout to Checkin, there will be a pending response on the latter whenever the file is checked out. The milestone from Checkin to Archive Case ensures that as long as there is at least one instance of Checkin that is pending, we can not archive the case. Finally, to archive the case, Archive Case excludes all instances of all events in Document Handling, except for Download as it should still be possible to download files. All instances of Upload Minutes are also excluded, it is not necessary to exclude the other events in Meetingas this will already have been done by holding or cancelling the meeting and unless one of these has been executed the case can not be archived.
