Automated Math Spec Framework
This project aims to build software capable of quickly generating mathematical specifications of complex systems. Eventual goal is for it to be capable of defining a schema for instantiating a mathematical specification base which then through multiple convenience functions and potentially application based interfaces be able to generate different pieces of the mathematical specification.
Project Planning
Project Vision
- Summary: A library which aids in automatically creating mathematical specifications based upon a schema written in python files
- Version History: The library would allow for version history because one would create a repo for each mathematical specification and then changes would be tracked by git
- Modular: The library allows re-use of elements so that a change only needs to be done in one place for types, mechanisms, etc and then it is pushed through the document
- Dynamic:
- HTML/PDF Reporting: The reports can be customized for different views such as picking only a selection of behavioral actions to map all the chains of or instead creating a report based on only one user and their own actions, etc.
- Web App: Sean has experience writing React front-end/Flask Back End/Docker Containerized apps and could create an app for reflection of the spec as well as more dynamic visuals
- Consistent: The library should be consistent with the GDS/cadCAD
- Component in a Suite of Tools: This tool should be part of a larger suite of tools below…
If we were working on a model of an airport queue model
Tech R&D |
Example |
Math Spec Mapping Library |
Specification of the airport queue model states, actions, parameters, etc. |
cadCAD 1.0 |
cadCAD model of the airport queue |
|
Backend of real data and any infrastructure key for setting up the digital twin |
Digital Twin Framework |
Airport queue model with |
Current Version
- Github repository: https://github.com/SeanMcOwen/MathSpecMapping
- Current version can handle most of the basics such as parameters, states, actions
- There is some html reporting basics created
- The current actions are defined as:
- Policy: Logic blocks which define out the policies in the system and are also modular to allow for policy options parts which define out what implementations could fit where
- Mechanisms: The blocks which do any state updates, instead of having policies update we use mechanisms to denote times where increasing funds somewhere might require also incrementing other accounts such as an account in the treasury or something. This is so that if in the future a tracking variable were to be added or something the mechanism is all that would need to be updated instead of every place where a certain variable is incremented
- This current version can be thought of a proof of concept/alpha version that will have heavy revisions
Project Phases
Phase 0 - Foundational Review: Review of past work, wrangling of the vision of the project
Phase 1 - Definitions and Scaffold: Building the scaffold of the product
Phase 2 - Minimum Viable Product/Beta: Revision of the library and creation of the working example of the airport queue model
Phase 3 - Stakeholder Review + Testing: Period of testing the use of the library with stakeholders to fine tune
Phase 4 - V1: Implementation of fine tuning and revisions, culminating in the official launch of the library
Phase 5 - Continued Development: Phase for further developing
Phase 0 - Foundational Review
Begin Defining JSON Schema
UI/Wireframe
Review Background Materials
Proof of Concept Modeling
Phase 1 - Definitions and Scaffold
Phase 2 - Minimum Viable Product/Beta
Phase 3 - Stakeholder Review + Testing
Phase 4 - V1
Phase 5 - Continued Development