Model Transformation A Personal Perspective

Model TransformationA Personal Perspective

Edward D. [email protected]

GMT Consortiumwww.eclipse.org

also Thales Research and Technology (UK)[email protected]

AMMA 2006

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


BackgroundElectronic Engineer

Racal Research -> Thomson CSF Racal -> Thales Research and Technology

DSP, DSP toolsWDL specification language proposal

Computer ScientistPhD - better DSP tools

DSP compiler optimisationMeta-compilation for C++

Open SourcePtolemy Caltrop - actor definition languageSourceForge NiceXSL - friendly front end for XSLTEclipse GMT - UMLX graphical transformation ideasEclipse OMELET - transformation integration - MDDIEclipse GMT - UMLX realisation


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 ...


Basic Analogue Circuit

● Transistor Amplifier each graphical element is almost a physical element


Hierarchical Analogue Circuit

● Op Amp high level symbol to control complexity


Analogue Computer

More Abstract – Model - Sinewave generator continuous time, continuous level


Systems


Block Diagrams● Low, medium or high level

● Friendly Convey an apparently simple meaning Open to review

● Each element Independent continuously operating


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


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


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 Blockinputs outputs

state


Function Modelling● An unsuccessful

area for graphics Program

Flowcharts Schlaer-Mellor

flow diagrams SDL


Transformations as Program Steps

● Generic state-based transaction

state state'

Mx

inputs outputs

state state'

inputs[constraint]/outputs


Component Oriented Communications

● provide a sink/source

loop foreverwait till inputs availableget inputscompute outputs and update stateput outputs

Blockinputs outputs

state


Trivial Deadlock

● Oops both waiting for inputs neither generating output

● Deadlock (with just 2 components!)

BlockAinputs outputs

state

BlockBinputs outputs

state


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 ??


The MDA Y

PSMwhat actually gets done -- the code

PlatformIndependent

Model

PlatformSpecific Model

Platform Model

Platform Model

PIM

what needsto be done

program/application models

what resourcesare available

program/algorithm/applicationlibraries

hardware/operating systemdefinition models


The less publicised MDA Y

MM - the manual intervention, so thatPSM - 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'


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


The Aspect Oriented Y

Transformations much too complex for one pass

Multiple passes variouslyDS(V)L or UMLCIMPIMPSMCode

PIMa PMaMMa

Concern A

PIMb PMbMMb

Concern B

PIMc PMcMMc

Concern C

PIMd PMdMMd

Concern D

PSM


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


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


● 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


● 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


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' ?


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


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

outinMx MyMz


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


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


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


The Re-usability problem again

● If any aspect of MMb to MMb' relationship notmachine 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


Semantic DomainsEach 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 independentof responsibilities of each job


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/...


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 ... ...


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


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/...


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


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 ⋃ ...


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


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 transformationsrequired properties valid transformation chain can be deduced


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


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?

Model Transformation A Personal Perspective

Technology

Transcript of Model Transformation A Personal Perspective