Iteration on UC3

["Jacques R. Durand" <JDurand@us.fujitsu.com>]

Dale, Stephen:

 

I am looking at UC3 states and focusing on the conditions that cause the state changes.

The way I understand what causes a state change is that there has to be an "observable event" causing the change, from a TaMIE viewpoint. (sometimes, there is no event at all and the transition is automatic)

 

This leads me to this slightly different version of an LTS graph for this use case, with a more explicit "condition" stated inside the "Label" elements:

 

<Label>FromState, ToState,  condition </Label>
 

So:

 

<Label>SimplePurchaseOrderCollaboration2,Start2,message_BtoS:POrequest</Label>

means that the transition from state "SimplePurchaseOrderCollaboration2" to state "Start2" is caused by the exchange of a message from B(uyer) to S(eller) of type "POrequest".

 

At this point, the states and state changes are from the viewpoint of a "man in the middle" i.e. a 3rd party observer not biased on either side (Buyer or Seller). So the only events my "conditions" know about is timing and messages that go back and forth.

 

That leads to this initial notation (which is still an "abstact" LTS, no XPath in it, and veru rough mark-up...):

( Dale: I used as starting point some complement diagrams you sent me some time ago, in  a word doc)

 

<Node>SimplePurchaseOrderCollaboration2</Node>
<Node>Start2</Node>
<Node>Cancellation2</Node>
<Node>OrderRejected2</Node>
<Node>OrderChanged2</Node>
<Node>OrderConfirmed2</Node>
<Node>PORequestResponses2</Node>
<Node>Cancellation2</Node>
<Node>Success2</Node>
<Node>Failure2</Node>

 

<Label>SimplePurchaseOrderCollaboration2,  Start2,  message_BtoS:POrequest</Label>
<Label>Start2,  OrderRejected2,  message_StoB:POreject</Label>
<Label>Start2,  Failure2,  (ElapsedTime > 2 hours)</Label>
<Label>OrderRejected2,Failure2,  true</Label>
<Label>Start2,  OrderChanged2,  message_StoB:POchange</Label>
<Label>Start2,  OrderConfirmed2,  message_StoB:POaccept</Label>
<Label>OrderConfirmed2,  Success2,  true</Label>
<Label>OrderChanged2,  Success2,  (ElapsedTime > 3 days)</Label>
<Label>OrderChanged2,  Start2,  message_BtoS:POupdate</Label>
<Label>OrderChanged2,  Cancellation2,  message_BtoS:POcancel</Label>
<Label>Cancellation2,  Failure2,  true</Label>

 

Then of course we can add more structure and information, to get a processable mark-up with XPath.

 

Is that an acceptable LTS rep of the Use case?

 

-jacques