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.

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.

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.

• structured,
• unstructured and
• semi-structured

processes, that I like. It is interesting, that in the definition of process the emphasis on the post is less on the sequence of activities, but more on the business goal to reach. That was, what I proposed earlier. And it makes sense. In the end it is more important, what the result of a process is, than what has been done or should be done in which order to try to (!) achieve it. I said “try to” because sometimes just doing a thing can not guarantee that the desired result is achieved. That’s why I say that the result is more important than the doing of an activity or task itself.
Of course it is inevitable that when a business process is implemented in an business process platform, that it is structured. Otherwise it is impossible to implement the business functionality that transforms the business objects that are part of the business process from one state to another. That is said modulo that there may be some generic functionality like a process engine for workflow or generally for execution of modeled process parts of course.
BPMN supports some Ad-Hoc modeling cababilities. There are Ad-Hoc tasks where the sequence is not defined or where it is not defined if none, one or all of them are executed. However one would expect, that any task that can be executed is modeled – at least if it is not, it can not be system supported. Also it is a difference, if the Ad-Hoc cababilities are on the process type level, or on the instance level, meaning that a concrete process instance can be adapted to a new, unexpected flow, sequence or even new Ad-Hoc Tasks.
However the more the tasks become Ad-Hoc the more they become an empty shell. What do I mean by this?
Create an Ad-Hoc task “Calculate stock losses based on financial crisis”. Of course if this is done the first time, there is no busines logic implementation for this. Even if there is a SOA service offering the solution, there needs to be some implementation of calling the service, which means gathering and providing the needed parameters and using the result in other processes.
So – as soon as a process is implemented in a business process platform it has at least some constraints.
Which is ok – because it has been formalized, because it’s execution is more repetitive.
On the other hand especially in times of crisis the importance of Ad-Hoc processes grows to account for the need to compensate unforeseen difficulties in the daily “business as usual”.
The important thing is, that the structured, the unstructured and the semi-structured processes can be integrated as seamless as possible. This is only possible, if there is a common notion of result of a process or of an activity in the process. Furthermore it is an interesting question – especially in semi-structured processes – how much constraints are desribed.

• None Constraints: Unstructured.
• Some Constraints: Semi-Structured.
• All Constraints: Structured.

As a general consideration the underlying problem discussed in the executable modeling debate is this: If Process Modeling is done, there are different purposes for it, as I already stated:
http://www.bpmnforum.net/blog/bpmn/bpmn-in-practice/process-modeling-purpose/
and
http://www.bpmnforum.net/blog/bpmn/bpmn-in-practice/more-on-modeling-purpose/
And yes – most BPMN models today are done for documentation purposes. But ImhO this is quite natural.
BPMN modeling is always done with a purpose. It is done or is most prudently done within a context of a BPM strategy that includes a BPM transformation. For a discussion about this see for example (1). One part of this BPM transformation is the as-is modeling of processes – for which a process documentation is needed. So in such a phase BPMN can serve as the as-is analysis modeling language – which it mostly does as of today. But that is not the whole purpose of the BPM transformation. It is a first step. The subsequent steps are shall-be process design and realization of the shall-be process. The realization is not necessarily done or always done with IT systems. But even for a process execution within a non-IT context consistency and completeness of a process model makes sense. Furthermore the more a process model goes into being the foundation of an IT realization, the more it must become executable – or at least be usable for development and ideally for model driven development. Therefore as the maturity of BPM transformations is progressing with time, the importance of the executable modeling aspect increase.

Bibliography

1. Snabe, Jim Hagemann, et al. Business Process Management – the SAP Roadmap. Bonn, Boston : Galileo Press Inc., 2009. ISBN 978-1-59229-231-8.

There have been complaints, that BPMN 2.0 is only designed with the goal of defining an executable process modeling language and that this impairs the usage of the modeling language for the purposes that it is currently most often used for: documentation.
http://www.brsilver.com/wordpress/2009/01/19/bpmn-20-update/
The complaint is that a model would not be counted as valid, if it is not executable. The demand is that it should also be valid, if it is not executable.
To shed some more light on the issue it is necessary to discuss several aspects. These come to my mind immediately:

1. Choreography Modeling and Execution
2. The concept of enforceability
3. Conformance
4. Abstract Processes

Ad 1) A new feature in BPMN 2.0 is the choreography model. Modeling a choreography model with BPMN 2.0 means modeling an abstract process representing the view of an independent observer on the exchange of the messages that are exchanged between participants. This process is by definition abstract, because it is “in the middle between” the participants. So by definition such a process can never be executed directly or be executable. It can only be realized by means of processes within the participants. But the realization is not necessary for a choreography model to be valid.
Ad 2) Enforceability of a choreography process is an attribute, that holds true, if a choreography model can be realized at all. Not all choreography models are able to be realized. This is completely independent of any technology. It is because of logic only. To make an example If we define this process between John, Mark and Jane, which are in different cities: First John calls Mark and tells him the weather. Then after this Jane calls Mark and they plan the weekend trip. This process is not enforceable. Because Jane cannot know when John has called Mark. So to make the process enforceable, John or Mark need to call Jane to tell her, that John and Mark have phoned. Which of both is better is another thing – but the first process is not enforceable – completely independent of the technology.
So yes, there are some rules in BPMN 2.0 Choreography model that must be kept with a choreography process so that the enforceability is not destroyed. But this has merely logical reasons.
Ad 3) There is a difference between Process Modeling Conformance and Process Execution Conformance. Process Modeling Conformance does explicitly not require that the Process Execution Semantics is kept. However the Process Execution Semantics is most clearly defined. But because this is optional, it is only for those who want to execute. And for those, an execution semantics is very helpful.
Ad 4) Abstract Processes are Processes that have the process type abstract. By definition they are not executed as is, but they are an abstraction of the process, that is really executed.
Good discussion though and I might continue to post on this.

http://www.brsilver.com/wordpress/subscribers-only-2/three-levels-of-process-modeling-with-bpmn/

The three levels
1) Descriptive Modeling
2) Analytical Modeling
3) Executable Modeling
Match quite nice with the levels 1-3 that I proposed. However I named them purposes and not levels, because when we have levels I think of a stack of models, each in different levels and somehow related – which is not the intention here. Yes, having different purposes might imply having different levels, but not necessarily.
I think that Bruce Silvers’ level 2 modeling, though keeping the validation rules of BPMN, might have some difficulties in expressing all the special cases. Bruce Silver states, that on Level 2 both conditions need to be fulfilled:
a) The model must validate against BPMN rules and
b) the model must cover the special cases of the business process
I see especially b) as very challenging. At least if we assume that the resulting model should still be readable in the end.
About Bruce Silver’s Level 3 I want to say: I think that many business processes cannot be executed by a workflow engine (as a BPMN engine).
Therefore I have proposed the 4th purpose: Model Driven Development. This means creating for the purpose of using them in some development environment where models can be refined for implementation – may be with the help of more detailed models, which would validate against the BPMN models, but be not limited to it.
I am not saying, that the detailed models should or are necessarily BPMN models. But there is a difference between this modeling purpose and the modeling purpose of Bruce Silver’s level 2) or 3), because in this 4th purpose it is not necessary to model all the special cases in advance, because they can be added in the detailed model. This makes the models more readable. On the other side the models of purpose 4 have sticter rules than those 1) – because they need to define the constraints for the lower level models.
In practice one would probably start with purpose 1), then might go into 2) for simulation purposes. For selected processes, he would go into 3) – but only for those parts of a process that should be executed as workflow in the end – which is the lesser number of processes I would say. Then he would go into 4 for the other (non workflow) processes and would try to realize more detailed models. Possibly someone else would to this job. Because then the detailed modeler would find some inconsistencies or ambiguities in the overview model and needs to correct them (of course if he can make some assumption about what is required).