[ebBP] 3/28/2004: WI-50 Constraints on Control Flow (TimeToPerformattribute of parallel tasks) [RSD]

["Monica J. Martin" <Monica.Martin@Sun.COM>]

Discussion|OASIS.ebBP.WI50-Control flow constraints;
Topic|;
Point|Touchpoint to late binding for v3.0;

mm1@
I wanted to share some feedback I received from Dennis Krukkert on 
TimeToPerform for Work Item 50.  This can be considered in v3.0. 
However, I think this relates to our recent discussions about what 
underlying constructs and concepts on which BPSS was based (activity 
diagrams, future - petri nets or other concepts, for example).

Work Item 50: Constraints on control flow
Description: Transitions between binary collaborations within a 
multi-party collaboration should be restricted. Currently, the 
destination of a transition can be any activity in the destination 
activity diagram.  However, in this case, this should be the start state.

I am not asking for any action now but we should think about Dennis' 
comments as we finalize v2.0 in anticipation of v3.0.  We will try to 
keep it simple for v2.0 and create a good baseline from which to work in 
v3.0.

Thanks to Dennis for his contribution.

===========================================================================================================
Dennis Krukkert: Hi Monica,

Recently you asked me to clarify my statement on the TimeToPerform 
attribute in bpss. I hope this helps a bit...

The problem starts with the lack of formal semantics on UML activity 
diagrams. Opposed to statecharts, activity diagrams have no formal 
semantics. Eventhough it is not formally stated, one of the common 
assumptions is that a activity in an activity diagram cannot be exited 
by an external trigger (opposed to a state in a statechart), so if the 
TTP attribute on collaboration level is exceeded, the event that occurs 
cannot cause the activities in the diagram to terminate.

Let's assume that the problem above is solved. Then still we have to be 
more specific on what happens if TTP exceeds (or, on the semantics of 
this parameter). In my opinion there are two ways to use this parameter, 
one of which has to be chosen (or it must be possible to specify the 
difference).

1 - Use TTP to introduce optional activities. If the diagram reaches 
such an optional activity, there are two ways to leave the activity. The 
first way is that something happens within the activity (within the 
limits of TTP) that causes the activity to terminate (and exited). If 
this happens, all actions (sending and receiving documents) within the 
activity are performed. If the activity does not terminate within TTP, 
then TTP triggers the exiting of the activity. All actions (sending and 
recieving of documents) that are already performed should be rolled back.

Example -> If you get a speeding ticket in Holland and you don't agree 
(because you're certain you didn't drive at the specific place and 
time), you have 2 weeks to sign a protest. If the justice department 
does not receive a protest within these 2 weeks, everyone assumes that 
you agree on paying the ticket (this can be modelled by an activity 
"protest" with ttp=2w).

2 - The second option is to use TTP as a requirement attibute. This 
means that all activities are mandatory but if TTP is used, an activity 
has to be completed within a specific period. Now, if TTP is exceeded, 
an error will occur and normal is terminated.

Example -> If you don't protest within two weeks (prev. Example), is 
clear that you have to pay the speeding ticket. You have 4 weeks to do 
so. Paying the ticket is (too bad) not optional. If the 4 weeks are 
exceeded, the normal collaboration is terminated and the justice 
department will seek other means to receive their money.

If option 1 is chosen, another problem occurs. If the activity does not 
terminate itself, you'll have to wait until TTP is reached before you 
can continue with the next activity. If the activity containing a TTP 
attribute is in a parallel branch, this means the join cannot be taken 
until TTP is passed.

I've also looked into Zing, but I think that this is another kind of 
project. As far as I can see, Zing is a model checker to assure 
integrity when parallelism is used in one model. The project I did 
looked for a way to check overlap in parallel executing of two different 
models.
===========================================================================================================
@mm1