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

Jon Dart wrote:

> 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).

mm1: It is the updated diagrams I provided in the reformatting of the 
use cases, as requested by the editors.

>
> 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. 

mm1:  This could decompose into several possibilities, now that I think 
about it further (Are we obsessing on this one case...in any case...):
It could occur that we know the business rules beforehand and (1) can 
execute, (2) may execute (Note: I didn't specify how, that accounts for 
the difference paths to do so). Second, what if the rule is not known 
beforehand, and a decision is made to execute this type of rule. This is 
slightly broader than my original thoughts in this use case, as I didn't 
think about then.  Therefore we have:

    * An agreement is understood prior to entry.
          o Business rules known and applied at entry
                + Parallel processing - A dependency exists and the
                  parallel processes are combined at the end (quality
                  check applied prior to completion).
                + Dependency: See ordering process Jon specifies above
                  (quality checks used as a subprocess).
          o Business rules known and applied during process execution
                + Dynamic: See ordering process Jon specifies above
                  where the quality check may or may not be applied
                  during process execution.
          o Business rules unknown prior to entry
                + Dependency: See above.
                + Dynamic:  See above.

> Note: Difference between dependency and dynamic may disappear in the 
> third scenario.  Thoughts?
>
> 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?

mm1: I think if we look at this more abstractly, many types of Quality 
Checks could be applied. Handle Questionnaire is just one example.  I 
would be happy to say apply Quality Check and specify in this case it is 
Handle Questionnaire.  Thoughts?

>
> 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 19:53:39 UTC