[Back]

C. Werner:
"Automatic generation of terminal workflow applications";
Supervisor: S. Dustdar; Institut für Informationssysteme, AB Verteilte Systeme, 2011.

Business processes are the heart of many modern software applications. Modern architectures tend to use Domain Specific Languages (DSL) to implement these processes. These languages contain an abstraction from technical implementation details. Therefore using DSLs lead to better readable and maintainable code.
In our approach we develop a DSL usable for specifying workflows for one specific domain. Our example is able to specify the check-in process at a doctor. Other use cases may be possible as well.
The DSL contains activities on an abstract level. To execute the workflow it has to be transformed to executable workflow code. This code will be implemented using a well established framework. There are many advantages using this level of abstraction over implementing the workflow in the executable workflow language.
- The DSL is framework independent and therefore can be used in any framework
- The DSL contains less activities than the executable workflow. This makes the workflow better readable and maintainable.
- DSL contains only activities on one level of abstraction. This might not be the case in the executable workflow definition. Activities only needed for technical reasons complicate reading the workflow. Our abstract DSL only contain activities needed for specifying the workflow.
Technically needed activities have to be added at the transformation process.
- Validation and Verification on the abstract level is easier. The smaller number, and the lack of technically needed activities make the workflow easier to validate.
- Optimation may be done at two points in time. First on DSL level and second at transformation time.
- The heavy use of frameworks offers flexibility and eases development.
This work introduces a DSL, able to specify such workflows. Afterwards a prototypical implementation of the transformation process for the Microsoft WF .NET framework is done.
Our approach is useful for applications where the workflow changes but the tasks stay allmost the same. Extention of the DSL is possible but has to be done by experts. Therefore extention may be expensive. We may generate applications which only differ by their workflow. Any other part (other userinterface, etc) has to be implemented or customized by hand.