Keynote at BigMDE 2013

1. Made available under EPL 1.0
OCL - The Bigger Picture
Edward Willink, Willink Transformations Ltd
Eclipse Projects: OCL, MMT, QVTd, QVTo, UMLX
OMG RTFs (representing Nomos): OCL, QVT, UML
BigMDE 2013, Budapest
17th June 2013

2. 17-June-2013 OCL - The Bigger Picture 2Made available under EPL 1.0
Overview
Big MDE
big problems
disproportionately big problems
Small MDE
small problems
insignificant in the small
significant in the large
Big MDE
disproportionately small problems

3. 17-June-2013 OCL - The Bigger Picture 3Made available under EPL 1.0
Background
Electronic/Systems Engineering
poor quality tools
make things better
make things reuseable
make things right
specification not implementation

4. 17-June-2013 OCL - The Bigger Picture 4Made available under EPL 1.0
OCL utility
executable specification language
right
useable
reuseable
unuseable
side effect free
nothing can change
needs objects
only useful within a larger context
transformation languages

5. 17-June-2013 OCL - The Bigger Picture 5Made available under EPL 1.0
Systems

6. 17-June-2013 OCL - The Bigger Picture 6Made available under EPL 1.0
Block Diagrams
●
Low, medium or high level
●
Friendly
 Convey an apparently simple meaning
 Open to review
●
Each element
 Independent
 continuously operating

7. 17-June-2013 OCL - The Bigger Picture 7Made available under EPL 1.0
Subsystems
Systems too complicated
break down in to subsystems/subsubsystems/...
Subsystems available
add value to create a System
What does it actually mean to compose
subsystems ?
compatible interface .... communication

8. 17-June-2013 OCL - The Bigger Picture 8Made available under EPL 1.0
Subsystem Interface Compatibility
Content compatibility
feet/pounds or metres/kilograms ?
model conforming to structural metamodel
types conforming to semantic metamodel
Communication compatibility
producer/consumer
client/server
...

9. 17-June-2013 OCL - The Bigger Picture 9Made available under EPL 1.0
Communication Link is two ended
Both ends must co-operate
All links must co-operate
share bandwidth
avoid deadlocks
reduce latencies
provide security
provide reliability
....

10. 17-June-2013 OCL - The Bigger Picture 10Made available under EPL 1.0
Component Oriented Communications
provide a sink/source
loop forever
wait till inputs available
get inputs
compute outputs and update state
put outputs
Block
inputs outputs
state

11. 17-June-2013 OCL - The Bigger Picture 11Made available under EPL 1.0
Trivial Deadlock
Oops
both waiting for inputs
neither generating output
Deadlock (with just 2 components!)
BlockA
inputs outputs
state
BlockB
inputs outputs
state

12. 17-June-2013 OCL - The Bigger Picture 12Made available under EPL 1.0
Eclipse System Performance
Eclipse 3.0 to 3.4 steadily faster
incremental editor/compiler
incremental builder
Eclipse 3.5 to '3.9'/4.3 steadily slower
innovative new projects
indisciplined use of component-level APIs
(e4 is far from being the major culprit)

13. 17-June-2013 OCL - The Bigger Picture 13Made available under EPL 1.0
'Stupid' Livelock Example
1: Every source file shall be reviewed after any change
2: Every source file shall contain a review record
Oops:
real change =>
review =>
review record change =>
review =>
review record change =>

14. 17-June-2013 OCL - The Bigger Picture 14Made available under EPL 1.0
'Real' Example
1: The Model Index shall contain a summary of all models
2: The Model Index shall be updated when a model changes
3a: The Model Index shall be accessible as a model
3b: A model shall be autogenerated from ...
3c: Another Model Index shall contain a summary of all models
3d: A Configuration Management State ....
In practice the infinite loop is only stabilized by:
an unmodified output file shall not be written

15. 17-June-2013 OCL - The Bigger Picture 15Made available under EPL 1.0
Communication Design
Requirements of the system
=> partitioning of computations
=> distribution over processes/processors
=> requirements on the communications
can be fundamentally relibale
Bottom up subsystem reuse
=> communication anarchy
Components must suit the system

16. 17-June-2013 OCL - The Bigger Picture 16Made available under EPL 1.0
Mutable Components
Implementations
numerous configuration options
(very) bloated interfaces
compromised performance
Specifications
auto-generated implementation
numerous configuration options
unwanted functionality gets optimized away
Dead Specification Elimination

17. 17-June-2013 OCL - The Bigger Picture 17Made available under EPL 1.0
Requirements Specification
Implementation

18. 17-June-2013 OCL - The Bigger Picture 18Made available under EPL 1.0
The basic software production problem
Simple
Problem
too hard
progressions
distractions
models
Specification
Code
Assembler
C
CIM
PIM
PSM
Models
MacroAssembler
C++, Java, ..
Aspect ...

19. 17-June-2013 OCL - The Bigger Picture 19Made available under EPL 1.0
MDA 'Y'
Platform
Independent
Model
Platform
Specific
Model
Platform
Model
PIM
what needs
to be done
program/application
models
what resources
are available
program/algorithm/application
libraries
hardware/operating system
definition models
PSM
what actually gets
done -- the code

20. 17-June-2013 OCL - The Bigger Picture 20Made available under EPL 1.0
Better MDA 'Y'
Specification + Hints + Reality => Solution
Platform
Independent
Model
Platform
Specific
Model
Platform
Model
Mark Model
MM - the manual
intervention
● do the JPEG on the
graphics processor
● use a non-reentrant
QuickSort algorithm for ...
● use TCP to satisfy
transmission guarantees
PSM - the 100%
autogenerated solution

21. 17-June-2013 OCL - The Bigger Picture 21Made available under EPL 1.0
Aspect Oriented MDA
Too many problems to solve
at once
divide and conquer
solve one concern at a time
precision
scheduling
partitioning
latency
integrity
middleware
code generation
Concern A
Code
Models
Concern B
Concern C
Specification
Concern Z
Platform Hints

22. 17-June-2013 OCL - The Bigger Picture 22Made available under EPL 1.0
MetaModel Typed MDA
All models conform to their meta-models
M Ain ≺ MM Ain
M Aout ≺ MM Aout
In practice not all of meta-model is used
M Ain ≺ MM' Ain ∈ MM Ain
M Aout ≺ MM' Aout ∈ MM Aout
M Bin ≺ MM' Bin ∈ MM Bin
M Bout ≺ MM' Bout ∈ MM Bout
Compatibility
M Aout ≡ M Bin
MM' Aout ∈ MM' Bin
[MM Aout ∈ MM Bin too strong]
Concern A
Code
MM Ain
Models
Concern B
Concern C
Specification
Concern Z
MM Bin
MM Bout
MM Aout
MM Cin
MM Cout
MM Zin
MM Zout

23. 17-June-2013 OCL - The Bigger Picture 23Made available under EPL 1.0
Traditional Modeling
UML Analysis Diagrams
poor quality tools
major analysis/design disconnect
UML Design Diagrams
difficult to capture behaviour
opaque code generation templates
troublesome reverse engineering cycles
Very productive in well-suited narrow domains
state/protocol machines
Counter productive in more general applications

24. 17-June-2013 OCL - The Bigger Picture 24Made available under EPL 1.0
The Action Problem
Action code does not model well
Any system
has a 'state'
comprising many variables
can be represented as an instance of a meta-model
event occurs
sometimes comprising a message
can be represented as an instance of a meta-model
has an updated 'state'
comprising many variables
can be represented as an instance of a meta-model

25. 17-June-2013 OCL - The Bigger Picture 25Made available under EPL 1.0
State change as model transformation
Any state change
can be treated as an atomic model transformation
from
old state
input message
to
new state
output messages
Model
Transformation
Input
Message
Output
Message(s)

26. 17-June-2013 OCL - The Bigger Picture 26Made available under EPL 1.0
In-place transformations
Embedded systems
in-place transformation (human)
old state can be accidentally corrupted while computing new state
hybrid old/new state can be inadvertently accessed
in-place transformation (declarative)
tooling must sequence old reads, temp stores, new writes
tooling must hide access during finite duration atomic change
Model
Transformation
A
Input
Message
Output
Message(s)
Model
Transformation
B
Input
Message
Output
Message(s)

27. 17-June-2013 OCL - The Bigger Picture 27Made available under EPL 1.0
Declarative model transformation
Relationship between Input(s) and Output(s)
no internal side effects
very disciplined form of model mutation
can be expressed in OCL
Model
Transformation
Input
Message
Output
Message(s)

28. 17-June-2013 OCL - The Bigger Picture 28Made available under EPL 1.0
Model transformation as OCL
self organizing (small changes)
every node notifies changes
every node listens for relevant changes
OCL analysis configures the listeners
change just ripples through affected graph nodes
strategic (large changes)
transformation directly pokes the affected nodes
OCL Equations
Directed Graph
Input Objects
and Messages
Output Objects
and Messages

29. 17-June-2013 OCL - The Bigger Picture 29Made available under EPL 1.0
Models of Compuation
How, When, Why computations happen
fundamental to Digital Signal Processing
insufficiently known more generally
Lee, E.A., Messerschmitt, D.G.: Synchronous data flow.
Proceedings of the IEEE 75(9), 1235–1245 (1987)

30. 17-June-2013 OCL - The Bigger Picture 30Made available under EPL 1.0
Java Model of Computation
double f(double x, double y)
double p,q,r;
p = x + 1;
q = y - 1;
r = p + q;
return r;
}
When f is invoked (unknown mechanism)
execution proceeds statement by statement
Result is returned (unknown mechanism)
Validity of variables is assumed to be ok
communication exists as a side effect

31. 17-June-2013 OCL - The Bigger Picture 31Made available under EPL 1.0
Java Model of Computation - Oops
double f(double x, double y)
double p,q,r;
r = p + q;
p = x + 1;
q = y - 1;
r = p + q;
return r;
}
Validity of variables is no longer ok
communication fails
may get 'uninitialized variable' warning
in general, just get a malfunction

32. 17-June-2013 OCL - The Bigger Picture 32Made available under EPL 1.0
System/subsystem view
Data dependencies are now clear
cannot misschedule
What happens when?
no one right answer
+

33. 17-June-2013 OCL - The Bigger Picture 33Made available under EPL 1.0
Continuous Time MoC
Executing on analogue hardware
each partial computation has its own hardware
occurs continuously
propagation delay from input to output

34. 17-June-2013 OCL - The Bigger Picture 34Made available under EPL 1.0
Simulation
Dedicated hardware per computation
impractical
inaccurate/unstable
unnecessarily redundant
Simulation
fast enough to give comparable results
share hardware

35. 17-June-2013 OCL - The Bigger Picture 35Made available under EPL 1.0
Data Flow MoC
Each node processes when ready
absorbs a token from each input
produces a token at each output
propagation delay from input to output

36. 17-June-2013 OCL - The Bigger Picture 36Made available under EPL 1.0
Synchronous Data Flow MoC
All input tokens 'appear' at once
no need for physical tokens
synthesize a legal schedule
p = x+1; q = y-1; r = p+q;
q = y-1; p = x+1; r = p+q;

37. 17-June-2013 OCL - The Bigger Picture 37Made available under EPL 1.0
Discrete Event MoC
Inputs may change one at a time
variables have persistent state
x changes:
p = x+1; r = p+q;
y changes:
q = y-1; r = p+q;

38. 17-June-2013 OCL - The Bigger Picture 38Made available under EPL 1.0
Practical Consequences
Incremental editor
editing 10 line file has cost T
editing a 10,000 line can be << 1000T
incremental code too hard to write manually
Eclipse JDT, builder sometimes malfunction (rebuild all)
Xtext does not attempt many incremental updates
incremental code can be correct automatically
OCL is a side effect free specification language
very hard to do the same with arbitrary Java code

39. 17-June-2013 OCL - The Bigger Picture 39Made available under EPL 1.0
Model Transformation Performance
large random trees using EMF
1.0 * C = time to create a tree in memory
1.6 * C = time to copy a tree in memory
1.7 * C = time to save a tree as XMI on disk
4.0 * C = time to load a tree from XMI on disk
36 * C = time to transform a tree in memory
Eclipse QVTo (interpreted)
2.0 * C = time to transform a tree in memory
Eclipse QVTi (code generated)

40. 17-June-2013 OCL - The Bigger Picture 40Made available under EPL 1.0
System Performance
Complex systems require transformation cascades
many intermediate models
N * (save + load + save)
N *(4.0 + 36 + 1.7) extra models ~15%
N *(4.0 + 2 + 1.7) extra models ~300%
Composition
merge multiple transformations
exploit close relationships with graph transformation

41. 17-June-2013 OCL - The Bigger Picture 41Made available under EPL 1.0
Performance Summary
Multiple transformations
optimize by composition
Long running systems
optimize by incremental update
only possible for declarative transformations
exploit side effect free characteristics of OCL

42. 17-June-2013 OCL - The Bigger Picture 42Made available under EPL 1.0
Shared tool chain
New transformation language
leverage interpreter/debugger/optimizers/composers
Better debugger
reuseable by many languages
VMNew Intermediate LanguagesQVT Declarative
QVTr QVTc QVTuQVTc QVTm QVTi
OCL
UML
QVTi + Java
Interpreters/DebuggersOptimizers/Composers/RescuersEditors

43. 17-June-2013 OCL - The Bigger Picture 43Made available under EPL 1.0
OCL Specification/Implementation
OCL specification is incomplete
EBNF UML OCLQVTUMLEBNF

44. 17-June-2013 OCL - The Bigger Picture 44Made available under EPL 1.0
The New Eclipse OCL using Xtext
Xtext covers large parts of an implementation
Modest gaps between specification and tooling

45. 17-June-2013 OCL - The Bigger Picture 45Made available under EPL 1.0
Eclipse OCL Tooling Work
OCL to Java automation of WFRs
OCL-friendly Transformation Virtual Machine
Automation of Pivot ASG creation/mapping
Automation of CST to Pivot ASG mappings
Re-useable for QVT

46. 17-June-2013 OCL - The Bigger Picture 46Made available under EPL 1.0
Software Qualification
Specification
words, ambiguities, omissions and contradictions
Code
huge line count, numerous authors,
finite development time and money,
finite testing enthusiasm
Specification
Code
Safety Critical
Eliminate all specification errors
Eliminate all implementation errors

47. 17-June-2013 OCL - The Bigger Picture 47Made available under EPL 1.0
Zeroth Order Software Qualification
Manually Check the Specification
confidence building prototypes
selective formal mathematics
Manually Check the Code
1000 lines possible
100,000 lines hard
1,000,000 lines totally unrealistic
Manual
Transformation
Specification
Code
checked
'ignored'

48. 17-June-2013 OCL - The Bigger Picture 48Made available under EPL 1.0
First Order Software Qualification
Check the Specification
manual check of principles
Automatically Validate the Specification
automated check of consistency, ambiguities, omissions
Manually Check the Transformation Tool Code
1,000,000 lines totally unrealistic
most errors are orthogonal
Auto-generate the Production Code
Automated
Transformation
Specification
Code
Transformation
Tool Code

49. 17-June-2013 OCL - The Bigger Picture 49Made available under EPL 1.0
Higher Order Software Qualification
Check the Specifications
manual check of principles
automated check of consistency, ambiguities, omissions
most errors are doubly orthogonal
tool specifications checks are re-useable
Automated
Transformation
Specification
Code
Transformation
Tool Code
Automated
Transformation
Tool Specification
Transformation
Tool Code
Automated
Transformation

50. 17-June-2013 OCL - The Bigger Picture 50Made available under EPL 1.0
Summary
Everything is a Model Transformation
efficient code generation
effective composition
autogenerated incremental update
autogenerated tooling
higher order software qualification

51. 17-June-2013 OCL - The Bigger Picture 51Made available under EPL 1.0
System Oriented Communications
●
Component Oriented Communications (One
Ended)
− system utility is not my problem
− deadlocks, livelocks are your problem
− difficult/intractable analysis
− component is not (re-)usable
●
System Oriented Communications (Two Ended)
− communication policy carefully chosen
●
suitable communication rates
●
suitable communication resources/bandwidths/routes
●
compliant sources and sinks on each end
− tractable synthesis
●
?? cf. Service Oriented Architectures ??