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

> -----Original Message-----
> From: public-ws-chor-request@w3.org
> [mailto:public-ws-chor-request@w3.org]On Behalf Of Ricky Ho
> Sent: Monday, February 03, 2003 7:58 AM
> To: Assaf Arkin
> Cc: public-ws-chor@w3.org
> Subject: 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 ?

Generally speaking activity diagrams and statechart diagrams are equivalent,
you can model the same information with one or the other, it really boils
down to how you decide to look at the information. You can model the private
process as a statechart diagram, the public process as an activity diagram,
and both processes as both diagrams at the same time. (See also Mayilraj's
e-mail)

There are some simplified state transition diagrams which are subsets of
statechart diagrams, as weel as simplified flowchart diagrams that are
subsets of activity diagrams. Since they are not complete depending on what
you want to model you may use one or the other but not both.

But there's no choice to use one or the other, you can have one person look
at the external behavior as an activity diagram since they prefer to see
distinct swimlines, and another person look at the same definition as a
statechart diagrams since they want to see clear relation between states.

Do not confuse the use of 'activities' in the various specifications with a
decision to use only activity diagrams. The distinction is not that clear
cut. For example, in WSCI a context would be equivalent to a state and a
complex activity would combine the state with the transition rules.


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

You can decompose but can you re-compose?

It is possible that the interaction between B and A and B and C is affected
by the interaction between A and C. In other words, that interaction is
observable to B though it does not involve B. You can decompose such a model
into three distinct interactions, but can you re-compose them into the right
model without any additional information?


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

I definitely agree. I said that the decision what to include in the external
behavior is arbitrary and subject to best practice. I would include
everything that is observable from the message exchange and nothing that is
not observable. I also use that to determine where to show a multi-party
choreography and where to show only bilateral choreographies. In other
words, everything that is observable by some participant should be expressed
in the choreography even if that operation does not involve that
participant.

(But again, this is treading into best practices, and some users may find
good reasons to include less information 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 ?

It wants to show that a decision is being made that will affect which
operation would occur next, but without restricting the implementation. You
are perfectly right, the name I selected is too revealing about the
implementation, but then it is just a name, it has no semantics that tell
you what actually happens behind the scenes.


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

That's a good question.

One way to model the process is to have distinct operations that clearly
indicate by act of performing the operation what has happened. In this case
the condition is always opaque, i.e. you know there is some condition there
but not what it entails. You only know that either X or Y would occur, not
why.

I think that's a good best practice.

But you may find valid cases where operations are overloaded, for example:

switch
  case
    condition not(accountValidate)
    operation reject
  case
    condition not(creditValidate)
    operation reject
  default
    operation accept
    . . .

arkin

>
>
> Best regards,
> Ricky

Received on Monday, 3 February 2003 13:38:22 UTC