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.

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.

Continuing my thoughts about the MDA Conference I want to make some remarks about (Kalnis, Celms, Kalnina, & Sostaks, 2009).

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.