According to the following BDD fragment and Activity Diagram with a DataStoreNode, how many DataToken tokens will still be in the «dataStore» AFTER a DataToken from the store is printed?

Click on the image to view it full size

Watch simulation

Watch a high resolution version of the video on Vimeo.

UML2.5.1: 'When an offer for an object token held by a DataStoreNode is accepted by a downstream object node, the offered token is removed from the DataStoreNode, per the usual CentralBufferNode semantics. However, a copy is made of the removed object token ...'

UML2.5.1: '... a copy is made of the removed object token, with the same value, and this is immediately placed back onto the DataStoreNode. Thus, the values held by a DataStoreNode appear to persist for the duration of each execution of its containing activity, even'

The initial “loop” will place 3 DataToken tokens in the DataStoreNode. There will still be 3 DataToken tokens in the DataStoreNode even after the OpaqueAction print("ds") has accepted a token offer, because offered tokens are effectively restored to the DataStoreNode.

Compare with:

SysMLv1: Cameo Simulation Toolkit: Activity Diagram simulation: Tokens in a CentralBufferNode [with mini video]

We are offering a HUGE 50% DISCOUNT off all SysMLv1/MBSE group course bookings fully pre-paid by 30th Nov 2025! Contact us now to apply!

Up next

TIP: SysMLv1: Cameo Simulation Toolkit®: HOWTO handle receiving multiple Signal events in parallel within a repeated loop [with mini video]

Notes

Snippets (quotes/extracts)

[UML-2.5.1] An ObjectNode may contain multiple object tokens with the same value. Such tokens are not normally combined (but see the special semantics for DataStoreNodes ...).

[UML-2.5.1] 15.4.3.4 Data Store Nodes - A DataStoreNode is a CentralBufferNode that holds its object tokens persistently while its activity is executing.

[UML-2.5.1] When an offer for an object token held by a DataStoreNode is accepted by a downstream object node, the offered token is removed from the DataStoreNode, per the usual CentralBufferNode semantics. However, a copy is made of the removed object token ...

[UML-2.5.1] ... a copy is made of the removed object token, with the same value, and this is immediately placed back onto the DataStoreNode. Thus, the values held by a DataStoreNode appear to persist for the duration of each execution of its containing activity, even

[UML-2.5.1] When a DataStoreNode accepts an object token, if that token contains an object with the same identity as an object contained in a token already held by the node, then the duplicate object token shall not be placed on the DataStoreNode.