Within the 4th European workshop on ” From code centric to model centric software engineering: Practices, Implications and ROI” we had an interesting discussion. After a talk about the question, if or if not MDA is practically usable in industrial projects with positive experiences (Fieber, Regnat, & Rumpe), the discussion was about Return on Investment of MDA. The most interesting part of the discussion for me was that there was a complaint about the fact, that until today it was not possible to model behavior effectively. If it were possible to model behavior – as structures can be modeled with UML – then this would be the big thing missing. However the problem was considered to be very difficult, if not too difficult.

That was when I made my statement, knowing about my yearlong successful experiences in behavior modeling. I said that probably the domain chosen was too broad. In my opinion we should concentrate on a specific domain – business processes – and model the behavior of it. That is because to model, it is necessary to know and describe the laws of nature of the domain – in this example business processes – in advance. Then as a result the modeling method will be very effective and successful. I said that for example in BPMN 2.0 major steps forward have been made recently.

We believed that following this approach it will be possible to achieve much better ROI of MDA than in the past. Practically this will mean that it will be possible to provide an application wireframe within days and an application within weeks instead of month or years. Through this productivity boost Custom Software will be cheap to build – therefore companies do not have the choice between standard software or high cost, but they can have what they specifically need at a low price. This is not out of reach.

Reference

Fieber, F., Regnat, N., & Rumpe, B. Assessing usability of model driven development in industrial projects. In T. Bailey, R. Vogel, & J. Mansell (Hrsg.), 4th European Workshop on “From code centric to model centric software engineering: Practices, Implications and ROI” (S. 1-9). University of Twente, Enschede: Centre for Telematics and Information Technology.

Why I am looking at these MDA papers?

It is inevitable in big organizations, that there are central processes that are supported by every part of the organization. But at the same time it is desirable, to support individual processes, that respect local specialties. In this case the local units must be given the possibility to plug into the global processes. This can only be done, if the behavior of the local and the central processes is known – and by this the interaction – the choreography between them – can be defined and described. Therefore it is important to have behavior modeling languages for processes of units and of the choreography. Furthermore sometimes it is necessary to allow a local unit to describe their own processes or aspects of their own processes in their own language – a DSL – and plug them into the central processes.

If this is achieved it is a controlled powerful local flexibility with the integration into centrally controlled processes.

All of these articles and also BPMN 2.0 can help to strife towards this goal.

(Soden & Eichler, 2009) discusses the need of extending the Eclipse Modeling Project under which EMF (based on MOF) is used to define Domain Specific Languages (DSL) and GMF to define Graphical Model Editors and Xtext to define Human Understandable Textual Notations (HUTN) for a defined DSL with a Model Execution Framework (MXF) that allows for the declarative specification of a model execution and simulation.

The idea is to extend an abstract syntax, that defines a Domain Specific Language (DSL) – for example a finite state machine language – with a model that describes runtime instances of the model (including state, counter, … ) plus a declarative (in this case even graphical) model for the behavior of the model simulation.

What I like in the idea is the thrive to make the DSL architect more productive in his work by relieving his duty to implement a model interpreter or model to code translator, if he invents a new DSL. By this, he can write a new DSL (like for example BPMN 2.0) and would be able to simulate the behavior of the execution semantics without implementation work – just by declarative modeling. That is the promise of the approach.

One could discuss, if the chosen Language MAction is the best way to describe model execution semantics, but at least it has to be taken serious. For me this is an interesting DSL prototyping environment. If one looks at model execution at runtime, I do not think that the Eclipse Environment is the right architecture for this. But it is a start – as I said – for DSL Prototyping. Other points that should be discussed in the future in my opinion are:

• Runtime Optimization for the Model by adding shortcuts in the Runtime Model
• Modeling of big examples (like BPMN 2.0) with the new language
• Evaluation of different ways of describing the Model Execution Semantics

References

Soden, M., & Eichler, H. (2009). Towards a Model Execution Framework for Eclipse. First European Workshop on Behaviour Modelling in Model Driven Architecture (BM-MDA) (S. 57-71). Amsterdam, The Netherlands: Centre for Telematics and Information Technology Workshop Proceedings.