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.

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.

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.

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.

It was rightly stated in the presentation, that UML sequence diagrams are insufficient to model behavior and that a new kind of modeling method is needed. Also the lack of a modeling method for operations of a class was obvious – nobody knows in which sequence they have to be called – if not prose does describe it. Therefore a new modeling method was proposed, that displays classes as swim lanes containing the operation definitions of the class as nested activities containing actions. In this “action language” sequences can be expressed by arrows between actions of one swim lane and other swim lanes.

In my opinion this idea points into the right direction. Actions / operations must be set into relation with regards to their mutual constraints and a simple graphical notation for this is needed.

I did not understand however why it is necessary to distinguish between operations and actions, because in my opinion the actions in this method reveals details of the inner structure of the operations, which is in my opinion not relevant. Furthermore in my opinion the flow based modeling (arrows) leads into a model explosion, if big examples (business use cases) are modeled.

In my opinion the suggestion of (Engels, 2009) was more appropriate to the task in this aspect.

References

Engels, G. (2009). Keynote: Automatic generation of behavioral code – too ambitious or even unwanted? In M. Aksit, E. Kindler, A. McNeile, & E. Roubtsova (Hrsg.), First European Workshop on Behaviour Modelling in Model Driven Architecture (BM-MDA). Amsterdam, The Netherlands: Centre for Telematics and Information Technology Workshop Proceedings.

Kalnis, A., Celms, E., Kalnina, E., & Sostaks, A. (2009). Behaviour Modelling Notation for Information Systems Design. In M. Aksit, E. Kindler, A. McNeile, & E. Roubtsova (Ed.), First European Workshop on Behaviour Modelling in Model Driven Architecture (BM-MDA) (pp. 29-40). Amsterdam, The Netherlands: Centre for Telematics and Information Technology Workshop Proceedings.

The second Presentation was about Weaving Executeability into UML Class Diagrams from Elvinia Riccobene of the Universtià degli Studi di Milano, Italy.

The introductory criticue about describing object contracts with a constraint language only (like OCL – or pre- and postconditions of methods / operations as mentioned before) was, that it was not possible to change the state of an object or a system by a postcondition. It was said, that it was better to describe this in an Abstract State Machine (ASM).

An ASM does not only describe preconditions for the execution of a function, but also the transition of the state – i.e. it is directly executable – platform independently (and thereby simulateable).

My personal opinion about this is, that in modelling the behavior of a business object a certain kind of nondeterminism is needed. For example if there would be a function “check credit limit” for a customer – this can be quite complex in terms of business functionality. So in an ASM you have the choice to model all the complexity of this decision, but then it is not a model any more, but it is the system implementation itself. So there is no other way than to do an abstraction and only model that ther outcome can be (granted, denied) or (granted, denied, manual decision needed) or whatever decision result needs to be modeled. If that is true, even in the ASM some nondeterminism is needed, which leads to limited executeability (i.e. a user must decide or chance or some simplified algorithm or the formalism is used for state space search).

But then the difference to modelling postconditions is not so big, because, the postcondition only states as well, that the result of the operation can be (granted, denied) or (granted, denied, manual decision needed). If the result is unary, then also the postcondition modelling can be used for execution.

In the succeeding part of the presentation it was explained in detail how ASM and UML class diagrams (as one example of any metamodel) can be weaved together to form new classes which are able to model the behavior in this language. But in my opinion first a common understanding on the more fundamental questions should be tried to reached, which I mentioned, before too much specific should deviate us from the discussion.

Why is it, that the structural aspects of software enjoys universality of modeling (UML) while the behavioral aspect does not (yet) and what can and should be done about it?

The same is – obviously – true for Web Service Descriptions. You will get a WSDL description which describes the syntactical aspect of the services, but the behavioral aspect is left undescribed.

The invited speaker was Prof. Gregor Engels, University of Paderborn about “Automatic generation of behavioral code – too ambitious or even unwanted?”

I am – as always – only giving my personal opinion here. I agree to the goal of behaviorable modelling. It was proposed, that preconditions and postconditions of operations should be used to do this. The advantage of the approach has been proposed to be able to become more specific step by step or level by level.

I mainly agree to the statement and I think it is pointing in the right direction. My personal opinion is, that preconditions alone are not enough, as long as they can contain every expression, because then they can not be linked with each other. Postconditions are in my opinion important, but they do not describe, how the state is changed by an operation. This is a difference to the ASM (Abstract State Machine) Approach, that was presented later and that I will discuss in another post.

Furthermore I think that code generation is the wrong way. The reason is, that code is too static to be extended later. A runtime model interpreter helps to avoid many problems, including extensibility and the deviations of models from the implemented reality. Furthermore in my personal opinion graph transformations should be avoided.

So this is my personal opinion about the first talk, which I think pointed into the right direction in general.