Prev Next

Tracking Property Parameter Values - Examples

To help you learn about the facility for generating information on property parameters from a simulation of a BPMN business process model, Sparx Systems provide two examples that you can explore in the EAExample model. These are the:

  • Fibonacci process - a very simple example to help you become familiar with the parameter tracking facilities
  • Car Repair process - a more complex example that you can manipulate to see how a real-life process might be investigated

At the end of this topic is a section that briefly discusses how you might work with an integer-based process containing parameters that are initialized by 'real' distributions, and a section describing the example of the behavior of the Time Parameters.

The Fibonacci Example

This is a very simple recursive business process that calculates a series of Fibonacci numbers through ten iterations; you can see how the property parameters increment in each iteration through the elements of the process. Open Example Model > Model Simulation > BPSim Models > Fibonacci.

The pseudocode of the process is shown in the Notes element on the diagram. The statement 'print(next)' will output the number series 2, 3, 5, 8, 13, 21, 34, 55, 89, 144.

The BPSim configuration for this process is set up as described here.



See also


On the 'Control' tab for the StartEvent element, set 'TriggerCount' to '1', and on the 'Properties' tab create and initialize the properties:

  • 'N' as '10'
  • 'first' as '1'
  • 'second' as '1'
  • 'n' as '0'


Now define the properties for each of the Activities in the process, on the 'Properties' tab. Note that the values for these properties are derived from Expressions, the components of which must be enclosed in braces - {xxx}. For the Activity:

  • next=first+second - set the property 'next' and define the value as the Expression {first} + {second}

  • first=second - set the property 'first' and define the value as the Expression {second}
  • second=next - set the property 'second' and define the value as the Expression {next}
  • n++ - set the property 'n' and define the value as the Expression {n} + 1
Using the Parameter Value Dialog The BPSim User Interface Components


Set the 'Condition' property parameters for the two Sequenceflow connectors issuing from the 'loopNode' Gateway element, on the 'Control' tab.

Expand the Gateway | loopNode element and for the link to:

  • next=first+second - set the Control parameter to 'Condition' and define the value as the Expression {n}<{N}

  • EndEvent1 - set the Control parameter to 'Condition' and define the value as the Expression {n}=>{N}


Having completed the configuration, click on the Run button on the Configure BPSim window and on the 'BPSim Simulation Controller' dialog, selecting a Standard simulation.

When the simulation is complete, click on the Attributes button.

On the 'BPSim PropertyParameter Values' dialog, set the 'Token number' field to '0' and click on the Query button.


Now examine the values of the 'next' property on entering the first=second Activity in each iteration of the simulation. Click on the 'Group by Property' tab and expand the 'next' item.

The list of values is long, so right-click on the column headers and select the 'Toggle Filter Bar' option. Under the 'Property' column heading, type 'first='. This filters the list to show only the property parameter values on entering the first=second Activity.

The Car Repair Example

This more complex example is based on a realistic model of a car repair process, where a number of individual customers request an estimate for repair and either proceed with the repair or decline to continue; you can see how the property parameters vary as different decisions are made during the process. Open Example Model > Model Simulation > BPSim Models > Car Repair Process.

The overall process is represented by this diagram:

The Repair Car Activity is a composite element that contains this sub process diagram:




In the Browser window, expand the 'BPSim' child Package underneath the 'Car Repair Process' Package, and double-click on the 'Scenario 1: Main Flow' Artifact. The Configure BPSim window displays. On the 'Scenario' tab look at the 'Duration' field; this has been set to 2 days and 12 hours (that is, 60 hours).


In the process hierarchy on the left of the window, expand the 'Start Event' category and click on 'Customer Arrives'. Select the 'Control' tab and look at the 'InterTriggerTimer' parameter, which has the value 24 minutes; that is, a customer arrives every 24 minutes (so over the 60 hour duration, 150 customers pass through the repair shop).

Each customer enters the repair shop with one or more issues to be evaluated and repaired. The number of issues each customer presents can be randomly generated using one of the Distributions supported by BPSim. As the issue number is counted in discrete units (rather than measured on a continuous scale) we would use an 'integer' distribution. If you select the 'Properties' tab for the 'Customer Arrives' Start Event, you will see that the 'noOfIssues' property value is initialized from a Poisson distribution with a mean of 3.


Now expand the decision Gateway 'Accepted?' and its connectors, in the process hierarchy. 'Initial Estimate Accepted' has a Control parameter 'Probability', set to 0.67. The alternative connector, 'Initial Estimate Not Accepted' has a similar Control parameter 'Probability' set to 0.33. That is, we expect an average of one issue in three to be withdrawn - or not pursued - by the customer.


Further into the process, when an issue is being assessed on the vehicle, there is a possibility of another issue being discovered.

In the list of Gateway elements, the last 'unnamed element' has two paths: 'New Issue Found' and 'No Added Issue Found'. Click on each of these and look at the 'Control' tab; the 'Probability' parameter for 'New Issue Found' is set to 0.25 and, for 'No Added Issue Found', to 0.75. So on average, for every four issues reported and assessed, one new one is discovered.

The 'New Issue Found' path takes the process to the 'Handle New Found Issue' Activity, which adds 1 to the number of issues to be processed for the current customer. Expand the Activity group, and click on the 'Handle New Found Issue' element and on the 'Property' tab. You will see that the property 'noOfIssues' here has the Expression value {noOfIssues} + 1.


When a problem with the vehicle is resolved, the 'Repair Issue' Activity deducts 1 from the number of issues to be repaired for the current customer. Click on the 'Repair Issue' element in the Activity group and on the 'Property' tab. You will see that the property 'noOfIssues' here has the Expression value {noOfIssues} - 1.


The value from the 'Repair Issue' Activity is tested at the 'Have Further Issues?' Gateway.

Click on the 'More Issues to Repair' connector and on the 'Control' tab; the Condition parameter for following this path is set to the Expression value {noOfIssues} > 0; flow passes to the Gateway prior to the 'Inspect for Issue' Activity.

Similarly, if you click on the 'No More Issues to Repair' connector and on the 'Control' tab, the Condition parameter for following that path is set to the Expression value {noOfIssues} =< 0, and flow passes to the 'Repairs Completed' End Event.

Now that you have examined the process flow and configuration settings, you can run a simulation and review the results.


On the Configure BPSim window, click on the Run button, and then on the 'BPSim Simulation Controller' dialog click again on the Run button, selecting the 'Standard' simulation (however, the type of simulation makes no difference for reviewing property parameters).

On the 'BPSim Simulation Controller' dialog, you can review the Token status (and see that an additional customer manages to enter the shop at the very last minute) but it is difficult to see exactly how this summary data resulted. Click on the Attributes button to obtain the detailed property parameter values information on the 'BPSim PropertyParameter Values' dialog.


On the left hand side of the dialog is a summary of the minimum and maximum values for the property parameter (attribute) for each element in the process. For example, for the 'Customer Arrives' element the 'noOfIssues' parameter has a minimum of 0 and a maximum of 8, as generated by the Poisson (3) distribution.

In the 'Token Number' field, type in a number (N) between 0 and 150 to select for the Nth customer who entered the repair shop. Click on the Query button to obtain the property parameter values used in the process for that customer. Review the results on each of the two tabs:

  • On the 'Group by Element' tab, see how the attribute's value changes in each element; for example, for customer 24 the 'noOfIssues' parameter is initialized with a value of 4 by the random distribution, and the 'Inspect for Issue' Activity is called six times with the parameter value being adjusted to 3 for three of those calls before cycling to 1, and the 'Handle New Found Issue' Activity is called twice with the parameter value at 3 both times
  • On the 'Group by Property' tab see how the parameter value changes as the process cycles through the Activities to completion, starting at 4, being adjusted between 3 and 4 a number of times and then decrementing to 0 at the end


Continue to explore the results as required, selecting different customers (Tokens). You can also return to the BPSim configuration and change the parameter initializations and add new ones, or change the decision points, to experiment with the process.

Responding to real numbers in the simulation of an integer-based process

In some cases, you might need to generate property parameter values using a distribution that returns 'real' numbers when the activities in the process operate with integers, or when you want to see what impact forcing integer values has on the process.

One mechanism to apply in such cases is to set conditions to avoid absolute numbers. So, for example, you might have a counter that decrements by 1, that is initialized to a 'real' number. If you set a condition to 'value==0' (equals 0) or 'value !=0' (does not equal 0), the two conditions might never be True or might always be True, respectively, causing an infinite loop. To avoid that, in the conditions you would use operators such as:

     'value > 0'

     'value < 0'

     'value >= 0'

     'value <= 0'

Another mechanism is to edit the code template used by the BPSim engine, to intercept and replace the real numbers provided to specific parameters with integers, as shown:

  1. Select the 'Develop > Source Code > Options > Edit Code Templates' ribbon option.
  2. In the Code Template Editor, in the 'Language' field, click on the drop-down arrow and select 'MDGBPSimExecutionEngineExtension'.
  3. In the list of (Java) templates, click on 'MDGBPSimExecutionEngineExtension Compute Value'. The template contents display in the 'Template' panel.
  4. Find this line:

         double %bpsimPropertyParameterName% = (double);

    Change it to:

         %if bpsimPropertyParameterName == "noOfIssues" or  bpsimPropertyParameterName == "noOfVisitors"%
         double %bpsimPropertyParameterName% = (int);
         //double %bpsimPropertyParameterName% = Math.ceil(;
         //double %bpsimPropertyParameterName% = Math.floor(;
         //double %bpsimPropertyParameterName% = Math.round(;
         double %bpsimPropertyParameterName% = (double);
  5. Replace the property parameter names with your own property parameters.
  6. Click on the Save button, close the Code Template Editor and reload the project.

As presented, for each specified parameter the code template will simply replace any 'real' number initialized by the distribution with an integer. If you prefer, you can use one of the commented lines instead:

  • Math.ceil() will take the 'real' number and convert it to the next highest integer
  • Math.floor() will take the 'real' number and convert it to the next lowest integer
  • Math.round() will take the 'real' number and round it up or down depending on whether it is greater than or less than n.5

Time Parameter Behavior

In the BPSim configuration, you can set a number of Time parameters for an Activity, such as Queue Time and Wait Time. You can also set a Result Request on each of these, for a Custom simulation. However, the BPSim simulation engine combines these parameters into a single 'Processing Time' quantity.

Consider the simple model TimeParameter in the Example Model (Example Model > Model Simulation > BPSim Models > Time Parameter), represented by this diagram:

Time Parameters, Business Process Simulation in Sparx Systems Enterprise Architect

If you double-click on the Artifact2 element, the Configure BPSim window displays. Click on the Activity1 element in the diagram to expand the Activity group, to select Activity1 in the hierarchy at the left of the dialog, and to display the first tab, 'Time', for the element in the configuration, as shown.

Note that in the upper panel there are seven system-supplied 'Time' parameters, which have been given initial values of - in order - 1, 2, 4, 8, 16, 32 and 64 minutes (the 64 minutes is 1 hour and 4 minutes). Note also that in the lower panel, each of these has a Result Request for the mean runtime value of the parameter.

Click on the Run button, and on the 'BPSim Simulation Controller' dialog click on the Run button and select 'Standard Simulation'. The simulation is configured to cycle through the process once. When the simulation is complete, click on the Open Result button, and on the 'BPMN Simulation Report View' right-click and select the 'Show Only Non-Empty Items' option. This gives you, for the Activity1 element on which the parameters were set, these results:

All of these derived results are 127 minutes, the sum of the initial values of the original seven 'Time' parameters. The individual parameters are not processed separately.

If you return to the 'BPSim Simulation Controller' dialog and click on the Run button, selecting 'Custom Simulation' this time, the Open Result button displays the 'BPMN Simulation Custom Report View'. In the configuration, the Result Requests were for the mean values of the seven parameters. In the Report View for the simulation, you only see the mean of the single aggregated parameter, ProcessingTime, as 127 minutes.