Budapest University of Technology and EconomicsDepartment of Measurement and Information Systems

Incremental Model Queries for Model Driven Software Engineering

Ákos Horváth Based on Dániel Varró’s slides

Budapest University of Technology and EconomicsFault Tolerant Systems Research Group

IncQuery Labs Ltd

Outline of the TalkMotivation of model queries and transformation:• Critical system development

The EMF-IncQuery framework• Language and Execution

Code Generation by Model Transformations• Batch vs. Incremental

Outlook• Performance evaluation• Distributed & Incremental Queries

Main Contributors o István Rátho Ákos Horvátho Gábor Bergmanno Ábel Hegedüso Zoltán Ujhelyio Benedek Izsóo Gábor Szárnyaso Csaba Debrecenio Dénes Harmatho József Makaio Dániel Steino …

MODEL TRANSFORMATIONS IN CRITICAL SYSTEMS DEVELOPMENT

Development Process for Critical SystemsUnique Development Process

(Traditional V-Model)

Critical Systems Design requires a certification process to develop justified evidence that the system is free of flaws

Software Tool Qualification obtain certification credit for a software tool used in critical system design

Qualified Tool Certified Output

DO-178BIEC 61508

Innovative Tool Better System

Model-Driven Engineering of Critical Systems

Traditional V-Model Model-Driven Engineering

Main ideas of MDE• early validation of system models • automatic source code generation quality++ tools ++ development cost--

• DO-178B/C: Software Considerations in Airborne Systems and Equipment Certification (RTCA, EUROCAE) • Steven P. Miller: Certification Issues in Model Based Development (Rockwell Collins)

Models and Transformations in Critical Systems

System Design Model

Architecture Design Model

Component Design Model

Refine

Refine

Design + V&V Artifacts (Source code, Glue code, Config. Tables, Test Cases, Monitors, Fault Trees, etc.)

Code & TestGeneration

Vertical Model Transform

ations

Component V&V Model

Architecture V&V Model

System V&V Model

Model generation

Back-AnnotationModel generation

Back-AnnotationModel generation

Back-Annotation

Use

Use

Horizontal Model Transformations

Formal methods

Formal methods

Design rules

Design rules

Design rules

End-to-End Traceability

End-to-End Traceability

Model Transformations• knowledge transfer: theoretical resultstools• bridge / integrate existing languages&tools

Related projects• CESAR, SAVI, …• HIDE, DECOS, DIANA, MOGENTES, CERTIMOT,GENESYS, SENSORIA

INCREMENTAL MODEL QUERIES: THE EMF-INCQUERY PROJECT

Motivation: Early validation of design rulesSystemSignalGroup design rule (from AUTOSAR)

o A SystemSignal and its group must be in the same IPduo Challenge: find violations quickly in large modelso New difficulties• reverse

navigation• complex

manualsolution

AUTOSAR: • standardized SW architecture of the automotive industry• now supported by modern modeling toolsDesign Rule/Well-formedness constraint: • each valid car architecture needs to respect• designers are immediately notified if violatedChallenge: • >500 design rules in AUTOSAR tools• >1 million elements in AUTOSAR models• models constantly evolve by designers

•Declarative graph query language•Transitive closure, Negative cond., etc.•Compositional, reusable

Definition

•Incremental evaluation•Cache result set•Maintain incrementallyupon model change

Execution

•Derived features,•On-the-fly validation•View generation, Notifications, Soft links, Databinding,

Features

EMF-IncQuery: An Open Source Eclipse Project

http://eclipse.org/incquery

The IncQuery (IQ) Graph Query Language

IQ: declarative query languageo Attribute constraints o Local + global querieso Compositionality+Reusabilility o Recursion, Negation, o Transitive Closureo Syntax: DATALOG style

pattern routeSensor(sensor: Sensor) = { TrackElement.sensor(switch,sensor); Switch(switch); SwitchPosition. switch(sp, switch); SwitchPosition(sp); Route.switchPosition(route, sp); Route(route); neg find head(route, sensor); }pattern head(R, Sen) = { Route.routeDefinition(R, Sen);}

route: Route sp: SwitchPosition

Switch: Switchsensor: Sensor

switchPosition

switchsensor

routeDefinition

Query(A,B) ∧condi(Ai,Bi) • all tuples of model elements a,b• satisfying the query condition• along the match A=a and B=b• parameters A,B can be input/ output

EMF-INCQUERY Architecture

Transaction

In-memory EMF model

Rete net

Indexer layer

EMF-INCQUERY

Indexing

In-memory storage

Production network• Stores intermediate query results• Propagates changes

Fill the input nodesFill the worker nodesRead the result setModify the modelPropagate the changesRead the changes in the result set (deltas)

Incremental Query Evaluation by RETE

join

join

antijoin

Result set

input nodes

Communication channel

Logical signal Mapping Physical signal

worker nodes

TRANSFORMATION DRIVEN ANALYSIS OF SYSTEM MODELS

Ongoing Project with ETH

UML State Machine

UPPAAL

Source Code

Automatically reveal• Deadlocks• Timing violations• Property violations

Generate source code• Different runtime

platforms• Incremental code

generation

Poor Man’s Generator: Java over EMF APIDefined by Java code

1. Traversal by code2. Manual model building3. No traceability

- High Maintenance- Low Reusability+ Easy to start

Concrete Syntax

Abstract Syntax

while (i <= input){ i++;}

:WhileStatement

:Block

:Increment

:VariableRefname = "i"

:ConditionTestconditionblock

:Relationop="<="

:VarRefname = "i"

:VarRefname = "input"

:Location

:Edge :Edge

:Guardexp="!(i<=input)"

:Location

:Edge :Edge

trg src

src trg

:Guardexp="!(i<=input)"

:Updateexp="i++"

srctrg

Transformation codeLocation transform(WhileStatement w) { for(Statement s: w.block.statements) { /* map the inner states */} for(Location l : locations) { /* Link the locations to a circle */} // Map the condition // Set the guards of the outgoing edges}

w.block.increment.variableRef.name 1l = factory.createLocation(); 2e.setSource(locationMap.get( edgeMap.get(w.condition)));

3

for(state:block)

instanceofA,B,CState

1

Factory.create

setTarget()

2

Code Generation by Model Transformations

Source Model Target CodeCode DOM/AST

M2M M2T

Model-to-Model (M2M) Transformation• SRC: In-memory model (objects) • TRG: In-memory model (objects)

Model-to-Text (M2T) Transformation• SRC: In-memory model (objects) • TRG: Textual code (string)

Traceability in Model Transformations

Source Model Target CodeCode DOM/AST

M2M M2T

Objective:• Support end-to-end traceability• REQ Model Code

Traceability links:• Additional links (edges)• Connect SRC and TRG models

Chaining of Model Transformations

Source Model Target CodeCode DOM/AST

M2M M2T

Inter Model 1 Inter Model 2

M2M

M2M

M2MGoal:• Reduce abstraction gap

by „divide and conquer”• Intermediate models• Chain of

model transformations

Model Transformation Flows / Chains

Source Model Target CodeCode DOM/ASTM2T

Inter Model 1 Inter Model 2

M2M

M2M

M2M

Source Model 2

M2M

Joint optimization steps

LEVELS OF INCREMENTALITY INMODEL TRANSFORMATIONS

No Incrementality: Batch Transformations

1. First transformation

2. Source model changes3. Re-execute from scratchfor all source models

SRC1

SRC2

TRG1TRACE1

TRG2TRACE2

Dirty Incrementality

1. First transformation

2. Source model changes3. Re-execute from scratchonly for changed models

SRC1

SRC2

TRG1TRACE1

TRG2TRACE2

Pros:• Large-step incrementality• Avoids continuous exec.Cons:• Complex MT can be slow• Cleanup (after an error)?• Chaining?

Incrementality by Traceability

1. First transformation

2. Source model changes

4. Re-execute MT only for untraceable elements

SRC1

SRC2

TRG1TRACE1

TRG2TRACE2

3. Detect missing trace links

Pros:• Small-step incrementality• Better performanceCons:• Highly depends on

traceability links• Smart matcher needed

Event/Change Driven Transformations

1. First transformation

2. Source model changes

4. Fire rule activations (in relevant context)

SRC1

SRC2

TRG1TRACE1

TRG2TRACE2

3. Detect new activations

Pros:• Refined context: driven by

changes of query result set• Chaining• Avoids continuous comp.Cons:• Language-level restrictions

PERFORMANCE BENCHMARKS

Performance of EMF-INCQUERY Incremental graph queries based on Rete Models in the Eclipse Modeling Framework

model size

runtimebatch queries

incremental queries

Exec. time is proportional to the size of the modification.

Largest synthetic model(TrainBenchmark)• 2.8 million nodes • 11.2 million edges• revalidation time: 1 ms

Largest real model(Eclipse 4.0 source code)• 8.6M nodes+26.2M edges• revalidation: <20 ms (except for 1 query)

Performance of EMF-INCQUERY

model size

incremental queries

batch queries

memory limit

Storing partial resultsmemory

consumption

Different Applications of on-the-fly Query Evaluation

•HW/SW Allocation•Queries for validation•Complex model transformation chain•Virtual models (by derived objects)

Toolchain for IMA configs

•Connect to Matlab Simulink model •Export: Matlab2EMF•Change model in EMF•Re-import: EMF2Matlab

MATLAB-EMF Bridge

•Traces :defined by queries + exist only at runtime• Linked element identified by query result• Supports collaboration

Soft Links for Traceability

•Provide simpified graphical views for complex models•Forward incremental view maintenance•Chaining of views

View Maintenance

•Find design candidates•Rules for operations•Queries for constraints•Hints and guidance•Potentially infinite state space

Design Space Exploration

•Itemis (developer)•Embraer•Thales•ThyssenKrupp•CERN

Known Users

Conclusions