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

My intent is the latter.

Rgds, Ricky

At 10:56 AM 3/27/2003 -0800, Francis McCabe wrote:
>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 14:16:42 UTC