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.

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.

If we look at executable processes, we will have process instances. A process instance obviously lives from the time, it is created, to the time it is terminated. During the lifetime of the process events occur, that need to be assigned to or correlated to a certain process instance, if not to many process instances.

The more process instances are created in the system, the more care needs to be taken that they all are managed correctly. Some unwanted effects may occur:

• An event is not correlated to the process instance it should have been correlated to (e.g. because of wrong correlation rules)
  • As a effect the event disappears without any effect.
  • As another effect the process instance, that the event should have been correlated to is stuck in an unwanted state.
    • A subsequent event, that is correlated again to this process instance, may find the process in the wrong state, causing more problems.
• An event is correlated to a process, that it should not have been correlated to.
  • As an effect the event is consumed and may not be correlated to the process instance, that it correctly should have been correlated to.
  • As another effect, the event will cause a problem in the wrong target process.
• Process instances may be started, even if there is already a process for the same thing, because of wrong correlation rules.
  • This may lead to starvation of other processes.
• There is no guarantee, that an event is correlated to any process.

So in the end there may be a system with many problematic process instances. Especially if not care is taken, that the correlation rules are absolutely consistent. This is difficult to achieve, especially if they can be maintained independently from each other.

So many problems? Well, at least problem recognition is the first step to the cure.