The document discusses model transformation from the perspective of the author's background in embedded systems and digital signal processing. It outlines the author's experience with diagrams and models from analog circuits to block diagrams to functional modeling. It then discusses the challenges of model transformation, including dealing with meta-model semantics, managing multiple meta-models, and improving transformation efficiency through techniques like combining multiple transformation passes. The document argues that achieving widespread re-usable transformations will require formalizing the relationships between meta-models and their semantics.

1. Model Transformation
A Personal Perspective
Edward D. Willink
ed@willink.me.uk
GMT Consortium
www.eclipse.org
also Thales Research and Technology (UK)
edwillink@iee.org
AMMA 2006

2. 3 May 2006 Model Transformation - A Personal Perspective 2
Outline
●
Background
− personal
− embedded rather than mainstream
●
different perspectives/tools
− diagrams and their meaning
●
Current
− convergence
●
same problems
●
Future Challenges
− meta-model semantics
− meta-model management
− transformation efficiency

3. 3 May 2006 Model Transformation - A Personal Perspective 3
Background
Electronic Engineer
Racal Research -> Thomson CSF Racal -> Thales Research and Technology
DSP, DSP tools
WDL specification language proposal
Computer Scientist
PhD - better DSP tools
DSP compiler optimisation
Meta-compilation for C++
Open Source
Ptolemy Caltrop - actor definition language
SourceForge NiceXSL - friendly front end for XSLT
Eclipse GMT - UMLX graphical transformation ideas
Eclipse OMELET - transformation integration - MDDI
Eclipse GMT - UMLX realisation

4. 3 May 2006 Model Transformation - A Personal Perspective 4
Experience
●
Embedded Signal Processing
− Comparatively simple code
●
Simple programming techniques
●
Prejudice for efficient languages
− Slow to move from assembler to C to C++
− Very reluctant to accept Java
− Comparatively complex architectures
●
Numerous communicating subsystems
− Diagrams always important to explain behaviour
●
Mainstream Programming
− Comparatively complex code
− Comparatively simple architectures
●
But Embedded world now wants
− Complex code – protocol stacks ...
●
But Mainstream world now wants
− Complex architectures – networks, threads ...

5. 3 May 2006 Model Transformation - A Personal Perspective 5
Basic Analogue Circuit
●
Transistor Amplifier
− each graphical element is almost a physical element

6. 3 May 2006 Model Transformation - A Personal Perspective 6
Hierarchical Analogue Circuit
●
Op Amp
 high level symbol to control complexity

7. 3 May 2006 Model Transformation - A Personal Perspective 7
Analogue Computer
More Abstract – Model - Sinewave generator
 continuous time, continuous level

8. 3 May 2006 Model Transformation - A Personal Perspective 8
Systems

9. 3 May 2006 Model Transformation - A Personal Perspective 9
Block Diagrams
●
Low, medium or high level
●
Friendly
 Convey an apparently simple meaning
 Open to review
●
Each element
 Independent
 continuously operating

10. 3 May 2006 Model Transformation - A Personal Perspective 10
Continuous Time
appropriate model for
− audio, radio, ... continuous signals
inappropriate model for
− sporadic events
− push buttons
− GUI interactions
− power failures
− interrupts
− protocol messages
− video, ... sampled signals
dedicated resource
− always processing
− 'infinite' power processing element

11. 3 May 2006 Model Transformation - A Personal Perspective 11
Discrete Time
●
shared resource
− process occasionally
− finite processing element
●
discrete time suitable for digital computers
− predictable, reliable, ...
●
continuous time impossible on digital computers
− create an illusion of continuous time
●
high enough sample rate (Nyquist)
●
Two practical forms of discrete time
− sporadic events/messages
●
state machines/protocols
− regular samples/tokens
●
Digital Signal Processing

12. 3 May 2006 Model Transformation - A Personal Perspective 12
Block Diagram Semantics
●
computation
− easy, only software
●
{inputs, state} -> {outputs, state'}
− soluble in most languages
●
communication
− collaboration between sender and receiver
− soluble in few languages
Block Block Block
inputs outputs
state

13. 3 May 2006 Model Transformation - A Personal Perspective 13
Function Modelling
●
An unsuccessful
area for graphics
− Program
Flowcharts
− Schlaer-Mellor
flow diagrams
− SDL

14. 3 May 2006 Model Transformation - A Personal Perspective 14
Transformations as Program Steps
●
Generic state-based transaction
state state'
Mx
inputs outputs
state state'
inputs[constraint]/outputs

15. 3 May 2006 Model Transformation - A Personal Perspective 15
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

16. 3 May 2006 Model Transformation - A Personal Perspective 16
Trivial Deadlock
●
Oops
− both waiting for inputs
− neither generating output
●
Deadlock (with just 2 components!)
BlockA
inputs outputs
state
BlockB
inputs outputs
state

17. 3 May 2006 Model Transformation - A Personal Perspective 17
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 ??

18. 3 May 2006 Model Transformation - A Personal Perspective 18
The MDA Y
PSM
what actually gets done -- the code
Platform
Independent
Model
Platform
Specific
Model
Platform
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

19. 3 May 2006 Model Transformation - A Personal Perspective 19
The less publicised MDA Y
MM - the manual intervention, so that
PSM - the 100% autogenerated solution
●
do the JPEG on the graphics processor
●
use a non-reentrant QuickSort algorithm for ...
●
use TCP to satisfy transmission guarantees
PIM
PSM
Platform
Model
Platform
Model
Mark
'Model'

20. 3 May 2006 Model Transformation - A Personal Perspective 20
Some Specification-based Problems
●
Types
− missing type inference
− type checking
− implementation type selection
●
Computation
− algorithms
●
Communications
− protocol/route/speed/...
●
Scheduling
− Heavyweight/lightweight/no OS/...
− priority/schedule
●
Partitioning
− processor type/choice/count/configuration
− activity to 'process' to processor allocation

21. 3 May 2006 Model Transformation - A Personal Perspective 21
The Aspect Oriented Y
Transformations
much too complex
for one pass
Multiple passes
variously
DS(V)L or UML
CIM
PIM
PSM
Code
PIMa PMaMMa
Concern A
PIMb PMbMMb
Concern B
PIMc PMcMMc
Concern C
PIMd PMdMMd
Concern D
PSM

22. 3 May 2006 Model Transformation - A Personal Perspective 22
Transformations Everywhere
[... from requirements
via vague specification
to executable specification]
●
Hundreds of transformations from:
− executable specification to implementation (code)
●
Code to executable
− currently hidden inside compilers
− could be exposed as hundreds of transformations
●
could then be customised for special purposes
●
could be optimised one transformation at a time

23. 3 May 2006 Model Transformation - A Personal Perspective 23
Future Challenges
●
Today
− single fully functional transformation difficult
●
ATL (First committed to CVS 5-Nov-2004)
− increasing utility, annual workshop/conference
− significant scaleability limitations
− first meta-model/transformation library (zoo)
●
VIATRA2 (One-off commit to CVS 20-Oct-2005)
− significant 'local' usage
●
QVT - ? coming soon ?
●
Tomorrow
− multiple transformations common-place
− effective usage will be the problem

24. 3 May 2006 Model Transformation - A Personal Perspective 24
●
meta-models defines the information content
●
models conform to their meta-model
Meta-Model Semantics
Ma Mb
MMa MMb
MMx
in out
usesuses
conforms to
conforms to
MOF
Mx

25. 3 May 2006 Model Transformation - A Personal Perspective 25
●
Mx author has detailed knowledge of MMa and MMb
− knows that
●
days of month count from 1
●
days of week count from 0 and that 0 is Sunday
●
name is a Java identifier and so cannot be “class”
●
negative numbers use parentheses
●
pressure is in foot-pounds
Single-Use Custom Transformation
Ma Mb
MMa MMb
MMx
in out
usesuses
Mx

26. 3 May 2006 Model Transformation - A Personal Perspective 26
Mx
Multiple Re-usable Transformations
Ma Mb
MMa MMb
MMx
in out
usesuses
Mb' Mc
MMb' MMc
My
MMy
in out
usesuses
MMb ≡ MMb' ?
Mb ≡ Mb' ?

27. 3 May 2006 Model Transformation - A Personal Perspective 27
Compatible Transformations
●
MMb ≡ MMb', Mb ≡ Mb'
− transformations can be cascaded
− no problem
− never going to happen universally
Ma Mb
MMa MMb
MMx
in out
usesuses
Mc
MMc
MMy
in out
usesuses
Mx My

28. 3 May 2006 Model Transformation - A Personal Perspective 28
Incompatible Transformations
●
MMb ≠ MMb' or Mb ≠ Mb'
 run-time: need a further transformation Mz
 compile-time: need to know that we need a further
transformation Mz -- type checking
Ma Mb
MMa MMb
MMx
in out
uses
uses
Mb' Mc
MMb' MMc
MMy
in out
uses
uses
MMz
uses
uses
outin
Mx MyMz

29. 3 May 2006 Model Transformation - A Personal Perspective 29
Model incompatibilites
●
MMb ≡ MMb', Mb ≠ Mb'
− Location
●
repository / file system
− Format
●
XML / textual
− Version
●
XMI 1.x / XMI 2.y
− Medium
●
File / Stream / DOM / EMF / ..
.
●
Soluble with libraries of conversion transformations
− no conversion of meta-model semantics is performed
− just a conversion/movement of model representation

30. 3 May 2006 Model Transformation - A Personal Perspective 30
OMELET solution
●
Transformations typed with an interface signature:
− Mx transformation model: Java
●
input model: DOM representation of MMa
●
output model: OutputStream representation of MMb
 My transformation model: XSLT2
●
input model: InputFile representation of MMb
●
output model: OutputStream representation of MMc
●
OMELET deduced from conversion library
− Mz transformation model: Java
●
input model: OutputStream representation of MMb
●
output model: InputFile representation of MMb

31. 3 May 2006 Model Transformation - A Personal Perspective 31
Meta-Model incompatibilities
●
Conversions of representations/locations are easy
●
Conversion of semantics is important
− but only where sensible
− banking models and atomic models are incompatible
●
Mappings
− 1:1 correspondences with trivial changes
●
Semantics rewrites
− more substantial changes
●
Should be checkable
●
Should be auto-generatable

32. 3 May 2006 Model Transformation - A Personal Perspective 32
The Re-usability problem again
●
If any aspect of MMb to MMb' relationship not
machine processable:
− need manual assertion/selection of Mx then My
●
Just another form of uncheckable programming
●
∴ every aspect of MMb to MMb' defined
Mx
Ma Mb
MMa MMb
MMx
in out
usesuses
Mb' Mc
MMb' MMc
My
MMy
in out
usesuses

33. 3 May 2006 Model Transformation - A Personal Perspective 33
Semantic Domains
Each semantic element needs its own meta-model
− some very simple:
●
Numeric unit meta-model
 scale factor with respect to an SI standard for units
●
Name spelling meta-model
 regular expressions
●
Name scoping and hierarchy meta-model
 predicate logic for ...
●
Each domain uses an appropriate mathematics
●
In so far as possible each domain is orthogonal
− spelling convention for employee names independent
of responsibilities of each job

34. 3 May 2006 Model Transformation - A Personal Perspective 34
Not so Simple Domains
●
Even numbers are not-trivial
− scale factor /unit
− maximum/minimum values
− resolution
− accuracy/precision/distribution
− overflow behaviour
− rounding/underflow behaviour
●
Meta-model may be relatively vague
− just a length
●
System specification (PIM) may imply
− maximum/resolution
●
Mark model may impose
− precision
●
Platform Model may offer
− types with maximum/minimum/resolution/...

35. 3 May 2006 Model Transformation - A Personal Perspective 35
Really not Simple Domains
●
Fowler: Analysis Patterns ...
●
Number becomes a Measurement
− what - the measurement
− who - the operator/equipment
− when - time ..
− where ...
− why - in response to request ...
− validated by ...
− ...

36. 3 May 2006 Model Transformation - A Personal Perspective 36
Semantic Domain Resolution
●
Semantic conversions can be automated
− Fahrenheit to Centigrade
− Name mangling policy for illegal names
●
C++ identifiers in C are marginally readable
●
With a defined semantic language
− conversion transformations for each semantic

37. 3 May 2006 Model Transformation - A Personal Perspective 37
Custom Semantics
●
Different 'enterprises' have special requirements
− banking
●
no lost fractional pennies/cents - COBOL
− security
●
no confusion of red/black data
●
data independent execution time
●
erasure of all temporary memory
●
minimised parasitic radio emissions
− integrity
●
guaranteed response time
●
guaranteed sub-system independence
− system
●
low power consumption/size/...

38. 3 May 2006 Model Transformation - A Personal Perspective 38
Subset Semantics Requirement
●
Ideally transformations proven to be applicable
− to all possible input models
●
Pragmatically transformations may be applicable
− to many useful input models
●
For instance
− 'UML to RDBMS'
●
only applies to UML classes
●
definitely not applicable to UML use cases
●
dubiously applicable to UML inheritance
− 'UML to Java'
●
not applicable for certain class names

39. 3 May 2006 Model Transformation - A Personal Perspective 39
Subset Semantics Solution
●
Mx is not valid for all Ma:MMa -> Mb:MMb
− is it valid for Mc:MMc where MMc ⊂ MMa ?
●
Proof of applicability
− ? semantic meta-models
●
Sub-set applicability
− can be defined by a sub-set meta-model
●
UML except {use cases ...}
●
MMc = MMa - ...
− can be defined by a constrained meta-model
●
UML except certain names to satisfy Java semantics
●
MMc = MMa ⋂ ...
− requires support for meta-model refinement
●
MOF package merge ...
●
MMc = MMa ⋃ ...

40. 3 May 2006 Model Transformation - A Personal Perspective 40
Extensible Semantics
●
One commonality between different requirements
− all different
●
Custom tools for each requirement undesirable
− COBOL
●
Need to extend existing tools to new semantics
− not rewrite for each new semantic

41. 3 May 2006 Model Transformation - A Personal Perspective 41
Semantic Satisfaction
●
Characterise
each semantic property for each transformation :
− each property is
●
established/destroyed/preserved/undefined
by each transformation
●
Satisfactory chain ends
− {don't care}*, establish, {preserve}*
for each required property
●
Given the source models (and meta-models)
a library of transformations
required properties
− valid transformation chain can be deduced

42. 3 May 2006 Model Transformation - A Personal Perspective 42
Efficient composition
●
Single Transformations
− potentially inefficient
●
arbitrary pattern matching
●
amenable to pragmatic constrained approaches
●
Cascades of hundreds of transformations
− potentially very very inefficient
●
numerous intermediate models
− potentially very efficient
●
semantics/intent of declarative transformations known
●
multiple transformation 'passes' can be combined
●
Graph Transformation Theory can prove validity
− slow execution instantly
− fast execution after optimised composition
●
custom compiler

43. 3 May 2006 Model Transformation - A Personal Perspective 43
Summary
●
Different programming worlds converging on MDA
●
Todays problems should become irrelevant
●
Tomorrows problems look interesting
− are Tx's the new programming language?
− are Tx chains deducible?
− is reusable software finally going to happen?