Just to provide a quick update on the progress of the thesis. The week coming to an end is the mid semester break so I have been working lightly on the design and implementation of the workflow builder as well as thinking conceptually on how the whole design will benefit the GCIMS architecture.
Workflow Builder
The workflow builder processing component, that is building an abstract of the workflow is approximatly 90% complete. Tests scripts can be used to build workflow elements of sequence, parallel split, simple merge and synchronisation and exclusive choice. Slight modifications (dependent on the finalisation of the WDL) and testing needs to be done on the workflow before I can finalise the processing part. I will finalise and present the results of each of the iterations once I have collated and analysed all my output.
Workflow GUI
I have begun researching and designing a simple workflow GUI. The GUI would be simple but allow users to essentially define their workflow and generate the XML output. I have decided not to do any "click and drag" and diagram based GUIs due to the time and scope of the project. Upon email consultation with Alan, he has advised me to focus my time on areas which will add value to the theoretical approach rather than focus on designing a flashy GUI with many 'bells and whistles'.
As a result, the simplified GUI would be designed to show the the core functionality of the workflow builder, that is, allowing users to create their workflow. The program and GUI is designed to be easy to read (i.e. code is well documented), understand (i.e. code is refactored and broken down) and be easily extendable assuming that future programmer has some experience in programming and OO design.
Meeting to Confirm Workflow Definition Language
On thursday the 27th of September, Hendy and I had a brief meeting to finalise the workflow definition language (WDL). We have made the following slight modifications:
- Merge and Synchronisation workflow elements are the same but only differ in the fact that synchronisation must wait for all workflows to merge before moving onwards.
- There is no longer a need to store the previous or next element. This is implicitly done by the structure of the XML
- Each workflow element (Seq, merge, sync, exc choice, par split) must have an attribute name and unique id. The name corresponds to the workflow name (e.g. Set Up Bed, "Administer Medication"). Each element must have a form and and a corresponding attribute "name". This form name corresponds to the name of the form from the form database. In my prototype workflow builder, i have made the assumption that the forms are valid and exists. But in a fully functional and operational program, the builder will interface directly with the forms database to ensure that the form exists.
- In merge and synchronisation work elements, there is no need to have form as an element. The reason is that the merge/synchornisation only acts as a medium in which workflow elements come together and feed into another workflow element.
Hendy and I have also discussed the overall architecture of the WfB and WfM in the WfMS. We have also discussed how we can each improve our own parts and how we can possibly demonstrate the idea. Currently, we are having issues integrating our parts into the GCIMS, especially the form builder. There are some font compatability issues in python going from a Mac to a PC environment which we have been trying to nail out. We may investigate the possibility of setting one of the uni computers to run all our applications if time permits.
No comments:
Post a Comment