Domain specific languages for Business Process Management: a Case Study

1. Domain specific languages for Business Process Management: a Case Study Janis Barzdins, Karlis Cerans, Mikus Grasmanis, Audris Kalnins, Sergejs Kozlovics, Lelde Lace, Renars Liepins, Edgars Rencis, Arturs Sprogis, Andris Zarins _______________________________________________________________ DSM Workshop, OOPSLA, Orlando, Florida, USA, 25th October, 2009

2. Outline • BPM – what is it? • The environment for building tools • TDA – the Transformation-Driven Architecture • TDA framework • GrTP – Graphical Tool Building Platform • Case study – two BPM languages • requirements they had • place in the architecture • aspects of implementation • impact on the platform • Summary • things done • future work DSM Workshop, OOPSLA, Orlando, Florida, USA, 25th October, 2009

3. The world of business processes • Meanings of the BPM • Business Process Modeling • paints the overall view over processes • helps to understand processes deeper • allowssimulation • Business Process Management • performs execution of processes • allows processmonitoring • ... • In either case... • ... we need a language for modeling processes • ... we need a tool for supporting the language DSM Workshop, OOPSLA, Orlando, Florida, USA, 25th October, 2009

4. Currently in the market... • There exist several business process modeling languages • languages are universal • so they must fit our needs regardless of the case • languages can be extendable a bit • we can add our specific attributes • one of the most notable representatives – the BPMN language • There exist tools supporting the languages • BPMN tools allow to compile a BMPN to a BPEL code • BPEL code can then be executed by a BPEL engine DSM Workshop, OOPSLA, Orlando, Florida, USA, 25th October, 2009

5. However... • Languages tend to be too universal • only a small subset is needed in many cases • only some minor changes can be done • addition of attributes • quite difficult to learn for a non-programmer • Tools tend to be too enormous • very complicated • very hard to adapt for specific needs • usually very expensive • some exceptions exist here – BizAgi, Intalio, ... • however, they are based on the same complicated languages DSM Workshop, OOPSLA, Orlando, Florida, USA, 25th October, 2009

6. What to do? • We need a Domain Specific Language for the given business domain • easy to learn by domain experts – known concepts • the language can be made fitting our needs completely • We need a tool implementing the language • the tool can be made in our tool building platform • thus it overcomes the problems mentioned previously DSM Workshop, OOPSLA, Orlando, Florida, USA, 25th October, 2009

7. The Transformation-Driven Architecture J. Barzdins, S. Kozlovics, E. Rencis. The Transformation-Driven Architecture. Proceedings of DSM’08 Workshop of OOPSLA 2008, Nashville, USA, pp. 60–63, 2008. DSM Workshop, OOPSLA, Orlando, Florida, USA, 25th October, 2009

8. Graphical Tool Building Platform GrTP • Implements principles of the TDA • Contains five engines (others can be plugged in when needed) • graph diagram engine • dialog engine • database engine • word engine • multi-user engine • Provides model transformations for user-created events • Introduces the Tool Definition Metamodel (TDMM) allowing to build tools more easily DSM Workshop, OOPSLA, Orlando, Florida, USA, 25th October, 2009

9. The Tool Definition Metamodel • TDMM provides a way of storing the definition of tools (graphical editors) • each tool is described asan instance of TDMM • instances can be generated using a graphical configurator • universal transformation interprets TDMM together with its instances at runtime • TDMM contains, so called, Extension Mechanism • the set of precisely defined extension points • a transformation assigned to each point • universal transformation calls the assigned transformation at specific time (defined by the point) • possibility to alter the behavior of tools DSM Workshop, OOPSLA, Orlando, Florida, USA, 25th October, 2009

10. Fragment of TDMM DSM Workshop, OOPSLA, Orlando, Florida, USA, 25th October, 2009

11. Case study – two BPM languages • Project Assessment Diagrams (PAD) • editor for definingand vizualizing business processes regarding review and assessment of projects • language similar to UML activity diagrams • some new elements • lots of new attributes • requirements for tool • possibility to send data to some outer database • simple business process monitoring • State Social Insurance Agency (SSIA) • manager of various social insurance processes • language more similar to BPMN • requirements for tool • online collaboration with a relational database during process development • generation of reports in a form of Microsoft Word • checking of various semantic constraints • simple solution to DSL (and platform) evolution problem DSM Workshop, OOPSLA, Orlando, Florida, USA, 25th October, 2009

12. Implementation of PAD and SSIA • First step – development of graphical editors • generation of TDMM instances using the graphical configurator • addition of some dynamic facilities using the Extension Mechanism • dynamically generating combo box items • dynamically generating pop-ups • adding specific toolbar elements • ... • Second step – extension of the platform • development of new engines • database engine • word engine • multi-user engine • evolution of the Tool Definition Metamodel DSM Workshop, OOPSLA, Orlando, Florida, USA, 25th October, 2009

17. Summary • Results • TwoDSLsfor BPM havebeendeveloped • TheTransformation-DrivenArchitecturehasbeentested • testpassed • ThetoolbuildingplatformGrTPhasbeenexamined • threenewengineshavebeencreated • thetooldefinitionmetamodelhasbeenimproved • Futurework • to develop a platformforbuildingdomainspecific BPM suites • severalfacilities (process editor, process engine, simulator, etc.) includedinonesuite DSM Workshop, OOPSLA, Orlando, Florida, USA, 25th October, 2009

18. Questions? DSM Workshop, OOPSLA, Orlando, Florida, USA, 25th October, 2009