Generate all the Things! Visit our website to see all of the currently generated artifacts.

1. What is Drasil?
2. Quick Start
3. Building Specific Examples
4. Running the Example(s)
5. Finding / Building the Haddock Documentation
6. Repository Contents

For well understood domains, building software ought to be a matter of engineering, based on solid scientific foundations. The ultimate test of "well understood" is being able to teach the domain language to a computer. Drasil is a framework for generating all of the software artifacts for (well understood) research software, from the natural knowledge base of the domain.

We take advantage of the inherent duplication of knowledge present in software artifacts (code, specification, tests, etc). More precisely, we capture the information present in software artifacts so that the particular view of that information in the artifacts can be reproduced by Drasil. For example, the equation F = ma will look different when rendered in documentation and in Java or Python, although it will mean the same thing. In this way, we obtain traceability: we know the exact relationship between information in the specification document and in the code and, furthermore, we know that they are coherent by construction.

Drasil is based on a combination of the following ideas:

1. domain knowledge changes very slowly
2. software in well-understood domains can be programmatically assembled from existing knowledge
3. the various artifacts that make up software are different views on the same knowledge
4. the most important information in crafting software are the design decisions and their rationale
5. a lot of software lives for a very long time (10+ years, often as long as 40 years), which needs a different approach

To better understand the requirements for Drasil, we follow an example-driven approach, based on a set of case studies. This is akin to test-driven engineering but at the system level. The currently generated examples serve as a good introduction to what we mean.

We wrote a position paper detailing our original ideas - but this is getting somewhat obsolete now. You can also take a look at a poster. For more information on the details of Drasil, please see the Drasil Wiki. A collection of Drasil-related papers can be found here. To contribute to this project, visit the Contributor's Guide.

Start by installing the build tools as directed in New Workspace Setup. For a minimal setup, follow everything up to Optional Utilities.

After this, you can:

1. Run stack setup while in ./code/
   • Remember to change your working directory to ./code/ first
   • Use cd to change working directory, pwd to print your current working directory
   • Refer to File Directory for further help regarding file directory commands
   • e.g. ./Users/.../GitHub/Drasil/code (on MacOS)
2. Use the basic make command to build Drasil and run all examples.
   • Run make help for a list of available commands.
   • Note that when building the examples, Drasil will output some "errors" in the terminal log. These are expected consequences of current development, and as long as the process finishes successfully you shouldn't be concerned.
   • Warning: this entire process takes around 10-15 minutes to complete (MacOS estimate)
3. You can find the generated output in the build folder that appears in the ./code/ folder. Each example will have its own subdirectory.

Simply run: make argument to build and run the corresponding example, where argument is detailed below:

For more commands related to Drasil, use make help or check out the Makefile documentation.

Please note that if make has been used, the Software Requirements Specification (SRS) documents are already generated automatically and can be found in build. Automated testing can be done on these examples.

After building, you can run the examples by using stack exec NAME where NAME is detailed below:

This runs the examples manually from the .stack-work folder after building, and the generated docs will appear in this folder (i.e. in the SRS folders). Due to this placement, these generated versions will not be subject to automated tests. The tex files are generated, but they are not automatically compiled. To compile the tex files, use the generated Makefile (in the same folder as the tex file).

You can run make docs from the ./code/ folder to build the documentation. Note: this process can take about 10-12 minutes (MacOS estimate).

See the README in ./code/ for more information.

Please use our provided CITATION.cff file for our preferred citation information. GitHub provides an export of it in BibTeX and APA if needed.

Please note that we only add to our CITATION.cff/preferred citation file on a consensual basis. If you would like your name added, please submit a PR with your information added to the CITATION.cff file.

code

• The main folder for Drasil source code and example implementations

doc

• Documents related to Drasil (contains the Contributor's Test)

notes

• Assorted general/administrative notes

Papers

• Subdirectory for papers related to Drasil framework, GOOL

People

• Contains contributions specific to some contributors (not necessarily to be implemented in Drasil)

Presentations

• Presentations on Literate Scientific Software and Drasil

WindowsFix

• Contains registry files for adding and removing the autorun of the command chcp 65001. This is to fix an issue with unicode characters. ONLY affects Windows machines.

.gitattributes

• Used by git (set language attributes so GitHub Linguist calculates code statistics as desired)

.gitignore

• Used by git (specifies which file(type)s to ignore when committing)

CITATION.cff

• Used to cite Drasil

LICENSE

• License information

README.md

• This file