Heiko Klare edited this page Jul 9, 2018 · 6 revisions

Welcome to the Vitruv Wiki

Vitruv is developed by members of the chair for software design and quality (SDQ) at Karlsruhe Institute of Technology (KIT).

For more information, take a look into this Wiki or contact us via vitruvius-dev@ira.uka.de.

You find all Vitruv projects, including application projects, in our GitHub organization.

Concept

The Vitruv approach implements the concept of dynamically created flexible views.

The approach is based on the Orthographic Software Modeling (OSM) concept by Atkinson et al. [1], but does not use a monolithic single underlying metamodel (SUM). Instead, legacy metamodels are combined in a non-invasive way to serve as a modular underlying model.

View-Centric

Our approach provides exible views conforming to well-defined view types that may combine elements of different metamodels. The flexible view definition specifies which elements (selection) of which metamodel types (structure) are displayed. It may also restrict the set of operations that are permitted on the displayed elements. For the individual views conforming to a specific view type, the origin of the elements is transparent. View types that combine or omit elements and trivial view types that display every element unchanged cannot be distinguished. This is possible, because all access to system elements has to occur through views conforming to view types.

Controlled Complexity

All views have to report atomic modifications of the elements that they are displaying. Based on this information, internal model instances of the involved metamodels are synchronized. These internal models cannot be directly accessed from outside. This allows us to control the complexity of synchronizations through the provided view types. For example, effects of operations that are not permitted do not need to be considered for synchronization.

Abstract Consistency

It is possible to define declarative correspondence and consistency rules for all pairs of metamodels with elements representing the same entities. If a view reports modifications, synchronization transformations that are generated from these definitions and modification response actions are executed. This separation of an abstract mapping between metamodels and the resulting synchronization operations decouples metamodels to allow for evolution according to their individual evolution pressure. If a metamodel shall be updated or added, it is sufficient to update or add its correspondence rules and the view types that display its elements.

Ease of Use

If elements of different metamodels shall be displayed as a single element in a view type, then this information can be used to propose correspondence relations between these metamodels. In return, correspondence relations that link equivalent elements in different metamodels can be used to suggest view types that combine these elements. This should reduce the effort needed to develop new view types and ease the addition of new metamodels. Furthermore, the generation of views and synchronization transformations from declarative definitions relieves the user from implementing these views and transformations.

Vitruv for PCM and Java Code

We implemented an approach that uses Vitruv to keep Java Source Code and PCM instances consistent during the development of a software system. Screencasts can be found under https://sdqweb.ipd.kit.edu/vitruvius/VitruviusScreencasts.

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.