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
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.
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 = 6and 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.
-
Report
See below for the run configuration, which we set up to receive the report statistics from below.
Please refer to the section Experiment Results for more information on the report specific data.
Run configuration
-
Stochastic Seed: 12345
-
Simulation start date: 1/1/2014 12:00:00 a.m.
-
Simulation stop time: 240
-
Simulation stop time unit: Hours
Report statistics
-
By looking at the report, we note that our model has been simulated just fine
-
Though, there is one single fact in the report, which does not add up at first glance: The bottom pool’s gateway statistics
-
Why did the gateway fire the default sequence flow twice?
-
Please have a look at both start events' configuration:
-
The top pool’s start event is being triggered every 2 hours
-
The bottom pool’s start event is being triggered every hour
-
(Also check the activities' time consumptions)
-
This means
-
that the first two process instances of the bottom pool reach the branching exclusive gateway before
-
the top pool’s first process instance completes the task "Condition is true"
-
and thus before it can write the new x into the data store "Another Database"
-
-
The first two process instances read from "Another database"
-
but they do not get any information for the variable x
-
because that data store has not been written to, yet
-
-
