NOTE: This exercise assumes you have completed the previous exercise.
In this exercise we'll go over the design of our new project.
Table 1.1. Design Considerations
|Generic, Data-Driven Approach||We'll use a new node type called <WorkloadNode> to specify the scripts that perform the CPU and GPU compute workloads. The <WorkloadNode> object is able to specify the Scenome Scripting Language script and functions used to perform the workload, and the user is able to add <FileNode> objects as children in order to specify the source data for the workload. This allows the end user to specify the workloads without having to change the application's source code.|
|Scripted Plugins||We want to make sure that this design allows us to write Scenome Scripting Language code in a 'plugin style'. This means that we want the Octopus application to know as little about the workloads as possible, and we want to delegate that responsibility to the data contained in the documents. In order to accomplish this kind of extensibility, our design requires a little more work upfront. However, it will be worth it over the long term.|
|Don't Neglect Quality of Life Features||We need to make sure that we pay attention to quality of life features. For example: the ability to enable and disable workloads is very important, as is the ability to specify that the workload is in a debug state. Otherwise, it will be frustrating to try to modify code that executes workloads if you have to run all the workloads in the document. Similarly, we need a way to signal that the user wishes to run the workload in debug.|
|Pay Attention To Service Boundaries||Service boundaries are also very important. Without clear service boundaries, we run the risk of making the application know too much about the workloads, and we run the risk of making the scripts that implement the system know too much about each other. For any workload, the underlying script code should only know about the function call signature required for it to receive the workload data from the application. Otherwise, we run the risk of having changes to the application require changes to the workload scripts. With some changes or refactors, changes to the scripts that process the workloads will be unavoidable, but we want those cases to be rare.|
Now let's create a small 'to do' list for the project and discuss each element. It might be a good idea to write these items down so you can keep track of them as you work through the exercises. Or, you can refer to this document from time-to-time.
Table 1.2. To Do List
|Download Elevation Data||We will download elevation data from the United States Geological Survey website that we'll use as source data for our implementation.|
|Create New Scenome Application||We'll create a new Scenome application named Octopus.|
|app_octopus_create_document_scripts.ssl||This script is created when you create the Octopus application. It will contain code for creating new Octopus app projects.|
|app_octopus_create_document_util.ssl||This script is created when you create the Octopus application. It will contain code for that will be called from app_octopus_create_document_scripts.ssl.|
|app_octopus_scripts.ssl||This script is created when you create the Octopus application. It will contain code for Octopus app commands, such as the build command that will execute the GPU compute workload specified by whatever Octopus document is opened.|
|app_octopus_util.ssl||This script is created when you create the Octopus application. It will contain code for that will be called from app_octopus_scripts.ssl. For example: this library will contain most of the Octopus app build command that will remotely execute the workloads specified by the <WorkloadNode> objects in the project files.|
|app_octopus_workload_terrain_classes.ssl||This script is created when you create a new Octopus app project. This will contain orchestration code that manages the CPU and GPU compute jobs for the terrain analysis. It will call into three additional libraries that actually perform the work.|
|app_octopus_workload_terrain_util.ssl||This script is created when you create a new Octopus app project. This will contain orchestration code that manages the CPU and GPU compute jobs for the terrain analysis. It will call into three additional libraries that actually perform the work.|
|app_octopus_workload_terrain_classes.ssl||This script contains class definitions for objects that store inputs used by the build and outputs created by the build.|
|app_octopus_workload_terrain_cpu_image_processing_util.ssl||This script contains functions that perform CPU-side image processing tasks.|
|app_octopus_workload_terrain_gpu_image_processing_util.ssl||This script contains functions that perform GPU-side image processing tasks. The code in this script interfaces with OpenGL and executes the compute shaders that perform the GPU compute operations.|
|app_octopus_workload_terrain_report_util.ssl||This script contains functions that generate a small, single-page web application that allows the user to review the results of the terrain analysis.|
Finally, we'll discuss an initial service boundary design below. These are just guidelines that we can change if needed.
Table 1.3. Service Boundaries
|Document Create Scripts Group||
|Application Scripts Group||
|Terrain Analysis Orchestration Group||
|Terrain Analysis Workload Group||
This exercise is complete. Please proceed to the next exercise.