Project Structure

HeikoKlare edited this page Dec 1, 2016 · 4 revisions

Table of Contents

Project Architecture

The Vitruv project consists of several modules that build on each other. All modules are explained in more detail in the following. In short, the modules are structured as follows:

The essential building block is the framework on which all other modules depend and which defines how a virtual model is created and how the automated consistency mechanisms work. Extensions extend the framework by further functionality that is required by certain domains or applications. DSLs provide specific languages for defining consistency specifications between two metamodels (domains). A domain represents essential information for a specific metamodel and an application contains the consistency specification between two metamodel. Views define the views by which models can be modified. An orthogonal module is the Build, which defines the structure of the project for the build and continuous integration environment.

The relations of the different module are displayed in the graphics below.


The framework consists of the central elements for defining a virtual single underlying model (VSUM) and provides extension points for the different domains and applications to be used with the framework.


Extensions extend the framework with new functionality and can be used by different domains and applications.

  • It depends on the used domains and applications if an extensions is required.
  • There are DSL extensions that are always required if the consistency specification in an application is written with a DSL.


The provided DSLs can be used to specify consistency-restoring transformations between exactly two different domains. They generate code that is used to extend the framework for keeping instancens of a specific pair of models consistent. These consistency specifications are used by an application that defines the relationship and consistency between two metamodels.

  • DSLs are only needed for developing applications, not for executing them. Thus, a user of Vitruv with an existing consistency specification does not need the DSLs.
  • DSLs depend on DSL extensions that are required both during developmend and during runtime.


A domain defines the necessary concepts for one metamodel. It defines the metamodel namespaces a domain consists of, defines utilities specific for this metamodel and defines the way in which editors for this metamodel are watched for changes.


An application is defined for a pair of domains. It essentially consists of the consistency-restoring transformations that keep model instances of these two domains consistent. It can also define further features for the domains, e.g. the integration of existing models.

    • Applications can be defined using the provided DSLs.
    • Applications depend on exactly two domains.
    • Applications are built on top of the framework. Therefore, they are developed in separate projects. You can find them on the vitruv-tools landing page:


A view is defined for a single or a set of domains. It specifies a specifiy view on the models, e.g. a UML class diagram view on Java code.


Build projects define features of the Vitruv project and information for their continuous integration.

You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.