Re: Requirements 1.0 - comments on D-UC-004

Ok, then I understand that the use case really illustrates two very 
general things:

First, choreography execution may be dependent on business rules (one 
example is a rule that selects a behavior based on the identity of a 
party to the interaction).

Second, the use case also illustrates the combination of a dynamic, 
business rule driven decision into a choreography flow. There could be 
several kinds of combination: parallel processing, dependency, and dynamic.

I notice the latest draft has incorporated some of my proposed text (and 
maybe my diagram, I'm not sure).

I don't want to obsess on this one use case, but I would still like to 
see the following text bits made more clear:

>  Note: In this case, independence is maintained. The Handle Questionnaire is actually executed against business rules during process execution, although it is either path is known prior to execution. Each is a valid path. The business rules related to the quality check are applied 'in' the process, even though a business context rule is applied prior to the order process initiation to maintain process independence.

 >  Note: In this case the business rules are applied first and either 
path is is actually executed before and during process execution. 
Although either path is known prior to execution. Each is a valid path. 
The business rules are applied overall before and 'in' the process.

These are quite opaque to me, although I understand them a bit better 
after Monica's explanation.

"Either path is known prior to execution"? It seems to me the point is 
that the path taken is not known prior to execution, but is dynamic; 
however, the text might suggest the opposite.

Since in the last two diagrams "Handle Questionaire" (should be "Quality 
Check", for consistency?) is in both alternate flows, it appears it is 
not actually optional here, but instead how it is performed can be 
different, depending on some rule. Is this accurate?

I'd suggest some rewording, but I'm not clear enough on the intent. 
Maybe Monica can help.

--Jon

Monica Martin wrote:

> mm1: Jon, actually there are a few inferences here that are potentially 
> lost if you use the alternate .gif you provided. To explain:
> 
>    * An agreement is understood prior to entry.
>    * At entry, business rules can be applied or the rules can be
>      applied dynamically during the process execution:
>          o Parallel processing - A dependency exists and the parallel
>            processes are combined at the end (quality check applied
>            prior to completion).
>          o Dependency: See ordering process Jon specifies above
>            (quality checks used as a subprocess). Note, that business
>            rules are applied at entry.
>          o Dynamic: See ordering process Jon specifies above where the
>            quality check may or may not be applied during process
>            execution.
> 
> Therefore, the drawings could be updated.  The simplification Jon did 
> only reflects part of that.
> 
>>
>> Another, related use case is this: in some cases where a check might 
>> normally be performed, the Buyer might request that the Seller omit 
>> the quality check, in order to be able to ship faster.
>>
>> Together, these lead to a requirement that the choreography flow is 
>> able to be altered, or one or more alternate flows selected, based on 
>> the identity of a participant, or based on a request to do so (which 
>> might be conveyed here as part of the incoming purchase order).
>>
>> See attached diagram.
>>
>> I think this is much clearer. However, it does leave out some bits 
>> from the original diagrams/text - but like I said, I think it's making 
>> multiple points, with multiple scenarios. Possibly some of the ideas 
>> I've omitted could be written up in a separate use case.
>>
>> --Jon
>>
>> ------------------------------------------------------------------------
>>
> 
> 
> 
> 

Received on Monday, 28 July 2003 16:44:51 UTC