Do we need simulation parameter(s) for incoming and outgoing message flows attached on tasks

[GoogleCodeExporter]

Do we need simulation parameter(s) for incoming and outgoing message flows 
attached on tasks to specify when during the time interval of the task does the 
message flow occurs.

Original issue reported on code.google.com by dga...@trisotech.com on 10 May 2012 at 8:08

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

For what it is worth, here are some thoughts to chew on for next time.  Let's 
start with the assumption that the occurrence of the message being received 
into / sent by a task seemingly must be within the time interval that 
represents the task's duration.

In the case of "received into", I think there will be some difficulty making 
this work like a catching message event where the behavior of the token is 
simple, namely it waits for the event to happen, which presumably helps to give 
rise to less rich simulation parameters applicable to it.  With a task that is 
also "catching" a message, it is not so simple because the behavior of the 
token is more complex, which equally helps to explain the rich simulation 
parameters applicable to it.

I think, to keep it simple, we have the occurence of the receive moment, or 
more precisely the "listener" for the task that is anticipating the incoming 
message, be enabled at some percentage of the task's duration.  For example, if 
the task takes 5 minutes to do, then the receive message aspect of the task's 
behavior would be enabled at 60% of the way through that, namely at 3 minutes.  
If we don't need to worry about an enabling moment being inconsistent with the 
duration time (e.g., saying it is at 6 minutes when the task itself is only 5 
minutes in duration), then we could go with a discrete value instead of a 
percentage.  Once the moment of enablement is understood as being reached, then 
we could allow for the occurrence to be at some point that is defined as a 
discrete value or a mean with a distribution.  So, use a receive message 
enablement time (as a percentage or discrete value) and receive message 
occurrence time (as a discrete value or a mean and a distribution).

On the other hand, I haven't really divined how the simulation of a boundary 
message event attached to a task would work in the context of changing the flow 
of the token out of a task.  Perhaps it has essentially the same problem.

For "sent by", it should be relatively straightforward.  At some point in the 
task's duration, the throwing moment happens.  This could be the analog to 
occurence moment above, except that there really does'nt need to be any 
uncertainty about it.  At some point in the duration, it just happens.  So, a 
send message activation time (as a discrete value or percentage).

Original comment by ldugan.b...@gmail.com on 11 May 2012 at 8:28

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Further thought on this point.  Had occassion to discuss this point with 
Michael zur Muehlen yesterday, and have a simpler idea to the one I expressed 
earlier.  Assume that the inbound message that feeds into a task is expected to 
arrive at the zeroth moment of the task's duration so that it, in effect, is 
part of the input requirements for the task that has to be satisfied before it 
can move to the active state.  To account for potential latency and uncertainty 
about the arrival moment for receiving the message, we could have a delay 
period of some value (even zero) that could be a static value or one with a 
mean and distribution.  So, in this case, it would be like a delay time for 
task start, but it should, I think, be understood as specifically because of 
the inbound message (as opposed to what I suggested earlier).  Just don't know 
what to call that sucker.

In the same vein, assume any outbound message is automically triggered at the 
end of a task.  And since it just happens, and presumably without reference to 
any resource constraint (like a throw message event would), there would be no 
parameter for it.

The thinking was that any, more detailed assumptions about how inbound/outbound 
message flows should be seen at a task implies a deeper, finer-grained 
structure to the functionality within the task than would seemingly be 
appropriate for simulation.  If it is, then the task should be "decomposed" 
until you get past that.

Original comment by ldugan.b...@gmail.com on 15 May 2012 at 5:18

[GoogleCodeExporter]

Nashua F2F Meeting
========================
It was decided that message flows would not have simulation parameters

Original comment by sringue...@trisotech.com on 31 May 2012 at 6:42

[GoogleCodeExporter]

Original comment by sringue...@trisotech.com on 20 Sep 2012 at 7:48

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by sringue...@trisotech.com on 24 Oct 2012 at 7:09

• Changed state: Done