RE: Same model for both Public and Private process ??

Assaf, thanks for your response !  My questions embedded

At 09:10 PM 2/2/2003 -0800, Assaf Arkin wrote:
>The external behavior of a system (its interface) is best described as:
>
>- A model of its behavior in which information is arbitrarily removed (a
>strict subset)

So you think it should be a subset of activity diagram (based on same model 
as private implementation) rather than a state transition diagram (a 
completely different model) ?  Do you see anything missing in the state 
transition diagram to represent external behavior ? or just "why bother" if 
the same model can do both ?


>If a system A is interacting with two other systems B and C, you may decide
>to have an external behavior that contains only interaction between A and B,
>only interactions between B and C, interactions between A, B and C (since
>they may be dependent on each other), and in fact all three at the same
>time.

I think the overall "external behavior" of system A is interaction of A-B 
and interaction of A-C.  It is just because system B is not interested in 
interaction A-C, so it only extract a subset of the overall behavior, which 
is interaction A-B.  If we believe we can always decompose a multi-party 
interaction into multiple pair-wise interaction, then interaction A-B and 
interaction A-C should have no coupling.


>For example, one may say that any condition is an implementation detail. On
>the other hand, it is fair for a supplier to indicate in their external
>behavior why certain purchase orders will not be processed. For example,
>because a credit card is rejected. So an opaque condition becomes part of
>the external behavior. Opaque in the sense that a condition is named
>(creditCardValidate) but not detailed (the manner in which the condition is
>evaluated).

Anything which is NOT reflected in the observable messages being exchanged 
should be treated as an implementation detail, therefore shouldn't be 
defined in the external behavior.

First, in your example, why does the supplier service want to tell the 
customer that it will check their credit card (which is part of their 
implementation of order processing).  What if the supplier service want to 
change their implementation so that if check the customer's credit history 
rather than the credit card ?

But lets make it more generic (say "creditValidate"), and lets assume this 
step will never be skipped and we want to externalize our decision to the 
customer.  Then I think the opaque condition should be indicated by 
defining a SOAP fault message called "InvalidCreditFault", which achieve 
the same effect as externalize the named condition "creditValidate", and 
also make the decision visible in the messages being exchanged.


Best regards,
Ricky

Received on Monday, 3 February 2003 10:58:54 UTC