Query-driven incremental synchronization of view models

Views are key concepts of domain-specific modeling in order to provide specific focus of the designers by abstracting from unnecessary details of the underlying abstract model. Usually, these views are represented as models themselves (view models), computed from the source model. However, the efficient maintenance of views when the source model changes is challenging, as recalculation from scratch has to be avoided to achieve scalability. This benchmark aims to measure query-based view model creation performance from detailed source models with the EMF-IncQuery framework.

Authors:  Debreceni Csaba, Ákos Horváth, Ábel Hegedüs, Zoltán Ujhelyi, István Ráth and Dániel Varró

Case Study Overview

The benchmark uses a domain-specific model of a railway system that contains most typical class diagram constructs in the source metamodel. This metamodel will be instantiated and then abstracted to view model as an instance of view metamodel.

Source metamodel

A train route can be defined by a set of sensors between two neighboring signals. The state of a signal can be stop (when it is red), go (when it is green) or failure. Sensors are associated with track elements, which can be a track segment or a switch. The status of a switch can be left, right, straight or failure. A route can have associated switch positions, which describe the required state of a switch belonging to the route. Different route definitions can specify different states for a specific switch.

View metamodel

View models consist of only connected virtual switches which abstract the instances of source metamodel. A VirtualSwitch represents a simple Switch from the source metamodel that is not in Failure state. Two VirtualSwitch elements are connected if the corresponding Switch elements are connected in the source model. The CountConnectedInFailure attribute shows the count of Switches that are connected to this VirtualSwitch and are in Failure state.

Derivation Rules

@QueryBasedObject(eClass = "VirtualSwitch")

pattern virtualSwitches(switchElement : Switch)
{
	neg find switchesInFailure(switchElement);
}

@TraceLookup(source = trg, target = t)
@TraceLookup(source = src, target = s)
@QueryBasedFeature(source = s, target = t, feature = "connectedTo")

pattern connectedTo(src : Switch, trg : Switch)
{
	find connectedSwitches(s,t);
	neg find switchesInFailure(s);
	neg find switchesInFailure(t);
}

@TraceLookup(source = src, target = s)
@QueryBasedFeature(source = s, target = c, feature = "CountConnectedInFailure")

pattern countConnectedInFailure(src : Switch, c)
{
	c == count find connectedSwitchesInFailure(src, _);
}

Helper patterns

pattern switchesInFailure(switchElement : Switch)
{
	Switch.Switch_actualState(switchElement, ::PointStateKind_FAILURE);
}

pattern connectedSegments(source : Segment, target : Segment)
{
	Trackelement.TrackElement_connectsTo(source, target);
}

pattern connectedSwitches(source : Switch, target : Switch) {
	Trackelement.TrackElement_connectsTo(source, target);	
} or {
	Trackelement.TrackElement_connectsTo(source, srcSegment);
	find connectedSegments+(srcSegment, trgSegment);
	Trackelement.TrackElement_connectsTo(trgSegment, target);	
}

pattern connectedSwitchesInFailure(source : Switch, target : Switch) {
	find connectedSwitches(source, target);
	neg find switchesInFailure(source);
	find switchesInFailure(target);
}

Measurement

All measurements were executed on a developer PC with a 3.5 GHz Core i7 processor, 16 GB RAM, Windows 7 and Java 7. To avoid interference between different executions, each time a new JVM was created with a 2 GB heap limit. The time to start up and shut down the JVM was not included in the measurement results.

Runtime Performance

Legend

Memory usage

Legend