Drasil is a framework for generating all of the software artifacts from a stable knowledge base, focusing currently on scientific software. We welcome students and collaborators to assist us as we research optimal ways to extend Drasil's functionality.
Navigate to the Quick Start Guide to see what Drasil can do.
Workspace recommendations are available on the New Workspace Setup page.
If you are interested in contributing to the project, please look at the Contributor's Guide as well as the Workflow page.
If you are interested in creating your own project in Drasil, please look at the Creating Your Project in Drasil page.
Debugging information can be found on the Debugging in Drasil page.
Drasil is a framework for generating all of the software artifacts from a stable knowledge base, focusing currently on scientific software. The main goals are to reduce knowledge duplication and improve traceability. The artifacts are generated from a common knowledge-base using recipes written in a Domain-Specific Language (DSL). These recipes allow us to specify which pieces of knowledge should be used in which artifacts, how to transform them, and more. For more information on the design, documentation, usage, and specifics of Drasil, please visit the GitHub repository or the GitHub Wiki.
This webpage is designed to contain the most up-to-date case study artifacts, Haddock documentation, and Drasil analysis from the Drasil repository. The case study artifacts include the Software Requirements Specification (SRS) for each case study, which specifies what the program sets out to achieve. The Haddock Documentation section contains the current documentation for the Drasil framework. The package dependency graphs show the hierarchy of modules within each package.
The following is a list of artifacts that Drasil currently generates:
We hope to generate the following artifacts in the future:
As described in the Information Encoding wiki page, Drasil uses specific terminology to address types of knowledge for the purpose of encoding information, since we know that we want to eventually generate words, sentences, paragraphs, whole documents with headings, references, formulas, tables, graphs, and code. This is done by trying to understand the basic 'units' of all artifacts, and methods for composing larger structures from these units. The removal of duplicate units is an important feature of this methodology. The basic building blocks of the methodology include different expressions for units with a specific meaning. These are built into ontologies of domains that address broader knowledge. Chunks form a fundamental part of such ontologies.
As described in the Chunks wiki page, a chunk is a data type specialized in holding a specific type of information for a specific purpose so that knowledge may be used in generated models, definitions, and theories. Chunks are usually made up of several lower-level types that hold lower-lever information; when contained together, these pieces of lower-level information hold a new specific purpose. The structure of a chunk can be thought of as a wrapper of information, and this is all implemented using Haskell's record-type syntax. Recipes transform the acquired knowledge into a usable format.
As described in the Recipes wiki page, recipes are instructions that unpackage necessary information from chunks and send that information to Drasil generators/printers to build complete artifacts. When an artifact needs to be changed, the recipe is modified to unpackage the additional necessary information from a chunk, or alternatively to omit unpackaging information that is no longer required.
As described in the GOOL paper, this is a Generic Object-Oriented Language that provides intermediary assistance in code generation, allowing Drasil to more efficiently generate code in several languages, including Python, Java, C-Sharp, and C++.
A list of papers and documents written about Drasil can be found on the Drasil Papers and Documents wiki page. In particular, there is an Old Position paper outlining our original ideas, a Drasil poster, and a Well-Understood paper discussing key concepts.
The development of Drasil follows an example-driven approach, with a current focus on creating Software Requirement Specifications (SRS). More specifically, Drasil's knowledge of the domain of Physics has seen significant growth through the creation of these examples, ranging from mechanics to thermodynamics. Each of the case studies implemented in Drasil contains its own generated PDF and HTML reports, and in some cases, its own generated code to solve the problem defined in their respective SRS documents.
Drasil allows some design decisions to be made by the user when generating code. The table below summarizes the design decisions made for each case study, followed by a guide giving the meaning of the short-forms used in the table:
| Case Study | Modularity | Implementation Type | Logging | Input Structure | Constant Structure | Constant Representation | Real Number Representation |
|---|---|---|---|---|---|---|---|
| DblPend | M | P | NoL | U | B | C | D |
| GlassBR | M | P | L | B | I | C | D |
| SWHSNoPCM | M | P | NoL | U | B | C | D |
| PDController | M | P | NoL | U | B | C | D |
| Projectile_U_P_NoL_U_WI_V_D | U | P | NoL | U | WI | V | D |
| Projectile_M_P_NoL_B_U_V_D | M | P | NoL | B | U | V | D |
| Projectile_M_L_NoL_U_U_V_F | M | L | NoL | U | U | V | F |
| Projectile_U_P_L_B_B_C_D | U | P | L | B | B | C | D |
| Projectile_U_P_L_B_WI_V_F | U | P | L | B | WI | V | F |
The legend for the Case Studies Table is listed below according to the column header:
Drasil's framework is primarily written in Haskell, so we use Haddock to document our code. The following link will take you to the current Haddock documentation for the Drasil framework. A variant with fully exposed modules is also available.
This section contains graphs and tables that may be used to analyze the structure of the Drasil framework. Here, we will explore the relationship between data types, classes, and instances of those classes within Drasil, as well as the structure of individual Drasil packages.
This Data Table is generated by Drasil to keep track of all the different types, classes, and where they intersect through instances. The rows are organized in order of Drasil packages, modules, and data types. The data types are further separated by their composition; those labelled Data Type are completely new types created and used in Drasil, while Newtype Types are type synonyms. All of the classes in Drasil are defined as column headers, starting from Haskell-native classes like Eq and going through every unique Drasil-defined class. A box marked with 'YYYY' symbolizes the file location of where that particular data type is an instance of a particular class. There is also a downloadable version of the Data Table available as a .csv file.
The following Table of Type and Class Instance Graphs is another artifact generated by Drasil. The type graphs explore the dependency of data types upon each other. These graphs include record-defined types, newtype wrappers, and data types built from other types. For these graphs, a node with a black outline signifies that the type is not defined in that package, but is still used in the creation of other types (this includes Haskell-native types since we do not redefine those). A red outline signifies that the type was created using Haskell's 'type' syntax, while dark green means the type was made using 'newtype' syntax. A purple border shows that the type uses constructor syntax and cyan is used for types written with record syntax. The arrow starts from the base types at the tip and follows through so that dependent types are placed at the tail. Usually, this means that those types at the tail may contain the type at the tip of the arrow.
The class instance graphs aim to look at the structure of classes, data types, and the interactions between those two. Specifically, each arrow represents the given type as an instance of a given class. The tip of the arrow points to the class, and the tail specifies the type that is an instance of the tip's class. For clarity in analyzing the structure, classes defined in the graph's package are coloured magenta, classes that are used but not defined in the package are rendered pink (including Haskell-native classes), and data types are rendered with a turquoise border.
Type Graphs
The below list contains all of the different packages used to build the Drasil Framework. Each package and its dependencies are displayed in the form of a graph, with the tail of the arrow being the dependent module, and the tip of the arrow being the base module. In other words, the tip builds off of (or relies on) the tail to work. Links are available to a PDF version of each package's dependency graph at the bottom. For example, the graph for the website package is shown below. Each section is made from different modules that come together under the Drasil.Website.Body module and then are generated by Drasil.Website.Main. This result shows that the package structure has a pyramid-like hierarchy.
The graph displayed below shows the dependencies between the packages used to build the Drasil Framework.
