Re: Events and States (was: timeouts & states

At 11:02 AM 4/11/2003 -0700, Assaf Arkin wrote:

>Ricky Ho wrote:
>
>>
>>I understand the "nested state", basically you breakdown a state into 
>>finer grain, but this is still mutually exclusive.  You can only be at 
>>one of the substate.
>>
>>In David's example, lets say the seller interact with the manufacturer as 
>>well as the credit check.  In the public state diagram, the seller want 
>>to express that the purchase order will be confirmed only when the credit 
>>check passes as well as the manufacturer have the product in stock.
>>
>>So, does the seller has two non-exclusive states "credit-pass", 
>>"product-available" ?
>
>Practically speaking, also as far as statechart is concerned, the seller 
>has two non-exclusive states that are part of the same parent state. 
>Although the startchart chart does not depict this, the statechart model 
>actually accomodates for that type of state (aka state variables).

Yes. I agree. And also we should not think "ONE" statechart diagram will 
capture all the dynamic aspects of the system.
Remember statecharts are designed to express one aspect.
Having too many state variables also does not help to focus on the behavior.


>There's one thing to demarcate a state. You do something and you enter a 
>state in which you can do other things until you leave that state. 
>State-transition diagrams talk about these states. Another thing is to 
>have a particular state that does not demarcate any activities, e.g. the 
>balance in your account.

This is exactly kind of places we should represent system  in "PetriNets" 
and reduce the behavior into actions or states where we want to focus on.

>Let's say you have 6 products to ship as part of a purchase order. At some 
>point in time you have already shipped two products, are currently 
>preparing to ship two other products and will later ship the last two 
>products. What state are you in?
>
>If you think in terms of binary states, you need an endless number of 
>combination to account for such scenarios. On the other hand, you can have 
>variable states, a state that is defined by a range of values. For 
>example: { shipped=2, shipping=2, remaining=2 }. Along side you can also 
>have demarcated states, e.g. "in the process of shipping" which is 
>contained in "in the process of fulfilling an order".
>
>The state you are in is usually defined in terms of the possible values 
>you can have and also the possible activities you can perform.
>
>arkin
>
>>
>>or 4 mutually-exclusive states "credit-pass and product-available", 
>>"credit-pass and NOT product-available" .....
>>
>>The latter is easier to understand.
>>
>>Rgds, Ricky
>>
>>At 10:15 AM 4/11/2003 -0700, Assaf Arkin wrote:
>>
>>>Ricky Ho wrote:
>>>
>>>>
>>>>In David's example, "State" is not mutually exclusive.  (Correct me if 
>>>>I'm wrong).  A role can have multiple "states" at the same time and 
>>>>each of this state can accept different events and transition to 
>>>>another states.  Somewhat similar to a multi-thread scenario.  So when 
>>>>one thread reaches an end state.  The choreography can still be active 
>>>>because of other threads.
>>>>
>>>>This is quite different from the traditional state chart who try to 
>>>>avoid composite states.  Am I totally lost ?
>>>
>>>
>>>Some state transition models have mutually exclusive states.
>>>
>>>Statechart diagrams have composite states, so they allow for 
>>>non-exclusive states and multiple concurrent sub-states as part of the 
>>>same parent state.
>>>
>>>arkin
>>>
>>>>
>>>>Rgds, Ricky
>>>
>>>
>>>
>
>
>--
>"Those who can, do; those who can't, make screenshots"
>
>----------------------------------------------------------------------
>Assaf Arkin                                          arkin@intalio.com
>Intalio Inc.                                           www.intalio.com
>The Business Process Management Company                 (650) 577 4700
>
>
>This message is intended only for the use of the Addressee and
>may contain information that is PRIVILEGED and CONFIDENTIAL.
>If you are not the intended recipient, dissemination of this
>communication is prohibited. If you have received this communication
>in error, please erase all copies of the message and its attachments
>and notify us immediately.
>
>

Received on Friday, 11 April 2003 14:35:03 UTC