Categories
#Multi-.instance subprocess #Spawn rule

Case Management Process

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.

Fig 1. Root Case Management Process

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.

Fig. 2. Meeting Sub-process

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.

Fig. 3. Document Handling Sub-process

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.

Fig. 4. Case Management Process

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.
6Morten Marquard, Muhammad Shahzad, and Tijs SlaatsCase ManagerUpload MinutesCase ManagerInvite ParticipantsHold Meeting!Change DateCancel Meeting%▼%▼%▼▼Fig. 2.Meeting Sub-processCancel Meetingexcludes this activity since it does not make sense to upload min-utes for a meeting that was cancelled. Finally the goal of the meeting sub-process isthat we either eventually hold the meeting or cancel it. This is modelled by makingHold Meetingapending response, drawn by adding a blue exclamation mark to theactivity box. A pending response denotes that an activity should either happen or beremoved from the process before we can finish or close the process; in our exampleeitherHold Meetingneeds to be done orCancel Meetingneeds to exclude it.CheckinCase ManagerCheckoutCase ManagerDownloadCase Manager%▼%▼+▼+▼▼Fig. 3.Document Handling Sub-processFigure 3 shows the pro-cess for managing adocument in the ECM.To edit the documenta user needs to checkit out, the file is thenlocked until it is checkedin again. This is mod-elled using first the ex-clusion relation to exclude each activity when they happen (meaning they can only bedone once at a time) and the two newinclude relations(→+) between the two events.The include relation is used to add removed activities back into the process, so in thiscase, whenCheckouthappens, it removes itself and addCheckinto the process andvice versa. Finally when a file is checked out we always want it to be checked in againbefore the process can finish. We model this through theresponse relation(•→) whichis a dynamic version of the pending response that we introduced earlier. It denotes thatafterCheckoutis executed we requireCheckinto be executed (or excluded) at leastonce before we can close the process. It is always possible to download the documentthrough the unconstrainedDownloadactivity.Finally we would like to tie all these process together into a single process describ-ing the handling of a case in the ECM system. For this we use an extension calledhier-archical 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 mainnew concept are the two new sub-processesMeetingandDocument Handling,Page 7Web-based Modelling and Collaborative Simulation of Declarative Processes7Document HandlingMeetingCase||||||Case ManagerArchive CaseCreate MeetingPost To ActivityStreamCreate DocumentCase ManagerDownloadCase ManagerCase ManagerUpload MinutesCase ManagerCancel MeetingCheckoutInvite ParticipantsHold Meeting!Change Date%▼%▼+▼▼▼▼▼▼%▼%▼▼%▼▼%▼▼%▼Checkin▼%+▼Fig. 4.Case Management Processdrawn as a box without a bar on top of it. These are essentially DCR Graphs inside theroot process that need to be initialized through the newspawn relation(→∗), creatinga new copy of the sub-process for each time it is spawned. In the example the activ-ityCreate Meetingspawns a new copy ofMeetingeach time it is executed andCreate DocumentandCreate Minutescreate a newDocument Handlingprocess each time they are executed.When one has a relation between an event of a sub-process and an event of its par-ent, the relation will apply to each instance of the event. For example a case can not bearchived while there are pending meetings; this is modelled by adding a condition fromHold MeetingtoArchive Case, meaning that while there is at least oneHoldMeeting-activity that has not yet been executed or excluded (by cancel meeting), itis impossible to executeArchive Case. In a similar manner it should not be pos-sible to archive the case while documents are checked out. We model this through themilestone relation(→), which blocks an event as long as some other event is pending.Because of the response relation fromCheckouttoCheckin, there will be a pendingresponse on the latter whenever the file is checked out. The milestone fromCheckintoArchive Caseensures that as long as there is at least one instance ofCheckinthatis pending, we can not archive the case. Finally, to archive the case,Archive Caseexcludes all instances of all events inDocument Handling, except forDownloadas it should still be possible to download files. All instances ofUpload Minutesarealso excluded, it is not necessary to exclude the other events inMeetingas this willalready have been done by holding or cancelling the meeting and unless one of thesehas been executed the case can not be archived.Page 88Morten Marquard, Muhammad Shahzad, and Tijs SlaatsThe example DCR Graphs from figures 1, 2 and 3 are all available on DCRGraphs.net,the Hi-DCR Graph in figure 4 was drawn using the development version of the portalwhich is not yet ready for release
(2) (PDF) Web-Based Modelling and Collaborative Simulation of Declarative Processes. Available from: https://www.researchgate.net/publication/283553986_Web-Based_Modelling_and_Collaborative_Simulation_of_Declarative_Processes [accessed Feb 20 2021].

LinkedIn
Share