Model 3e - Data Stores

Goals of this lesson

Usage of Databases
Transferring data between pools by using Databases

Model 3e uses Data Stores to store data in a database and to transfer it across the pools' borders.

How-to

Figure 1: Model 3e - Data Stores / IYOPRO-Link

Transferring Data between Pools

In the first activity of the bottom pool we define x = 5
Afterwards we transfer x to the first Data Store by assigning x to the Data property of the Data Association (see the highlighted area in the figure below).

Data Associations can (similarly to Message Flows) transport data.
You simply need to enter the desired data's name into the Data property.

x is now stored in the Database, and the first activity of the upper pool can read it.

Figure 2: Simulation Properties of a Data Association - The Data property is highlighted

Renaming data

As you might note (while examining the model on your own), we did not simply transfer x to the upper pool, but we also renamed it to y due to the AS qualifier in the Data Association's Data property (x AS y).

Transferring Data back to the original pool

The upper edge behind the gateway has a condition defined: y == 5.
If this is true, the upper pool's second activity sets y = 6 and writes it to the second Data Store.
Note that the variable also gets renamed back to x (y AS x).
When the condition is not met, the process terminates.

Using the new data

Now the bottom pool's second activity reads the new x from the second Data Store.
The process then uses it for decision-making at the gateway.
The bottom edge's condition checks for x == 6. Is this the case, the third activity will be executed, otherwise the process just terminates.
Since the new x is equal to 6, the third activity is being executed.

Extra Info: Using different Data Stores which resemble the same semantic Data Store

By assigning Data Stores the same name, they become the same object.
This can be very useful for extensive models.
Imagine Model 3e to be much larger with one write / read operations at the beginning and at the end of the model.

By using just one Data Store you would have to draw Data Associations across the model, which could get very confusing (especially if you also use some Message Flows).
Therefore you can gain clearness by putting up one Data Store at the beginning and one at the end of the model, both with the exact same name.