Für eine korrekte Darstellung dieser Seite benötigen Sie einen XHTML-standardkonformen Browser, der die Darstellung von CSS-Dateien zulässt.

. .

SiLift: Tool Environment Overview

The SiLift Processing Pipeline

Figure 1 shows the main steps of the adaptable difference processing pipeline of SiLift:

SiLift Processing Pipeline

Fig. 1: SiLift Processing Pipeline

(1) Model Matching

Initially, a Matcher searches for pairs of corresponding model objects which are considered to be the same in both models. SiLift comes with a set of primitive matchers such as a UUID matcher based on XMI-IDs and a simple, but efficient signature-based matcher which establishes correspondences based on equal values of name attributes; these names are available for the most model element types in typical modeling languages.

The SiLift framework can be adapted to arbitrary more sophisticated matching engines. Adapters for EMF Compare and the SiDiff Matching Engine have already been realized. Further matchers can be added via the extension point org.sidiff.matcher.extensionpoint.

(2) Low-level Difference Derivation

Based on a given set of correspondences, a low-level difference based on the ASG is built by a Difference Derivator. The low-level difference basically consists of

  • objects that are deleted and inserted,
  • object references that deleted and inserted,
  • and changed values of object attributes.

A difference derivator can exclude predefined element, reference and attribute types from the difference. For instance, SiLift already provides several derivators for Ecore excluding EAnnotations or EGenericTypes. Further difference derivators can be added via the extension point technical_difference_builder_extension.

(3) High-level Operation Detection

The Lifting Engine identifies groups of low-level changes representing the effect of a high-level edit operation.

The SiLift Operation Detection Engine is configured by EMF Henshin model transformation rules implementing the set of language-specific edit operations. To be more precisely, the transformation rules used by the Lifting Engine are called recognition rules (not shown in Figure 1). They are automatically derived from their corresponding edit transformation rules, each edit rule implementing a high-level edit operation.

Furthermore, a set of atomic consistency-preserving edit transformation rules can be automatically derived from the corresponding metamodel of the modeling language using the SiDiff Edit Rule Generator (SERGe) (s. Figure 1, (A)). More complex edit transformation rules such as refactorings can be inferred form a set of examples (s. Figure 1, (B)). All the transformation rules are statically analyzed for potential conflicts and dependencies (s. Figure 1, (C)); the analysis results are needed for the next step.

To adapt SiLift for further modeling languages the set of edit transformation rules must be provided as a Rule-Base Project via the extension point org.sidiff.editrule.rulebase.project.runtime.extension.

(4) Edit Script Generation

The Edit Script Generator analyzes the detected edit operation invocations for sequential dependencies and their invocation arguments and generates an executable Edit Script.

(5) Difference Presentation UI

The Difference Presentation UI serves as graphical interface and enables end-users to examine semantically lifted model differences.

(6) Change Propagation

A generated Edit Script can be (interactively) applied to other model versions.

SiLift API

All components of the processing pipeline can be accessed via API:

  • org.sidiff.matching.api.MatchingFacade
  • org.sidiff.difference.technical.api.TechnicalDifferenceFacade
  • org.sidiff.difference.lifting.api.LiftingFacade
  • org.sidiff.difference.asymmetric.api.AsymmetricDiffFacade
  • org.sidiff.patching.api.PatchingFacade
Each Facade provides a set of convenience functions encapsulating the corresponding processing pipeline steps. This enables tool engineers to implement more complex version management functions such as patching or merging directly using high-level model differences as shown in the next section.

Integration with Eclipse IDE and Version Control Systems

SiLift is based on the Eclipse Modeling stack and tightly integrated with the Eclipse IDE. Each step of the processing pipeline can be configured for each domain separately and may be set for the overall workspace or related to a specific project via the Eclipse preferences dialog.

Furthermore, its compare and patching facilities are connected to the Eclipse Team Provider for SVN (Subversive) and Git (EGit) and are automatically used when comparing or synchronizing local workspace copies with other local workspace copies or versions obtained from a repository.

Tool Demonstrations

You are kindly invited to watch the screencasts below in order to get an overview of the SiLift main functions model differencing and model patching (including workspace updates).

Demo 1: semantic lifting of model differences

Demo 1: workspace update

Related Projects

The SiLift Framework has been further integrated into and extended by several related projects which exploit its high-level compare and patching facilities:
  • IncSlice: A Tool for Incrementally Slicing Editable Sub-Models
  • ReVision: A Tool for History-based Model Repair Recommendations
  • SiPL: A delta-based modeling framework for SPLs