QuEStSoftwareArchitecture
This article discusses how the QuESt codebase is designed and organized.
The design of the QuESt GUI application is loosely based on the model-view-controller (MVC) or model-view-adapter (MVA) software architectural patterns.
The model layer consists of "pure Python" systems in the QuESt codebase that work with data, such as:
- Optimizers
- Data downloaders
- Data file readers
Generally speaking, these are systems that can be used independently from the GUI application for standalone functionality.
The QuESt application GUI can be considered the view layer. The GUI is used to interact with model layer systems.
Controller layer systems interface the application GUI with model layer systems. Examples include:
- Optimizer handlers
- Data manager
- Data management systems
QuESt is designed using object-oriented programming.
QuESt was built upon using optimization problems to tackle energy storage valuation. The earliest such optimization problem was used in what became known as QuESt Valuation. The problem, although having many similar variations, was determined to be easily modularized. The idea of class design was to have a single class handle multiple variations of a certain flavor of optimization problems - value stacking in ISO/RTO electricity market. Variations of the problem included different market areas and different value stacks while the majority of parameters could be shared across all flavors of the problem.
Optimizer models are those derived from an abstract base class, Optimizer. This blueprint lays out a skeleton for creating derived classes that describe more specific optimization problems. Additionally, the Optimizer base class passes common functionality to its derived classes via inheritance. The end result is the Optimizer family of Python classes that abstract away the details of optimization modeling in Pyomo while providing well-defined interfaces for users to interact with the encapsulated models.
See the full Optimizer article.
In addition to code, contributions to the QuESt software should include docstrings and commenting, documentation, and unit tests for continuous integration.
This software uses the NumPy docstring style.
See also: https://www.sphinx-doc.org/en/master/usage/extensions/example_numpy.html
This project uses Sphinx to generate/render documentation. The QuESt application GUI is not intended to require manuals or documentation; however, the API/library portion of QuESt should be covered in the documentation.
Documentation pages are written in reStructuredText (RST).
See also: https://www.sphinx-doc.org/en/stable/usage/restructuredtext/index.html
Unit tests are used to test the library functionality of QuESt. Currently, there are no plans to do unit testing for the application GUI.
The unit tests are written using the unittest module in Python.
Continuous integration (CI) for the repository is set up for TravisCI. The configuration uses test discovery for the entire repository.