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, useage, 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 shows the hierarchy of modules within each package.
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 contain their own generated PDF and HTML reports, and in some cases, their 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 |
|---|---|---|---|---|---|---|---|
| GlassBR | S | P | L | B | I | C | D |
| NoPCM | C | P | NoL | U | B | C | D |
| PD Controller | C | P | NoL | U | B | C | D |
| Projectile_U_P_NoL_U_WI_V_D | U | P | NoL | U | WI | V | D |
| Projectile_C_P_NoL_B_U_V_D | C | P | NoL | B | U | V | D |
| Projectile_S_L_NoL_U_U_V_F | S | 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 column header:
Drasil's framework is primariliy 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 an 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 other types. For these graphs, a node with a black outline signifies that the type is not defined in that package, but 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 (includes 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.
