QM - Design

This page presents the main ideas for the design of the QM. However, the page where ideas are discussed and evolve is on the Open-DO Forge »

Main concepts:

The Qualifying Machine (QM) at its core is a process manager. It handles two main “concepts”: artifacts and traceability links. An Artifact is an “atomic” component of your project: a requirement, piece of a document, test case, test result... A Traceability Link is a link from one or several artifact to one or several artifacts and keeps track of already performed activities (actions performed by a human or a tool). For example, deriving a requirement into three test cases, is in fact the execution of three times the activity “Write a test case for this requirement”, and leads to three traceability links from the test cases to the requirement. Note that an activity that does not produce any artifact is not considered an activity (and can be safely removed from your process anyway, as this means the activity produces nothing !). The traceability links may also have dependencies, some kind of “In context of” links. For example, if you’ve written your test case according to some plans or coding standard, then your traceability links will be completed with dependency links to those documents. Dependencies are very important when running a test case for example: the traceability link that exists between the test result and the test case will have a strong dependency link to the execution environment for example (what version of the software is under test, what OS it’s running on and so on).

The role of the QM:

Retrieving the artifacts and links:

The whole point of the QM is to retrieve all artifacts that are part of your project and automatically calculate all traceability/dependency links according to a model that describes this project. This allows the user to organize its files as he wishes on its filesystem without using any external database, the rational being that too often databases get de-synchronized with the actual data, and it’s very hard to re-use/extract the necessary information stored in a database. Using a filesystem-based storage also means a more natural interaction with external tools (very often file based), and offers a natural place to store the QM’s metadatas (as subdirectories of the artifacts). For now, the QM can only retrieve artifacts that have the following properties:
  • each artifact is placed has its own directory
  • each artifact contains one or several files
  • the links are calculated using hierarchical and naming conventions on directories.
  • the above property also implies that the artifact hierarchy is a pure tree.
Those rules already allow a great deal of flexibility while keeping the project’s organization easily maintainable by humans. However, some complex projects will require a more flexible approach, and we’re currently working on a more flexible scheme that should allow:
  • retrieving artifacts that are part of a set of files (for example a set of functions in source code, part of a model)
  • retrieving artifacts that are owned by a software (DOORS requirements, simulink models) and are retrieved using plugins in this software.
  • expressing more complex traceability relationship.
  • allowing a more general oriented graph hierarchy of artifacts

Impact analysis:

From this set of artifacts and links, and by storing simple metadata informations, the QM can also verify if your project is coherent: If you modify a requirement for example, then you need to verify that your test cases can still test properly the requirement, and amend/complete them as required. The QM will point you to the artifacts that might need a review because of changes in other artifacts. This is called “impact analysis”. Now the interesting part is that some activities can be fully automated (for example running a test, producing a PDF from wiki-like documents, etc.). Using the impact analysis above, the QM can then automatically re-produce artifacts by using those automated activities when possible.


So that’s pretty it concerning the goals of the QM. To summarize, the QM: * Retrieves artifacts from a raw filesystem structure by using a metamodel that describes this organisation. * From the metamodel, calculates the traceability and dependency links * Calculates on-the-fly the signature of the content of the artifacts, and for each artifact check the last “valid state” with its environment to provide impact analysis * Uses scripts to automate some activities.

Technical design:

Now technically speaking, the QM is composed of two main parts:
  • An Ada/python backend embedding a web server
  • A Javascript client used as GUI

The Server:

The server is composed of a core written in Ada, that is responsible for storing the objects (artifacts, links, activities), provide some services (native support for GIT for example), and expose the python classes that will be used to script it (artifacts, links and activities). The Artifacts are the containers that contain the user data. The Links are used to retrieve all artifacts recursively, by moving from one link to another using naming conventions (only kind of link available for now). The Activities are used to create an artifact by executing some external tools. All three objects will be user-customizable via Python (in the current version only Activities can be customized, but there is on ongoing work to also be able to customize artifacts content and links) When started, the server is starting an interactive python session so that python commands can directly be entered via the console. The QM also accepts scripts as input so that qualification material can be automatically re-generated overnight for example.

The Client:

The Server is embedding an HTTP server that can serve the Client to a browser. The Client is a web page that allows the user:
  • To see the content of its project, organized by links
  • To see the result of the impact analysis
  • To validate an artifact (e.g. tell the QM that the content is correct in the current context, and commit it)
  • To execute the automated activities
  • To manually create artifacts (manual activities) and to some extent modify it.

More description to come:

This technical design description is obviously not complete yet, and more needs to be written on the subject.

Stay tuned for updates on the forge wiki: Open-DO Forge » !!


We have created some mockups as a basis for the on-going GUI design. If you want to see what the QM will look like in the near future, you can have a look at those by following this link.

  • Categories

  • Open-DO Projects

  • Contact

    info @ open-do.org