Forks for Newbies

[alicecbrown]

Refer to figure 255 (UML 2.0 Superstructure, p. 335).

With respect to state machine diagrams, a fork pseudo-state signifies that its incoming transition will come from a single state, and it will have multiple outgoing transitions. These transitions must occur concurrently, requiring the use of concurrent regions, as depicted below in the composite state. Unlike choice or junction pseudo-states, forks may not have triggers or guards. The following diagram demonstrates a fork pseudo-state
dividing into two concurrent regions, which then return to the EndState via the join.

From the examples used, it appears as though these forks should require a decision in order to know WHICH state forks!!!!  There has to be some reason for the original element to go down one thread as opposed to another.
Please rescue me from this quandary.    I think we need the old decision triangle.  

[sargasso]

Hi Alice.

(would you please include the date of the UML spec you are reading from, there are >1 publications of th same spec - the date is on the bottom of the title page.)

AFAIK, there is no constraint on the concurrency of the  transitions coming out of the fork, its just that the output token of the fork is available concurrently to all transitions.  By example, pumping out an email with 10 cc:'s on it makes each copy (theoretically) available to all recipients "at the same time".  It does not make them all read the email at the same time.

The constraint is on the fork, not the transitions. IIRC it just says that on acceptance of the incoming token, it will make the outgoing tokens available to all transitions concurrently.  If you like it's a zero time action.

hth
bruce

[Paolo F Cantoni]

Hi Alice,

you may want to use the [size=13]UML 2.1 Superstructure (interim)[/size] Specification. As this indicates current UML thinking.

If you could also give the caption of the diagram it will help locate it.

Paolo

[alicecbrown]

Just found the date of the User's Guide: 12/13/2006.  to clarify, that is the date the file was created.  The EA User Guide contains this diagram at EA.chm::/forkjoin.htm

So that I can be clear on this, is a join bar symbolic of a state in which the Action 'Fill order' puts the order there and the forking action 'Ship Order' and 'Send Invoices' have to acquire/request it??  It's a pull, rather than flow? No switch is needed or implied?

My references here say, Refer to Fig. 263 (UML 2.0 Superstructure, p. 340), The OMG UML specification (UML 2.0 Superstructure, p. 471) states:

"fork vertices serve to split an incoming transition into two or more transitions terminating on orthogonal target vertices (i.e. vertices in different regions of a composite state). The segments outgoing from a fork vertex must not have guards or triggers."
Tokens arriving at a fork are duplicated across the outgoing edges. If at least one outgoing edge accepts the token,
duplicates of the token are made and one copy traverses each edge that accepts the token. The outgoing edges that did not
accept the token due to failure of their targets to accept it, keep their copy in an implicit FIFO queue until it can be
accepted by the target. The rest of the outgoing edges do not receive a token (these are the ones with failing guards). This
is an exception to the rule that control nodes cannot hold tokens if they are blocked from moving downstream (see
“Activity (from BasicActivities, CompleteActivities, FundamentalActivities, StructuredActivities)” on page 328).

But UML 2.1 spec is slightly different: When
an offered token is accepted on all the outgoing edges, duplicates of the token are made and one copy traverses each edge.
No duplication is necessary if there is only one outgoing edge, but it is not a useful case.
If guards are used on edges outgoing from forks, the modelers should ensure that no downstream joins depend on the
arrival of tokens passing through the guarded edge. If that cannot be avoided, then a decision node should be introduced
to have the guard, and shunt the token to the downstream join if the guard fails.  See example in Figure 12.44 on page 342.

[alicecbrown]

Application explanation:
If there are two forks, [glb]two processes/two threads[/glb] are spawned at the fork, and in our example, the orders are shipped and the invoices mailed concurrently!!!

I do better with concrete examples than abstractions.
Thanks to all, We're enjoying the snow in Boston, as with Global WArming, it will all soon be gone.

P.s. Did you know that flash doesn't work...the HTML at the top, next to Insert Hyperlink?  I thought it was because I nested it, then tried it alone and it still just prints out the flash commands.
Alice

[thomaskilian]

Strange things you do. Never even noticed there's a flash icon. Nor would I know what to use it for. Stupid me.

[alicecbrown]

This is the curse of having first been a programmer, then turning into a Software Safety engineer, then becoming a Software process Improvement 'co-ordinator', then back to a Software Quality Engineer. We are usually hated if we are doing our jobs correctly, not 'right'..as that implies a moral judgment.
With their definition of 'forks'  would mention spawning processes equal to the number of forks.  Would make it easier for us to visualize.