The infancy of workflow diagramming standards
I did something foolish recently... I criticized someone for an analysis diagram that, I felt, didn't use "standard" workflow notations.
Granted, the diagram looked very different from the kinds of diagrams that have been coming out of workflow tools, and it definitely wasn't compliant with UML Activity diagrams, but that still didn't give me the right to be critical. How can I tell someone to "follow a standard" when a standard doesn't exist?
There are some links to an emerging standard, however, that I would like to share. First off: the Business Process Modeling Notation (BPMN) specification (currently in v1.0 draft status) is an open source initiative to create a common diagramming standard that (a) doesn't have the limitations of UML as it applies to human collaborative workflow, while (b) provides a good standard for business process modeling that can be mapped to BPEL.
On that site, you would find a good (fairly short) paper comparing BPMN and UML Activity diagrams written by Steven White of IBM. I heartily recommend this paper.
One problem that I have with diagrammatic standards to date, including BPMN, is the lack of clear determinism in the diagrams themselves. Unfortunately, I can't level my criticism in this blog, very easily, because I haven't quite figured out how to embed an image in the blog! I will, however, try to explain.
In Code, we can show the beginning of something, and the end of something... we call it scope.
public void myroutine(int param1)
{ // myroutine scope starts here
if (condition == true)
{ //if scope starts here
} //if scope ends here
} // myroutine scope ends here
However, in workflow diagrams, this is not so easy to do. Workflow diagrams are graphs. Pathways can snake through a diagram without respect to starting points or ending points. Process A can branch out to two parallel processes, B and C, which then merge back together in process D.
This looks good in a small excerpt. However, if we put in semantics, and a real world scenario, we can end up with lots of hidden rules. For example: let's say that we have the process described above (A -> (B or C) -> D)... Now, let's add the workflow pattern of a synchronization... this means that process D cannot begin until both processes B and C are complete.
That's all well and dandy, but what if B loops back around and merges with A? Would this be legal?
If B calls A, and when A is done, it is expected to use some form of "return" notation to denote that we should return to B, and then continue on to D? Is this legal?
The reality is that there is a scope for the parallel split that occurs when the workflow process branches from A to both B and C. That is the scope of the join at the end (from B and C down to D). That scope needs to have properties, to be respected, to make sense. The engines need to know what processes are related, what processes are required to complete.
The diagramming standards provided don't enforce that sense. There are no constraints.
As a result, it is trivial to take a workflow model, as diagrammed in the BPMN and create a structure that works very well... then add a perfectly legal link and create a structure that works very poorly or not at all.
In software development, we learned this lesson the hard way, in 1968, when Edsgar Dijkstra published a paper titled "Goto Considered Harmful" (see https://www.acm.org/classics/oct95/). This is one of the key triggers to a series of changes in language innovations that led, ultimately, to structured programming. I would posit that without the "culture" of questioning language design that arose out of this transformation, the innovations that led to Object Oriented development, and now Aspect Oriented Development, would not have been possible. Constraints are good.
Of course, I am no expert in UML 2.0 or in BPMN, so it is quite possible that there is a rule, somewhere, that says that my assertion would not be legal. I have not seen it, and if it exists, I encourage my fine readers to point it out to me.
My concern is that we have created two standards for workflow notation (BPMN and UML 2.0) that are no different in their fundamental constraints than BASIC and FORTRAN were... they both appear to be at the same level of evolution, where it is still more important to diagram what can be done, than to constrain the modeler from represeting flows in a way that should not be done.
B+ for effort. C- for results.