1. Budapest University of Technology and Economics
Department of Measurement and Information Systems
Budapest University of Technology and Economics
Fault Tolerant Systems Research Group
MTA-BME Lendület Research Group on Cyber-Physical Systems
Change Propagation of View Models
by Logic Synthesis using SAT solvers
Oszkár Semeráth, Csaba Debreceni,
Ákos Horváth, Dániel Varró
BX 2016, Eindhoven
1

2. Artemis Concerto Project
 Project Goal:
o Wearable sensors and smart home solutions
o Telecare systems for remote medical
examinations and diagnostics
o Important aspects: Reliability and Safety
 Our Tasks:
o Component modeling
o Telecare specific code generators
o Query-based visualization with Sirius (Telecare specific views)
 Forward and backward transformation of view models
2

3. Running Example: Blood Pressure Measurement
 Architecture model:
Blood pressure + Pulse measure
 Model queries: EMF-IncQuery
o Graph patterns
o Incremental evaluation
 Well-formedness constraint:
o Error pattern: no match  Valid 
o Consistency of the source model
3
pt:PeriodicTrigger
measures
triggers
phone: Sensor measures
pressure: Type pulse: Type
when m2 :Measurem1: Measure
type type
pulseDone:
EventTrigger
triggeredBy
pressureDone:
EventTrigger
triggeredBy
triggers
triggers
Architecture Model
unreported(m)
m:Measurement
:Report
what NEG
WF constraint
emerg:Hostgp:Host
where where
r2 :Reportr1 :Report
what what

4. Running Example: View Models
 View Model: match  traceability model  element in view model
 Automatically created + incrementally maintained
4
dataflow(type, host)
:Measurement
:EventTrigger
:Report
host:Host
triggeredBy
type: Type
type where
what
Pressure
Pulse
GP
Emerg
when
phone: Sensor
m2 :Measure
pt:PeriodicTrigger
pulseDone:
EventTrigger
r2 :Report
emerg:Host
measures
triggeredBy
m1: Measure
pressureDone:
EventTrigger
r1 :Report
gp:Host
measures
triggeredBy
triggers
triggers
triggerspressure: Type pulse: Type
type type
where where
what what
1. Initial Model
3. View Model
2. Transfor-
mation
Architecture Model
Data-flow model
C. Debreceni, Á. Horváth, Á. Hegedüs, Z. Ujhelyi, I. Ráth, and D. Varró. Query-driven incremental synchronization of view
models. In Proceedings of the 2nd Workshop on View-Based, Aspect-Oriented and Orthographic Software Modelling, 2014.

5. Properties of the Forward Transformation
S. Hidaka, M. Tisi, J. Cabot, and Z. Hu. Feature-based classification of bidirectional
transformation approaches. Software & Systems Modeling, pages 1–22, 2015.
 Forward functional transformation
 Consistency definition: Unidirectional, Total target
 Expressiveness: Turing incomplete
 Forward propagation: Automatic, Operation-based, Live
 View models: regular models
 Incomplete change support: only the source can be edited
5
Contribution: Backward change propagation of View models

6. Running Example: Change in the View Model
6
dataflow(type, host)
:Measurement
:EventTrigger
:Report
host:Host
triggeredBy
type: Type
type where
what
Pressure
Pulse
GP
Emerg
when
phone: Sensor
m2 :Measure
pt:PeriodicTrigger
pulseDone:
EventTrigger
r2 :Report
emerg:Host
measures
triggeredBy
m1: Measure
pressureDone:
EventTrigger
r1 :Report
gp:Host
measures
triggeredBy
triggers
triggers
triggerspressure: Type pulse: Type
type type
where where
what what
1. Initial Model
Pressure
Pulse
GP
Emerg
3. View Model 5. Changed Model
«new»
«del»
2. Transfor-
mation
4. Change
Architecture Model
Data-flow modelData-flow models
 Abstract view models can be edited (Conceptual changes)
 Pulse measurements are redirected to the General Practicioner

7. Running Example: Backward Change Propagation
7
unreported(m)
m:Measurement
:Report
what NEG
dataflow(type, host)
:Measurement
:EventTrigger
:Report
host:Host
triggeredBy
type: Type
type where
what
Pressure
Pulse
GP
Emerg
when
phone: Sensor
m2 :Measure
pt:PeriodicTrigger
pulseDone:
EventTrigger
r2 :Report
emerg:Host
measures
triggeredBy
m1: Measure
pressureDone:
EventTrigger
r1 :Report
gp:Host
measures
triggeredBy
triggers
triggers
triggerspressure: Type pulse: Type
type type
where where
what what
1. Initial Model
Pressure
Pulse
GP
Emerg
3. View Model 5. Changed Model
«new»
«del»
2. Transfor-
mation
6. Change
propagation
Architecture Model
Data-flow models
WF
?
4. ChangeCreate solution candidates:
 Consistent with the Views
 Satisfies the well-formedness constraints

8. Running Example: Backward Change Propagation
8
unreported(m)
m:Measurement
:Report
what NEG
dataflow(type, host)
:Measurement
:EventTrigger
:Report
host:Host
triggeredBy
type: Type
type where
what
Pressure
Pulse
GP
Emerg
when
phone: Sensor
m2 :Measure
pt:PeriodicTrigger
pulseDone:
EventTrigger
r2 :Report
emerg:Host
measures
triggeredBy
m1: Measure
pressureDone:
EventTrigger
r1 :Report
gp:Host
measures
triggeredBy
triggers
triggers
triggerspressure: Type pulse: Type
type type
where where
what what
1. Initial Model
Pressure
Pulse
GP
Emerg
3. View Model 5. Changed Model
«new»
«del»
7. A.
pulseDone:
EventTrigger
«del» r2
pressureDone:
EventTrigger
r1 :Report
GP:Host
where
what «new» what
2. Transfor-
mation
Architecture Model Architecture Model Variants
Data-flow models
pulseDone:
EventTrigger
«new» :Report
pressureDone:
EventTrigger
r1: Report
GP:Host
where «new»
where
what «new» what
7. B.
«del» r2
WF
4. Change
Multiple valid solutions
 Sol 1: pulse and pressure in the same message
 Sol 2: two separate reports
6. Change
propagation

9. Properties of the New Backward Transformation
S. Hidaka, M. Tisi, J. Cabot, and Z. Hu. Feature-based classification of bidirectional
transformation approaches. Software & Systems Modeling, pages 1–22, 2015.
 Implicit backward consistency: View models derived from
a changed source model are isomorphic to the changed view
 Well-formedness: Changed source models are well-formed
 State based and offline back-propagation:
changes on view  stable view  source changes
 Interactive execution: Developer may select the most suitable one
source change
9

10. Overview of the Approach
10
Target (View) Models Source ModelTrace
Change
on target
𝑀 𝑉
′
= 𝑀 𝑉
𝐹
+ 𝑀 𝑉
𝑁
difference
𝑀 𝑉 = 𝑀 𝑉
𝐹
+ 𝑀 𝑉
𝑂
View model 𝑀 𝑉 is changed to 𝑀 𝑉
′
 Fix: 𝑀 𝑉
𝐹
 Old: 𝑀 𝑉
𝑂
 New: 𝑀 𝑉
𝑁

11. Overview of the Approach
11
𝑇 = 𝑇𝐹 + 𝑇𝑂
Target (View) Models Source ModelTrace
Change
on target
𝑇′
= 𝑇𝐹 + 𝑇 𝑁𝑀 𝑉
′
= 𝑀 𝑉
𝐹
+ 𝑀 𝑉
𝑁
difference
𝑀 𝑉 = 𝑀 𝑉
𝐹
+ 𝑀 𝑉
𝑂 𝑙𝑜𝑜𝑘𝑢𝑝
𝑙𝑜𝑜𝑘𝑢𝑝
difference
The change is traced back to changeing Trace model 𝑇  𝑇′
 Fix: 𝑇𝐹
 Old: 𝑇𝑂
 New: 𝑇 𝑁

12. Overview of the Approach
12
𝑀𝑆 = 𝑀𝑆
𝐹
+ 𝑀𝑆
𝐶
+ 𝑀𝑆
𝑂𝑇 = 𝑇𝐹 + 𝑇𝑂
Target (View) Models Source ModelTrace
Change
on target
𝑇′
= 𝑇𝐹 + 𝑇 𝑁𝑀 𝑉
′
= 𝑀 𝑉
𝐹
+ 𝑀 𝑉
𝑁
difference
𝑙𝑜𝑜𝑘𝑢𝑝𝑀 𝑉 = 𝑀 𝑉
𝐹
+ 𝑀 𝑉
𝑂 𝑙𝑜𝑜𝑘𝑢𝑝
𝑙𝑜𝑜𝑘𝑢𝑝
difference
Impact analysis  Source model is separated to three partitions
 Fix: 𝑀𝑆
𝐹
(unaffected, don’t hurt)
 Changing: 𝑀𝑆
𝐶
(affected,
but can not be removed)
 Old: 𝑀𝑆
𝑂
(affected, can be removed)
when
phone: Sensor
m2 :Measure
pt:PeriodicTrigger
pulseDone:
EventTrigger
r2 :Report
emerg:Host
measures
triggeredBy
m1: Measure
pressureDone:
EventTrigger
r1 :Report
gp:Host
measures
triggeredBy
triggers
triggers
triggerspressure: Type pulse: Type
type type
where where
what what

13. Overview of the Approach
13
𝑀𝑆 = 𝑀𝑆
𝐹
+ 𝑀𝑆
𝐶
+ 𝑀𝑆
𝑂𝑇 = 𝑇𝐹 + 𝑇𝑂
Target (View) Models Source ModelTrace
Change
on target
𝑇′
= 𝑇𝐹 + 𝑇 𝑁𝑀 𝑉
′
= 𝑀 𝑉
𝐹
+ 𝑀 𝑉
𝑁
Logic
Solver+WF
difference
𝑙𝑜𝑜𝑘𝑢𝑝𝑀 𝑉 = 𝑀 𝑉
𝐹
+ 𝑀 𝑉
𝑂 𝑙𝑜𝑜𝑘𝑢𝑝
𝑙𝑜𝑜𝑘𝑢𝑝
difference
?
Model synthesis by logic solvers:
 Language Specification
 Well-formedness constraints
 Changing + Fix part as Partial Model
 Definition of the patterns
 Matches of the changed view model

14. Overview of the Approach
14
𝑀𝑆 = 𝑀𝑆
𝐹
+ 𝑀𝑆
𝐶
+ 𝑀𝑆
𝑂𝑇 = 𝑇𝐹 + 𝑇𝑂
Target (View) Models Source ModelTrace
Change
on target
𝑇′
= 𝑇𝐹 + 𝑇 𝑁𝑀 𝑉
′
= 𝑀 𝑉
𝐹
+ 𝑀 𝑉
𝑁 𝑀𝑆
𝑁1
WF WF
Logic
Solver+WF
difference
WF
«del»
𝑀𝑆
𝑁2
𝑀𝑆
𝑁3
𝑙𝑜𝑜𝑘𝑢𝑝
𝑀𝑆
′
= 𝑀𝑆
𝐹
+ 𝑀𝑆
𝐶
+
«new»
𝑀 𝑉 = 𝑀 𝑉
𝐹
+ 𝑀 𝑉
𝑂 𝑙𝑜𝑜𝑘𝑢𝑝
𝑙𝑜𝑜𝑘𝑢𝑝
difference
Model synthesis by logic solvers:
 Language Specification
 Well-formedness constraints
 Changing + Fix part as Partial Model
 Definition of the patterns
 Matches of the changed view model
Valid instance model

15. Measurement Setup
 Prototype implementation using Alloy with Sat4j
 Benchmark based on the healthcare domain:
o Size of the source model
o Number of changes
o Incremental vs Full generation
 Average runtime in 3 runs
15

16. Measurement Results: Scalability
16
0
20
40
60
80
100
120
140
160
180
200
15 35 55 75 95 115 135 155 175
Runtime(s)
Number of objects in the original source model
|N|=0
|N|=1
|N|=2
|N|=3
|N|=4
|N|=5
|N|=6
|N|=7
|N|=8
|N|=9
|N|=10
O(|S|^3)
O(|S|^3)
O(|S|^3)
proportional to the
cube of the size
proportional to the
cube of the size
proportional to the
cube of the size

17. Measurement Results: Full vs Incremental
17
0
50
100
150
200
250
300
350
400
0 2 4 6 8 10 12 14 16 18 20
Runtime(s)
Number of intrduced new objects to the changes source model
Incr,|S|=15
Incr,|S|=27
Full,|S|=15
Full,|S|=27
proportional to the
cube of the size
Full generation
Incremental

18. Conclusion
18
Target (View) Models Source ModelTrace
Change
on target WF WF
Logic
Solver+WF
difference
WF
«del»
difference
dataflow(type, host)
:Measurement
:EventTrigger
:Report
host:Host
triggeredBy
type: Type
type where
what
Pressure
Pulse
GP
Emerg
when
phone: Sensor
m2 :Measure
pt:PeriodicTrigger
pulseDone:
EventTrigger
r2 :Report
emerg:Host
measures
triggeredBy
m1: Measure
pressureDone:
EventTrigger
r1 :Report
gp:Host
measures
triggeredBy
triggers
triggers
triggerspressure: Type pulse: Type
type type
where where
what what
1. Initial Model
Pressure
Pulse
GP
Emerg
3. View Model 5. Changed Model
«new»
«del»
7. A.
pulseDone:
EventTrigger
«del» r2
pressureDone:
EventTrigger
r1 :Report
GP:Host
where
what «new» what
2. Transfor-
mation
Architecture Model Architecture Model Variants
Data-flow models
pulseDone:
EventTrigger
«new» :Report
pressureDone:
EventTrigger
r1: Report
GP:Host
where «new»
where
what «new» what
7. B.
«del» r2
WF
4. Change
6. Change
propagation