Model Design Patterns

1. Submodel Stack

---

Submodel Stack

A submodel is simply a term used to define a model that has been executed by another model. This parent model will have a connection to the submodel within one of its actions. When the action is executed, the submodel is added to a stack of models that are currently active within the execution. When the submodel connects to the Exit state, the submodel is then removed from the stack of existing models within this execution, and returns to the parent model to continue.

Note: A model cannot be added to a stack if it already exists in the stack within DAI’s current functionality.

Why should we use submodels?

The use of submodels within the Eggplant ecosystem solves a handful of functional and workflow-related issues:

1. Simultaneous Contributions
   
In its current state, the Eggplant Designer does not allow multiple people to work on a model at the same time. If two individuals attempt to make changes to an existing model, the first person to do so would have their changes written to the underlying database and saved. Once this occurs, the other individual is effectively looking at an old version of the model. Any attempts to modify the model will be met with an error message stating that changes cannot be saved and the user needs to refresh their browser in order to view the latest version of the model.


2. Easier to Read and Maintain

   The concept of keeping things simple and easier for others to read, maintain, and enhance is one that spans all of programming, but also other industries and skillsets. It is demonstrably easier to understand a model’s purpose and complexity when it’s smaller and centralized around a specific feature or function of your targeted system. As you can imagine, you may find it difficult to track down the usage of a model’s variable when there are hundreds—or thousands—of nodes.


3. Feature-Focused Testing

   At its core, a model execution should be about exploratory execution and testing of your system. That is the strength of the modeler and the primary purpose one should be leveraging it within their testing library. With that said, if you were to make changes to an existing monolithic design and then attempted to execute the model to ensure your changes accurately reflect any necessary testing- and business-logic, you could be there for days waiting on the system to find its way down to your additions. However, if you extract the functionality into its own model (and design your model according to best practices), you can forego testing from the parent model and execute from the feature-specific submodel instead, resulting in a much higher possibility of executions that test your additions.
 Again, this will require that you conform to existing best practices around model design and ensure your model can be executed both independently and as part of a larger system of models. The latest information around this process is outlined in another section within our wiki.