Martin>> 1) we
found that customers do not seem to like to work with the activity diagrams.
Even though the ones we put out were accurate, someone else was asked to
explain them in more detail and subsequently issued a document with scenarios
in that were far more restrictive that they should have been.
[<JJ>] It is clear
that moving forward BPSS's control flow needs to be redefined. We might
also want to discuss if we want to come up with a corresponding notation. BPMN
comes to mind. MEGA had also done a lot of work in this direction.
Dale> From Martin's description, I can not tell that using UML
activity diagrams is responsible for the difficulties reported or instead the
inaccurate use of that notation was at fault. I would like to understand why
an out of band process, such as the telephone based subprocess, could not have
been captured and added. If so, would the overly restricted model been
corrected? Although I am quite willing to believe that any given UML view
might be lacking some needed aspect (after all, that is why there are so many
of those model views!), I am not able to see what features BPSS needs to add
to its control flow, and why. I have heard JJ mention adding some "numerical"
constructs (such as exactly N, at most N, at least N, M out of N, etc) to
joins/merges. I would be interested to know what additional BPSS
control constructs might be useful. Our charter, however, says we are not
trying to construct another execution language. That makes me concerned with
the rationale for any additions that are proposed. On JJ's later suggestion
about looking at BPMN and MEGA, I am not too familiar with these
efforts. I heard, possibly inaccurately, that BPMN was intended to
support a common graphical display presentation (I am sure there was more to
it), and I have not followed MEGA. JJ, could you post some pointers to
descriptions of results the TC members could/should be
considering?