Albert Schaffer

Use Cases

“As a researcher, I want to visualize full time trajectories from the DEVS-Suite simulator stored on my computer so that I can better understand my simulation results”

“As a researcher, I want to visualize time trajectories for individual inputs, outputs, and states so that I can see how these data types change during a simulation scenario”

“As a researcher, I want to visualize superdense time so that I can clearly see changes in data for a given time instance at which multiple data transitions occur”

Requirements

-- Program must use data from a Postgres database with data generated by DEVS-Suite.

-- User must easily be able to choose databases and select simulation scenarios.

-- For a given model and simulation scenario, for one or more components, the user must be able to select any number of inputs, outputs, or states to visualize.

-- Program must produce individual time trajectories for each of the selected data types. Time trajectories should be vertically stackable.

-- Program must visualize superdense time.

-- Zoom feature should be integrated into the time trajectory visualizations. This is especially important considering that thousands to many millions of data points could be plotted.

-- Program should be designed for future integration into DEVS-Suite.

Program Design

This program was designed as a Model-View-Controller (MVC) application, where:

-- The model consists of the data structures that hold the data, as well as business logic to pull data from the database.

-- The view consists of all UI elements, developed in JavaFX.

-- The controller calls business layer methods based on user input.

Below are two design approaches that I considered when developing the program. I ultimately went with Approach 1 as it was faster and easier to implement, though Approach 2 would allow for more efficient data manipulation.

Data Structure Design

The next step was to figure out how to store the data from the Postgres database. This problem took me a long time to solve since I needed to learn about how relational databases worked. The below images show how my understanding of the data structure evolved over time, and eventually I found the best way to store the data.

This process reflected one of the challenges I faced in this project, which was that I initially struggled to understand the requirements and design constraints my professor, Dr Sarjoughian, laid out. In particular, the data structure Approaches 1 and 2 fail to take into account the database structure and the relationships that exist between the Postgres tables. In Approaches 3 and 4, the data structures better reflect the database structure, but did not accurately store superdense time.

Finally, the correct approach was reached in Approach 5, which I named JoinedDataModel because I used SQL JOINS to collect the data. In the UML diagram, the piecewise constant data (stateData) and event-based data (inputData and outputData) are easily distinguishable.

User Flow

To meet the requirements my professor and I set, I needed to ensure that the user flow to select the database to view was similar to the model configuration user flow in DEVS-Suite.

UI Design

I created several wireframes to find the best way to implement the user flow. Like the data structure design, the wireframes evolved as I understood the DEVS-Suite user flow and the requirements better. I also include DEVS-Suite’s UI for reference.

The initial design had the user select from an unorganized list of all inputs, outputs, state data, and rows, but did not take into account the various models that are being run in the simulator due to a lack of understanding of DEVS-Suite itself and how data was stored in the database. I realized that model_string could be used to let users choose individual components from models, but my next solution still forced users to choose components in an unorganized list.

At this point, I took into account how DEVS-Suite lets users track simulator data. In DEVS-Suite, the user can select individual models to simulate, then select components to track. My final solution reflects a similar user flow to let the user select component data to visualize. The database selection and model selection pages in the data visualizer app reflect the model configuration and component tracking pages in DEVS-Suite, respectively, to ensure a similar user flow between the two applications. This allows DEVS-Suite users to easily learn and use the visualizer because the UIs between the two apps are similar.