The design will be based on the needs of the case studies (WP6) using use cases. This task starts at the start of the project and will result in a first draft of the design document in the first month. During the design of the component tools, the design document is updated and this task will resolve any interoperability issues.
The document reflects only the views of the author and the Community is not responsible for any use that may be made of the information it contains. This is an important part of the application, but it can also support other models and tools as long as they follow Spine Toolbox conventions or there is a translator between the application and the external tool. One of the conventions is the Spine data structure, which is an entity-relationship data model for structured yet flexible data storage.
This first version of this deliverable is expected in M02 of the project and the final version is expected in M30.
Introduction
Case Study The Spine project has 13 case studies that help improve, validate and implement various aspects of the Spine Model and Spine Toolbox. Spine Model is an energy system model and is not called a 'model' in software architecture context. Spine data structure The spine data structure defines the format for storing and moving data in the Spine Toolbox.
Spine data structures can be manipulated and visualized within Spine Toolbox, while Spine Model can use and export them directly. Spine Model An interpreter, which formulates a solver-ready mixed-integer optimization problem based on the input data and the equations defined in the Spine Model. A tool object contains a reference to the model code, external program that executes the code, and input data (eg, files) that the model code requires.
Together, the use cases are used to test the functionality and stability of Spine Toolbox and Spine Model under various possible circumstances.
System Overview
- Description of Main Building Blocks
- Contructing Modelling Tasks from Building Blocks
- Execution of Tools
- Viewing and Editing Project Data
The display process can be automated so that Spine Toolbox displays the results of the tool after running the tool. The output scenario is consequently a child scenario of the input and the tool in question. Model inputs are collected in databases that can be filtered to select only parts of the data.
One of the main features of Spine Toolbox is the ability to run different energy system models. Since one of the requirements for the Spine Toolbox is compatibility with a large number of different models, we chose the subprocess option. The Spine Toolbox's responsibility is to create an instance of the tool (shown as a blue toolbox) that can be submitted to a subprocess for execution.
The data store block represents some or all of the data in a project in the Spine data structure format.
Spine Toolbox Use Cases
- Manage Project Use Case
- Generate Data Collections Use Case
- Execute Project Use Case
- Manage Output Data Use Case
- Set Up New Tool Use Case
The system opens a view where the user can browse his local folders or network folders. The user navigates to the project file location he/she wants to open and clicks 'Open' or double-clicks the file. The system closes the file browser view, loads the project, sets the project settings, and displays the main application view.
The main view of the application shows the project canvas, which contains the data collections, tools, manipulators and data stores that have been stored in the project. An example of a window where the user can manage or view data might look like the data store view shown in Figure 5. Note: a window like this also opens when the user selects a database and clicks "view data" .
When the user is satisfied with the data collection, he/she clicks "End data collection". If the user is satisfied with the data collection, he/she clicks "End data collection". Summary The user wants to use a calculation tool to create a set of results from collections of input data.
Optional: User clicks 'validate project' to check whether the processing tools in the project have valid input data or whether there are errors in the combination of data sets. Optional: The user selects a processing tool icon and clicks 'validate' to check whether that processing tool has valid input data available in the project. The entire project will be executed, or by b) Selecting a part of the project from the project canvas and clicking 'execute'.
Note: For the validation of input data to work, the processing tool must be configured in a way that this information is available to the project. When a user adds a new tool block on the project canvas, the new external model is now available.
Requirements, Assumptions, Dependencies, and Constraints
Functional Requirements
- UI Requirements
- Data Management Requirements
- Project Execution Requirements
The application must check if it can read the data collection in the Spine data structure format. Placing data collections in a hierarchy so that a higher-level data collection includes lower-level data collections (Tree structure, i.e., parent-child relationship). Finally, the user selects the number of data sets to generate and starts the process.
The most obvious example is comparing the input datasets of two or more scenarios (our result). If this database is then connected to the tool, it is converted to the Spine data structure format on the fly when its runtime script task is executed. However, a database can also have a property where it stores the database in a Spine data structure file.
In this case, the Spine data structure would only be created from the resources when the database is marked for re-reading (or a better word would be re-execution - reading data from the resources is a task after all). The user wants to specify the specifics of this scenario (i.e. the user wants to select a set. This can be done by collecting the desired data from various data sources into a data store block that is stored as a Spine data structure.
Create derived scenarios by combining a base scenario with databases that define sensitivities (changes to the base scenario) using recipes. When there is room for new tasks, the application also assigns them. A particular computer naturally has its own resources available, but external resources can also be specified by assigning appropriate handles to file systems and computing units.
Preferably, this should include some sort of activation button so that the user can design changes without actually forcing the changes before the activation is triggered.
Non-functional Requirements
- Implementation Language and Dependencies
- Coding Style
- Versioning, Version Control and Deployment
- Security and Testing Requirements
The problem with the GPL v3 license is that if we develop Spine Toolbox with a library that is released under a GPL license, then all derivatives of that work must also be released under a GPL license. The latest (as of November 2017) PySide2 version is 5.9 and the Spine Toolbox implementation will start with it. These reasons, in addition to the thousands of online users who form a supportive community, make a very compelling case for choosing PySide2 for Spine Toolbox development.
In order to meet all the requested features of the Spine Toolbox in the allotted time, we need to use other open source python packages in addition to Pyside2. Windows XP is no longer supported in Python 3.5+, so Spine Toolbox does not support it. Every time enough progress is made to warrant a new version, the application will be deployed.
That is, there will be an installation package released for Windows, which contains Spine Toolbox application and all its dependencies (including Python). In the fall of 2018, the source codes will be released to the public by transferring them to a web-based Git version control repository hosting service. These tools allow the users and developers of Spine Toolbox to report bugs and request new features and in addition, they allow Spine members and project management to follow the progress of the implementation.
Spine Toolbox aims to follow the guidelines set out in the document Certification Requirements for Windows Desktop Apps10. While the Spine Toolbox will be cross-platform, the document has sections that are general enough to be applicable to Linux and Macintosh app development as well. This section will be updated when more information is available about the type of data Spine Toolbox will process and where the data is stored.
Spine Toolbox developers will write unit tests for the application that will be included in the application source code. However, core components will undergo rigorous testing to ensure that Spine Toolbox core features remain reliable even as new features are continually added.
System Architecture
- Model Classes
- View Classes
- Controller Classes
- Design for Tool Execution
Separating the model (data) from the view and controller components allows multiple views of the same model. If the user changes the model via the controller of one view, all other views that depend on this data must reflect the change. The views in turn retrieve new data from the model and update their displayed information.
The basic idea of the observer pattern can be summarized as in Figure 11, where the observer isolates the model from referencing the views directly. The primary advantage of MVC is that it makes model classes reusable without modification. In some applications the controller and the view are the same object, but in this project we aim to keep them separate.
The following subsections present the main classes of Spine Toolbox, divided into model, view, and controller modules. The rest of the sub-chapters in this chapter present the designs of individual features in Spine Toolbox. MainForm class represents the view that is shown to the user when the application starts.
Other views inherit the QWidget class and are created and instantiated when the user chooses from the main window. This will likely evolve as new requirements and features are added to the design. The application creates an instance of a GAMSTool or a JuliaTool depending on the type of tool the user is trying to run.
The application creates an instance of a ToolInstance class, which knows the command to be executed and has a reference to the Sub-process instance. When the subprocess is finished, it sends a signal to the execution_finished() slot and notifies the user about this.
Spine Data Structure
