Frank Michael Kraft's Blog

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.

It could be asked this question: Communicating processes have an analogy to communicating programs. In the eighties there have been quite some publications about this, including Milners Pi calculus. So how is the relation of BPMN choreography and this?

My answer would be, that the Pi Calculus is a Low Level desription calculus for processes that communicate with each other, messages and message channels. This serves the simulation and analysis. The choreography model and the collaboration model are more like a notation with metamodel covering the processes and the messages, but not the message channels. It is more for modeling than for analysis, although the model can be input to the analysis and the simulation.
Also every BPMN choreography model or collaboration model can be mapped to a Pi Calculus description, but not vice versa. Pi calculus is more general and has no notation. BPMN is guiding the modeling process and therefore easier to understand.

When one want to use the BPMN choreography model or collaboration model as input to a pi calculus conversion or a simulation and analysis, the quality of service contract needs to be specified before.

http://www.bpmnforum.net/blog/bpmn/bpmn-in-research/quality-of-service-contracts/

(1) speaks also about Quality of Service Contracts. In my understanding these questions need to be answered: Is the service synchronous or asynchronous. If it is asynchronous, are there queues (serialization contexts) or not? If there are queues, which type of queues like exactly once in order (EOIO) or Exactly Latest (EL). Also the question is relevant which granularity do the queues have.
Why is this relevant? Why can this not merely be ignored as a technical detail of the implementation?
It can not be ignored at the time of design of a contract, because it determines the possible situations (states of the process) that may occur and that need to be resolved in the design of the contract which implies the ability to design choreographies.
To make an example. If it is only possible to update a sales order synchronously, then the contract needs not to be designed in a way to deal with a concurrent asynchronous cancellation of a previous sales confirmation, that might have happened in an asynchronous update scenario. And the resolution is not merely a technical resolution, but the resolution is better done on the business level – as for example discussed in (2). Therefore the QoS Contract implies needed resolutions on the business level – that need to be designed into the behavioral contract and into the syntactical contract.

Bibliography

1. Beugnard, Antoine, et al. Making Components Contract Aware. Computer. 1999, Vol. 32, 7, pp. 38 – 45. http://portal.acm.org/citation.cfm?id=621275.
2. Lecture Notes in Computer Science: Non-desynchronizable Service Choreographies. Decker, Gero and Alistair Barros, Frank Michael Kraft and Niels Lohmann. Berlin / Heidelberg : Springer, 2008. Service-Oriented Computing – ICSOC 2008. Vol. 5364/2008, pp. 331-346. http://www.springerlink.com/content/9055736715131767/. ISSN 0302-9743 (Print) 1611-3349 (Online).