Dale,
The issue of the Activity diagrams is that people generally
do not take the time to sit down and work out how to read them. We spent
lots of time on the phone explaining to our developers and other designers
explaining the nuances of the diagrams and the use of the patterns. Once
these people spent the time to understand most of them saw that they were more
powerful than a finite set of scenarios.
The other issue you mentioned was the lack of modeling of
the ourt of band transactions. What we did to get round these was to
implement transactions that could be sent from our system to the partners
system. The consequence of this is that we suddenly had a doubling of the
number of Business transaction activities in a collab. as the BPSS does not
allow a BTA to be initiated by either partner.
One model would be to allow a transaction to run in
reverse, i.e. The normal would be that you send me an order and I send you a
order response. In the event of an out of band order placement, I send you
the customer the purchaseOrder Response and the customer sends me back the order
that they should have sent. In this way the transaction activity has been
completed and the states aligned.
Martin
Roberts xml designer, BT Exact e-mail:
martin.me.roberts@bt.com tel: +44(0) 1473
609785 clickdial fax: +44(0) 1473 609834 Intranet Site :http://twiki.btlabs.bt.co.uk/twiki
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?
|