This week I am in Nijmegen with the purpose of integrating Declare and iTasks.
The idea is to allow components in either language to be used as sub-components in either. This makes it possible to mix paradigms (declarative and functional workflow modeling), introduces modules in Declare, and makes Declare (and iTasks) distributed.
We are still working on the details; we have not actually tested the two systems together and some parts are still missing from both systems. Still, the implementation in Declare is mature enough to give you an idea of what it looks like.
The functionality is similar to the functionality tying Declare to YAWL (you can read more about that here (PPT)), except this is more general and allows embedding multiple languages (in addition to the current implementations, I intend to make one for CPN Tools and ProM (execution only); I may make one for YAWL if I feel particularly masochistic). Also, this is not broken since YAWL 2.1.
Let’s dive in. First, we set up the framework:
We need to set up the Registry (which is a name service for modules; it needs to run at just one machine) and the registry client as well as the port used to accept incoming requests.
Next, we start up our models:
At the top is our repository of tasks offered externally and at the bottom are the tasks currently running in Declare. We have started a medical process. We can instantiate offered tasks directly using the “start” button, and we can directly load and start tasks without offering them externally.
Starting the worklist yields:
We have two sub-modules, “get_details” and “fracture”. We assume that get_details is handled elsewhere (it gathers information about the patient). After executing that, we can start initial tests:
The initial tests result in a diagnosis that defines which action to take.
Here, we treat a fracture. The definition of the “fracture” task is as follows:
Instead of a panel to tie the task to YAWL, we just tie it to an external task. We also describe the data flow to and from the module. Here, we give inputs to the module, namely the name of the patient and whether the patient has a medical insurance. Starting the task yields:
As we see in the model overview in the framework (2nd picture above), fracture is bound to a particular Declare model. Starting the module thus yields a new instance in the overview to the left. Here we also see one of the missing features in this version: even though the child model has not been completed, the constraint is marked as satisfied. It should of course only be marked so when the child has finished. We can switch to the fracture treatment module:
We then treat the patient:
The module is now at a satisfied state, so we can close the instance:
And complete the top level process as well.
As we can see, it is possible to use Declare models as sub-components of Declare models (making Modular Declare a reality and also allows us to execute Declare models distributed over several machines). Currently missing is better data transfer and fixing synchronization.
Next step is integration with iTasks, so we can use foreign components as well. The “get_details” module is intended to be made is iTasks as it is simple form-filling and therefore less suited to Declare.
Then comes adding CPN models to the family, so we can use CPN models as component and foreign components as sub-pages. I’ll add an interface to ProM, so it is possible to use ProM plug-ins as components. This is an extension of the ProM orchestration I’ve already demonstrated using CPN models, extended to Declare models and any language supporting our module concept. If YAWL is added to the family, we restore the old functionality in a way that does not require me to worry about YAWL every new release.
One thought on “Modular Declare”