A Module Example

Imagine you're building a business model for an airline. The causal loop diagram for the model (the “dynamic hypothesis”) might look like this:

This is the top level of the model, which is comprised of five modules (Customers, Fleet, Reputation, Quality, and Service). The connectors between modules indicate how values flow from one module to another. In the example, you can see that variable values flow in both directions between the Customers and Fleet modules; however, variable values flow only in one direction from the Quality to Reputation modules, and from the Reputation to Customers modules. Similarly, the connectors show you that there is no direct connection between the Service and Customers modules.

You develop each underlying module as a separate model. This is what the “Customers” (customer acquisition) module might look like:

Note that this module depends on several inputs from elsewhere in the model and won't be able to run until those inputs are assigned. The unassigned module inputs are indicated visually by a double-thick border for their variable icons and a bold font for their labels:

plane overcrowding factor
Reputation
Average Service Quality
drop price sw

When these module inputs are assigned to variables elsewhere in the model, the module will be fully defined and able to simulate as it stands in isolation.

Notice that the previously unassigned module inputs are now named this way:

Fleet.plane overcrowding factor
Reputation.Reputation
Quality.Average Service Quality
Quality.drop price sw

The part of the name before the period indicates the module where the variable is defined (here, “Fleet”, “Reputation”, and “Quality”). The part of the name after the period indicates the variable’s actual name, as defined in the module where the variable is defined (like “plane overcrowding factor” or “Average Service Quality”). Notice that the assigned module inputs are now indicated visually by italics on the variable’s label, and a double-thick gray border for the variable’s icon.

This module also contains a variable that's defined as a module output (remember that the Customers module had connectors indicating that it had inputs and outputs to both the Fleet and Quality modules). In the Customers module, the “Customers” variable is defined as an output. Outputs are indicated visually by a double-line border (which looks like an O in converters and flows). The name for outputs appears in a regular font.

Now, let’s look at the Quality module, which tracks service quality. This is the way the module looks after the module inputs have been assigned:

In this module, there are two module inputs (“Customers.Customers” and “Service.Service Capacity”) and four module outputs ("drop price sw", “Average Service Quality”, "Service Quality", and “normal service quality”).

Module inputs can be assigned to:

Variables that are directly connected to this module with an incoming connector.
Variables that are defined as module outputs in any module that is connected to this module via an incoming connector.
Variables defined as module outputs in any submodule that has a connector into the module input.

If you look back at the top-level of the module, you'll see that the Customers and Service modules are both connected to the Quality module via incoming connectors, so module outputs from both of those modules are available to be assigned as inputs to the Quality module.