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.

In the same workshop as mentioned before there was the presentation of (McNeile & Roubtsova, 2009).

UML State Machines were discussed for the purpose of behavior modeling. It was rightly pointed out, that they have some severe weaknesses.

One weakness is that events trigger transitions, but if there is no transition with the event, the event is not inhibited. It just happens without any result.

A second weakness is the possibility of a state explosion in real scenarios. This can – in my opinion however – be addressed with state regions (see UML).

Another weakness is the lack of composition capability – i.e. the possibility to add a model part that does not modify another model part but has an effect.

I agree to these observations.

Furthermore It was distinguished between states that are actively set (like active or closed) and those which are calculated and whose transition are done by change of input values (like overdrawn or in credit with a bank account). While I see these differences as well, in my opinion they are not so strict. There are also cases where there is a state, that is changed actively (not completed) but the result state is calculated (partially completed, fully completed). For this case it was not taken account for.

As a solution it was proposed that protocol machines are constructed, that are able to Allow an event or Refuse or Ignore. While I can understand for what Allow and Refuse is needed (i.e. Buttons on a Screen) I see no direct use case for Ignore.

Also it was proposed a composition mechanism that provides for adding behavior to a model without modifying it. While I think this is pointing into the right direction and this should be achieved, I have doubts if the way that was presented was the solution. There were some ambiguities in the proposal – especially with regards to the question what the absence of a transition within a certain region really means (Refusal?)

All in all for me it was one of the most interesting presentations going into a promising direction.

References

McNeile, A., & Roubtsova, E. (2009). Composition Semantics for Executable and Evolvable Behavioral Modeling in MDA. First European Workshop on Behaviour Modelling in Model Driven Architecture (BM-MDA) (S. 41-56). Amsterdam, The Netherlands: Centre for Telematics and Information Technology Workshop Proceedings.