[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [ebBP] 3/28/2004: WI-50 Constraints on Control Flow (TimeToPerformattribute of parallel tasks) [RSD]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]