incremental model queries for model-dirven software engineering
TRANSCRIPT
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