Re: More about the patient/receptionist/doctor use case.

The doctor/patient scenario can be viewed as an example of two 
fundamental scenarios:

1. The multiple server/single queue scenario (this is how I introduced 
the use case at the F2F)
2. The composite business scenario (to build a patient visit service 
you need to combine a receptionist with a doctor)

If the latter is the intent, then the diagrams are fine. If the former 
is the intent, then my issues stand.

Frank

On Thursday, March 27, 2003, at 10:48  AM, Ricky Ho wrote:

> I think the diagram precisely represent the text description of the 
> use case I originally put up.
> We can argue whether the doctor use case really need an interleaving 
> dependency.  And I'd like to hear from Francis which particular 
> dependencies are inappropriate.
>
>
>> One issue behind diagrams like these is that (a) they presuppose an
>> ordering relationship between messages between the receptionist and 
>> the
>> patient that is dependent on message between the doctor and the
>> receptionist. This is not accurate.
>> [saw]I don't think this is an issue of the diagrams itself. The 
>> diagrams were to help visualize the issues of the discussion. A 
>> multi-Party choreography presupposes the ordering relationship you 
>> mention. But the individual 2-party choreographies do not presuppose 
>> this ordering relationship. The diagrams helped clarify the 
>> difference between the two approaches (at least for me).
>
> +1
>
>> And (b) that there is one
>> receptionist/patient interaction with every receptionist/doctor
>> interaction, again not sustainable; at least, the interleaving is not
>> so straightforward.
>> [saw]This might be an argument against a multi-party choreography or 
>> we should discuss a way of representing complexities of the 
>> relationships, if possible. Again, I intended the diagrams to help 
>> facilitate the discussions.
>
> +1
>
>
>> Frank
>

Received on Thursday, 27 March 2003 13:56:53 UTC