The synchronizing stub is a dynamic or static stub with plug-ins that must synchronize before continuing with the traversal past the stub. Therefore, dynamic stubs have the following behavior:

  1. A standard dynamic stub allows one plug-in to be chosen.
  2. The Multiple Choice pattern extends the standard dynamic stub to allow more than one plug-in to be chosen. The plug-ins are executed in parallel but do not synchronize.
  3. The synchronized stub extends the standard dynamic stub even further by requiring the plug-ins to synchronize before continuing with the traversal past the stub. There are a number of variations in terms of the number of plug-ins required to finish before continuing on.
    1. One or more plug-ins can be chosen but all chosen plug-ins need to finish before continuing (this supports the Synchronizing Merge pattern).
    2. M plug-ins are chosen but only N need to finish before continuing (this supports the N-out-of-M join pattern).
    3. One or more plug-ins can be chosen but only one of them needs to finish before continuing (this supports the Discriminator pattern).
    4. Note that in cases 2 and 3, the remaining plug-ins finish but are ignored (they do not trigger another continuation of the traversal).

Therefore, static stubs have the following behavior:

  1. A standard static stub executes its only plug-in once.
  2. In addition to the N value discussed above, a synchronizing static stub specifies the number of parallel invocations for its plug-in (i.e. a replication factor for static stubs). Each invocation of the plug-in is executed in parallel when the traversal reaches the stub. Each invocation of the plug-in must finish before continuing the traversal past the stub. There are two cases in terms of how the number of invocations can be specified:
    1. The number can be hardcoded (this supports the Multiple Instances With A Priori Known Design Time Knowledge pattern).
    2. The number can be variable (this supports the Multiple Instances With A Priori Known Runtime Knowledge pattern). Variable numbers use integer scenario variables.

This requires stubs to be identified as synchronizing. Also for dynamic stubs, the number of plug-ins that need to finish before continuing must be specified (default is all that were chosen). The number of chosen plug-ins is defined by the selection criteria of the plug-ins. Also for static stubs, the number of parallel invocations needs to be specified.

Furthermore, the notation for a dynamic stub needs to at least indicate that the stub is synchronized (e.g. with the letter "S" inside the stub). Ideally, the number of plug-ins that must finish should also be shown inside the stub ("1/n" for Discriminator, "n/m" for N-out-of-M join, and nothing else for the default Synchronizing Merge). In terms of synchronizing static stubs, the same "S" inside a stub could be used with a number that indicates the number of parallel invocations (or "n" in case of variable invocations) followed by "x".

-- Gunter Mussbacher - 22 Mar 2007

Form For Req edit

Req Name SEMReq Synchronizing Stubs
Description jUCMNav shall support synchronizing stubs.
Type Functional
Importance Mandatory
Priority Urgent
Status Proposed
Author Gunter Mussbacher
Dependencies
Verification Approach
Test Cases
Topic revision: r3 - 22 Mar 2007 - 23:22:40 - Gunter Mussbacher
 
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback