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.

Again about the First European Workshop on Behavior Modelling in Model Driven Architecture [BM-MDA].

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.