Megamodels of Programming Technologies

(1)

Megamodels of

Programming Technologies

Ralf Lämmel and Andrei Varanovich

Software Languages Team

University of Koblenz-Landau

Germany

Acknowledgement: Scientific co

_{llaboration with inspiration}

from Dragan Gasevic and Jean-M

_{arie Favre. Thanks also to}

(2)

(3)

We have

a problem.

EMF

SQL

TENEO

Java

XSD

DOM

Antlr

OWL

UML

XMI

Ecore

SQL DDL

XLST

Saxon

Hibernate

Awk

Json

Yacc

JAXP

Rest

OWL

RDF

ATOM

SparQL

XSLT

DTD

BNF

XSD

OCL

Prolog

grep

MOF

OMG

QVT

jDOM

Rose

Protegé

XQuery

ODM

XMLSpy

JPA

JAXB

JDBC

ODBC

MySQL

ArgoUML

Jean

Jena

Ralf

Dragan

TXL

VLDB

EMF.gen

ORACLE

TCS

XText

Teneo

Jersey

GWT

Sesame

Stratego

XPATH

JeanBeans

UTF8

ASCII

RDFa

RDF(S)

RDFS

CFG

LALR

ER

SLE2010

xerces

xalan

saxon

sax

sed

XSD

JMI

JMF

SBVR

(4)

EMF

SQL

TENEO

Java

XSD

DOM

Antlr

OWL

UML

XMI

Ecore

SQL DDL

XLST

Saxon

Hibernate

Awk

Json

Yacc

JAXP

Rest

OWL

RDF

ATOM

SparQL

XSLT

DTD

BNF

XSD

OCL

Prolog

grep

MOF

OMG

QVT

jDOM

Rose

Protegé

XQuery

ODM

XMLSpy

JPA

JAXB

JDBC

ODBC

MySQL

ArgoUML

Jean

Jena

Ralf

Dragan

TXL

VLDB

EMF.gen

ORACLE

TCS

XText

Teneo

Jersey

GWT

Sesame

Stratego

XPATH

JeanBeans

UTF8

ASCII

RDFa

RDF(S)

RDFS

CFG

LALR

ER

SLE2010

xerces

xalan

saxon

sax

sed

XSD

JMI

JMF

SBVR

Issues with

programming technologies

• Silos of knowledge

• Combining technologies

• Complexity of technologies

• Entering a new space

(5)

Why would you study computer science,

if your ultimate destiny is

to

_{get lost in space and technology}

?

(6)

Popular faculty opinion 1

Practice is terribly complex.

University should not bother.

(7)

Popular faculty opinion 2

Practice is too complex.

University can not bother.

(8)

Popular faculty opinion 3

Practice is incidentally complex.

University must not bother.

(9)

Proposed opinion shift

Practice is amazingly complex and does not go away.

(10)

EMF

SQL

TENEO

Java

XSD

DOM

Antlr

OWL

UML

XMI

Ecore

SQL DDL

XLST

Saxon

Hibernate

Awk

Json

Yacc

JAXP

Rest

OWL

RDF

ATOM

SparQL

XSLT

DTD

BNF

XSD

OCL

Prolog

grep

MOF

OMG

QVT

jDOM

Rose

Protegé

XQuery

ODM

XMLSpy

JPA

JAXB

JDBC

ODBC

MySQL

ArgoUML

Jean

Jena

Ralf

Dragan

TXL

VLDB

EMF.gen

ORACLE

TCS

XText

Teneo

Jersey

GWT

Sesame

Stratego

XPATH

JeanBeans

UTF8

ASCII

RDFa

RDF(S)

RDFS

CFG

LALR

ER

SLE2010

xerces

xalan

saxon

sax

sed

XSD

JMI

JMF

SBVR

• Silos of knowledge

• Combining technologies

• Complexity of technologies

• Entering a new space

• Teaching technologies?

Issues with

programming technologies

• Analogy

• Examples

• Abstraction

Our Approach

(11)

Analogy

, examples, abstraction

MOF

XSD

RDFS

SQL.DDL

EBNF

OCL

XPath

QVT

XQuery

SPARQL

SQL

Protégé

Topbeard

XMLSpy

VS-XML

ArgoUML

Rose

MySQL

Oracle

XSLT

TXL

ASF

MetaEnv.

XML

VLDB

MoDELS

ECMDA

ICSW

ESWC

VLDB

SIGMOD

CC

POPL

language

Navigation

Query

Transfo.

Toolkit

Conferences

(12)

Sesame

Analogy

in space travel

XMI

modelware

XMLware

javaware

JDBC

Dataware

JDOM

Ontware

Jena

Hibernate

EMF.gen

JMI

Teneo

_JAXB

JPA

(13)

Analogy,

examples

, abstraction

company "meganalysis" {

!

department "Research" {

!

manager "Craig" {

!

address "Redmond"

!

salary 123456

!

}

!

employee "Erik" {

!

address "Utrecht"

!

salary 12345

!

}

!

employee "Ralf" {

!

address "Koblenz"

!

salary 1234

!

}

!

}

!

department "Development" {

!

manager "Ray" {

!

address "Redmond"

!

salary 234567

!

}

...

Total

salaries

Cut

Store

companies

Navigate

(14)

Total salaries in XQuery

Cut salaries in SQL DML

UPDATE employee

SET salary = salary / 2;

{sum(//salary)}

</result>

(15)

Variation points for examples

X vs. O vs. R vs.

λ

etc.

Static typing vs. dynamic typing

Textual vs. abstract vs. visual syntax

GPPL vs. DSL vs. embedding vs. API

Instance- vs. operation-based mapping

Type checking vs. inference vs. reasoning

Code first vs. schema first vs. mapping only

In-memory processing vs. push vs. pull parsing

Pure vs. impure transformations (or in between)

Code vs. generative vs. model-driven vs. mapping

(16)

Analogy, examples,

abstraction

What’s the taxonomy of programming technologies?

What’s the

_essence

of technology

xyz

?

(17)

(18)

Abstraction with megamodels

An XSLT transformation

(19)

Remember

Tombstone diagrams?

http://en.wikipedia.org/wiki/T-diagram

"Used for describing

complicated processes for

bootstrapping, porting, and

self-compiling of compilers,

interpreters, and

(20)

(21)

(22)

Selected programming technologies

JDBC: Generic database access with Java

Hibernate: Object/relational mapping with Java

JAXB: XML-data binding with Java

xsd.exe, too: Typed database access with .NET

Entity Framework: Object/relational mapping with .NET

xsd.exe: XML-data binding with .NET

(23)

Selected 101companies implementations

101implementation:jdbc

101implementation:hibernate

101implementation:jaxbComposition

101implementation:xsdDataSet

101implementation:ef

101implementation:xsdClasses

(24)

(25)

Running example:

XML-data binding for C# with xsd.exe

Involved entities: languages, artifacts, and technologies

Relationships between those entities

Additional aspects:

Use generated classes

Runtime de-serialization

XML transformation

(26)

Involved languages

2 Ralf L¨

ammel and Andrei Varanovich

function) [[

· ]] :

S

→

(

U

→

B

) where

U

⊇

L

is again a suitable universe (in fact,

a language) from which to draw elements for inquiring membership for

L

and

B

denotes the Boolean value domain

_{

T

,

F

_}

. Thus, the generalized solution to the

membership problem for

L

⊆

U

specified by

s

∈

S

is stated as follows:

∀

x

_∈

U. x

_∈

L

_⇐⇒

[[

s

]]

x

=

T

For instance, a context-free grammar

G

is interpreted as follows:

[[

G

]]

x

=

�

T

,

if

root

(

G

)

_⇒

+

_G

x

F

,

otherwise

Inspired by the grammar view, we also say that [[

s

]] denotes an acceptor for

L

.

Any acceptor for

L

with associated universe

U

⊇

L

should be a function of type

U

_→

B

. Among all conceivable acceptors, [[

s

]] stands out by being essentially

derived from a specification. In practice, we may indeed consider acceptors that

are essentially black boxes, i.e., they are not declared to be derived from a

specification. For instance, a parser in a compiler may be handwritten or its

status may simply be unknown.

3 Megamodels

Megamodels

mm

= (“

import

”

name

)

∗

“

megamodel

”

name

“

_{

”

dec

∗

“

}

”

Declarations

dec

= “

language

”

name

|

“

artifact

”

name

|

name rel name

|

“

constraint

”

name

“:”

name

+

|

“

transformation

”

name

“:”

name

+

“

_→

”

name

Relationships

rel

= “

_∈

”

_|

“

_⊂

”

_|

“

_⊆

”

_{| · · ·}

Languages involved in XML-data binding for C# with

xsd.exe

:

language

C

#

language

XSD

Artifacts involved in XML-data binding for C# with

xsd.exe

:

artifact

aSchema

artifact

anObjectModel

artifact

aProgram

aSchema

_∈

XSD

anObjectModel

_∈

C

#

aProgram

_∈

C

#

(27)

Involved artifacts

(part I)

3 language

C

#

language

XSD

Artifacts:

artifact

aSchema

artifact

anObjectModel

aSchema

_∈

XSD

anObjectModel

_∈

C

#

Technology:

transformation

xsd

.

exe

:

XSD

_→

C

#

Relationships:

xsd

.

exe

(

aSchema

)

_�→

anObjectModel

The aspect of using the generated classes:

artifact

aProgram

_∈

C

#

constraint

uses

:

C

#

_×

C

#

uses

(

aProgram

,

anObjectModel

)

The aspect of runtime de-serialization:

language

XML

language

RuntimeObjects

transformation

XmlSerializer

.

Deserialize

:

XML

_→

RuntimeObjects

anXmlDoc

_∈

XML

anObject

_∈

RuntimeObjects

anXmlDoc

:

aSchema

anObject

:

anObjectModel

XmlSerializer

.

Deserialize

(

anXmlDoc

)

�→

anObject

The aspect of XML transformation through objects:

constraint

a

ﬀ

ects

:

C

#

_×

RuntimeObjects

transformation

XmlSerializer

.

Serialize

:

RuntimeObjects

_→

XML

anXmlDoc

�

_∈

XML

anXmlDoc

�

:

aSchema

a

ﬀ

ects

(

aProgram

,

anObject

)

(28)

The

xsd

_.

exe

class generator

(Involved technology (part I))

3 language

C

#

language

XSD

Artifacts:

artifact

aSchema

artifact

anObjectModel

aSchema

_∈

XSD

anObjectModel

_∈

C

#

Technology:

transformation

xsd

.

exe

:

XSD

_→

C

#

Relationships:

xsd

.

exe

(

aSchema

)

_�→

anObjectModel

The aspect of using the generated classes:

artifact

aProgram

_∈

C

#

constraint

uses

:

C

#

_×

C

#

uses

(

aProgram

,

anObjectModel

)

The aspect of runtime de-serialization:

language

XML

language

RuntimeObjects

transformation

XmlSerializer

.

Deserialize

:

XML

_→

RuntimeObjects

anXmlDoc

_∈

XML

anObject

_∈

RuntimeObjects

anXmlDoc

:

aSchema

anObject

:

anObjectModel

XmlSerializer

.

Deserialize

(

anXmlDoc

)

_�→

anObject

The aspect of XML transformation through objects:

constraint

a

ﬀ

ects

:

C

#

_×

RuntimeObjects

transformation

XmlSerializer

.

Serialize

:

RuntimeObjects

_→

XML

anXmlDoc

�

_∈

XML

anXmlDoc

�

:

aSchema

a

ﬀ

ects

(

aProgram

,

anObject

)

XmlSerializer

.

Serialize

(

anObject

)

�→

anXmlDoc

�

3 Artifacts:

artifact

aSchema

artifact

anObjectModel

aSchema

_∈

XSD

anObjectModel

_∈

C

#

Technology:

transformation

xsd

.

exe

:

XSD

_→

C

#

Relationships:

xsd

.

exe

(

aSchema

)

_�→

anObjectModel

The aspect of using the generated classes:

artifact

aProgram

_∈

C

#

constraint

uses

:

C

#

×

C

#

uses

(

aProgram

,

anObjectModel

)

Runtime (de-)serialization:

(29)

Language acceptors

(Involved technology (part II))

3 def

= (“

_∀

”

name

“

_∈

”

name

“

.

”)

+

rel

“=

_def

”

rel

Languages involved in XML-data binding for C# with

xsd.exe

:

language

C

#

language

XSD

Artifacts:

artifact

aSchema

artifact

anObjectModel

aSchema

_∈

XSD

anObjectModel

_∈

C

#

Technology:

transformation

xsd

.

exe

:

XSD

_→

C

#

Relationships:

xsd

.

exe

(

aSchema

)

_�→

anObjectModel

Language acceptors:

language

Any

constraint

acceptXsd

.

exe

:

Any

constraint

acceptCsharp

.

exe

:

Any

∀

x

_∈

Any

. x

_∈

XSD

=

_def

acceptXsd

.

exe

(

x

)

∀

x

_∈

Any

. x

_∈

C

# =

_def

acceptCsharp

.

exe

(

x

)

The aspect of using the generated classes:

artifact

aProgram

_∈

C

#

constraint

uses

:

C

#

_×

C

#

uses

(

aProgram

,

anObjectModel

)

The aspect of runtime de-serialization:

language

XML

language

RuntimeObjects

transformation

XmlSerializer

.

Deserialize

:

XML

_→

RuntimeObjects

anXmlDoc

_∈

XML

anObject

_∈

RuntimeObjects

anXmlDoc

:

aSchema

anObject

:

anObjectModel

(30)

The aspect of

using the generated classes

3 language

C

#

language

XSD

Artifacts:

artifact

aSchema

artifact

anObjectModel

aSchema

_∈

XSD

anObjectModel

_∈

C

#

Technology:

transformation

xsd

.

exe

:

XSD

_→

C

#

Relationships:

xsd

.

exe

(

aSchema

)

_�→

anObjectModel

The aspect of using the generated classes:

artifact

aProgram

_∈

C

#

constraint

uses

:

C

#

_×

C

#

uses

(

aProgram

,

anObjectModel

)

The aspect of runtime de-serialization:

language

XML

language

RuntimeObjects

transformation

XmlSerializer

.

Deserialize

:

XML

_→

RuntimeObjects

anXmlDoc

_∈

XML

anObject

_∈

RuntimeObjects

anXmlDoc

:

aSchema

anObject

:

anObjectModel

XmlSerializer

.

Deserialize

(

anXmlDoc

)

_�→

anObject

The aspect of XML transformation through objects:

constraint

a

ﬀ

ects

:

C

#

_×

RuntimeObjects

transformation

XmlSerializer

.

Serialize

:

RuntimeObjects

_→

XML

anXmlDoc

�

_∈

XML

anXmlDoc

�

:

aSchema

a

ﬀ

ects

(

aProgram

,

anObject

)

(31)

The aspect of

runtime de-serialization

3 language

C

#

language

XSD

Artifacts:

artifact

aSchema

artifact

anObjectModel

aSchema

_∈

XSD

anObjectModel

_∈

C

#

Technology:

transformation

xsd

.

exe

:

XSD

_→

C

#

Relationships:

xsd

.

exe

(

aSchema

)

_�→

anObjectModel

The aspect of using the generated classes:

artifact

aProgram

_∈

C

#

constraint

uses

:

C

#

_×

C

#

uses

(

aProgram

,

anObjectModel

)

The aspect of runtime de-serialization:

language

XML

language

RuntimeObjects

transformation

XmlSerializer

.

Deserialize

:

XML

_→

RuntimeObjects

anXmlDoc

_∈

XML

anObject

_∈

RuntimeObjects

anXmlDoc

:

aSchema

anObject

:

anObjectModel

XmlSerializer

.

Deserialize

(

anXmlDoc

)

_�→

anObject

The aspect of XML transformation through objects:

constraint

aﬀects

:

C

#

_×

RuntimeObjects

transformation

XmlSerializer

.

Serialize

:

RuntimeObjects

_→

XML

anXmlDoc

�

_∈

XML

anXmlDoc

�

:

aSchema

aﬀects

(

aProgram

,

anObject

)

(32)

The aspect of

XML transformation

3 language

C

#

language

XSD

Artifacts:

artifact

aSchema

artifact

anObjectModel

aSchema

_∈

XSD

anObjectModel

_∈

C

#

Technology:

transformation

xsd

.

exe

:

XSD

_→

C

#

Relationships:

xsd

.

exe

(

aSchema

)

_�→

anObjectModel

The aspect of using the generated classes:

artifact

aProgram

_∈

C

#

constraint

uses

:

C

#

_×

C

#

uses

(

aProgram

,

anObjectModel

)

The aspect of runtime de-serialization:

language

XML

language

RuntimeObjects

transformation

XmlSerializer

.

Deserialize

:

XML

_→

RuntimeObjects

anXmlDoc

_∈

XML

anObject

_∈

RuntimeObjects

anXmlDoc

:

aSchema

anObject

:

anObjectModel

XmlSerializer

.

Deserialize

(

anXmlDoc

)

_�→

anObject

The aspect of XML transformation through objects:

constraint

a

ﬀ

ects

:

C

#

_×

RuntimeObjects

transformation

XmlSerializer

.

Serialize

:

RuntimeObjects

_→

XML

anXmlDoc

�

_∈

XML

anXmlDoc

�

:

aSchema

a

ﬀ

ects

(

aProgram

,

anObject

)

(33)

The aspect of

a constrained target language:

4 Ralf L¨

ammel and Andrei Varanovich

The aspect of XML transformation:

constraint

a

ﬀ

ects

:

C

#

_×

RuntimeObjects

transformation

XmlSerializer

.

Serialize

:

RuntimeObjects

_→

XML

anXmlDoc

�

_∈

XML

anXmlDoc

�

:

aSchema

a

ﬀ

ects

(

aProgram

,

anObject

)

XmlSerializer

.

Serialize

(

anObject

)

_�→

anXmlDoc

�

The aspect of a constrained target language:

constraint

O

/

X

:

C

#

O

/

X

(

anObjectModel

)

An alternative form of expression:

language

C

#

₋

O

/

X

C

#

₋

O

/

X

_⊂

C

#

anObjectModel

_∈

C

#

₋

O

/

X

Query language-based definition of target language:

language

C

#

₋

QL

constraint

C

#

₋

QL

₋

interpreter

:

C

#

₋

QL

_×

C

#

ox

.

csharpQl

_∈

C

#

₋

QL

∀

x

_∈

C

#

. x

_∈

C

#

₋

O

/

X

=

_def

C

#

₋

QL

₋

interpreter

(

ox

.

csharpQl

, x

)

Megamodel for the query language:

language

PT

-- Prolog terms

language

PTG

-- Prolog term grammars

constraint

PTG

₋

acceptor

:

PTG

_×

PT

artifact

csharpQl

.

ptg

-- a grammar for

C

#

₋

QL

csharpQl

.

ptg

_∈

PTG

∀

x

_∈

PT

. x

:

csharpQl

.

ptg

=

_def

PTG

₋

acceptor

(

csharpQl

.

ptg

, x

)

∀

x

_∈

PT

. x

_∈

C

#

₋

QL

=

_def

x

:

csharpQl

.

ptg

4 Ralf L¨

ammel and Andrei Varanovich

The aspect of XML transformation:

constraint

a

ﬀ

ects

:

C

#

_×

RuntimeObjects

transformation

XmlSerializer

.

Serialize

:

RuntimeObjects

_→

XML

anXmlDoc

�

_∈

XML

anXmlDoc

�

:

aSchema

a

ﬀ

ects

(

aProgram

,

anObject

)

XmlSerializer

.

Serialize

(

anObject

)

_�→

anXmlDoc

�

The aspect of a constrained target language:

constraint

O

/

X

:

C

#

O

/

X

(

anObjectModel

)

An alternative form of expression:

language

C

#

₋

O

/

X

C

#

₋

O

/

X

_⊂

C

#

anObjectModel

_∈

C

#

₋

O

/

X

Query language-based definition of target language:

language

C

#

₋

QL

constraint

C

#

₋

QL

₋

interpreter

:

C

#

₋

QL

_×

C

#

ox

.

csharpQl

_∈

C

#

₋

QL

∀

x

_∈

C

#

. x

_∈

C

#

₋

O

/

X

=

_def

C

#

₋

QL

₋

interpreter

(

ox

.

csharpQl

, x

)

Megamodel for the query language:

language

PT

-- Prolog terms

language

PTG

-- Prolog term grammars

constraint

PTG

₋

acceptor

:

PTG

_×

PT

artifact

csharpQl

.

ptg

-- a grammar for

C

#

₋

QL

csharpQl

.

ptg

_∈

PTG

∀

x

_∈

PT

. x

:

csharpQl

.

ptg

=

_def

PTG

₋

acceptor

(

csharpQl

.

ptg

, x

)

∀

x

_∈

PT

. x

_∈

C

#

₋

QL

=

_def

x

:

csharpQl

.

ptg

Alternatively:

(34)

Query language-based

definition of target language

4 Ralf L¨

ammel and Andrei Varanovich

The aspect of XML transformation:

constraint

a

ﬀ

ects

:

C

#

_×

RuntimeObjects

transformation

XmlSerializer

.

Serialize

:

RuntimeObjects

_→

XML

anXmlDoc

�

_∈

XML

anXmlDoc

�

:

aSchema

a

ﬀ

ects

(

aProgram

,

anObject

)

XmlSerializer

.

Serialize

(

anObject

)

_�→

anXmlDoc

�

The aspect of a constrained target language:

constraint

O

/

X

:

C

#

O

/

X

(

anObjectModel

)

An alternative form of expression:

language

C

#

₋

O

/

X

C

#

₋

O

/

X

_⊂

C

#

anObjectModel

_∈

C

#

₋

O

/

X

Query language-based definition of target language:

language

C

#

₋

QL

constraint

C

#

₋

QL

₋

evaluator

:

C

#

₋

QL

_×

C

#

ox

.

csharpQl

_∈

C

#

₋

QL

∀

x

_∈

C

#

. x

_∈

C

#

₋

O

/

X

=

_def

C

#

₋

QL

₋

evaluator

(

ox

.

csharpQl

, x

)

Megamodel for the query language:

language

PT

-- Prolog terms

language

PTG

-- Prolog term grammars

constraint

runPtg

.

pro

:

PTG

_×

PT

artifact

csharpQl

.

ptg

-- a grammar for

C

#

₋

QL

csharpQl

.

ptg

_∈

PTG

∀

x

_∈

PT

. x

:

csharpQl

.

ptg

=

_def

runPtg

.

pro

(

csharpQl

.

ptg

, x

)

(35)

ox.csharpQl

and([

or(map(

match('This source code was auto-generated by xsd'),

collect(comment))),

not(null(collect(attribute('System.Xml.Serialization.*')))),

and(map(

test(classDeclaration),

collect(typeDeclaration))),

null(collect(methodDeclaration)),

and(map(

not(null(attribute('System.SerializableAttribute'))),

collect(classDeclaration)

))

]).

(36)

bquery(not(B)) :- bquery(B).

bquery(and(Bs)) :- queries(Bs).

bquery(or(Bs)) :- queries(Bs).

bquery(null(L)) :- lquery(L).

bquery(test(S)) :- sort(S).

bquery(match(A)) :- atom(A).

queries(Bs) :- star(bquery,Bs).

queries(map(B,L)) :- bquery(B), lquery(L).

lquery(S) :- sort(S).

lquery(collect(L)) :- lquery(L).

lquery(attribute(A)) :- atom(A).

sort(comment).

sort(typeDeclaration).

sort(classDeclaration).

sort(methodDeclaration).

C#-QL

(37)

Megamodel

for the query language

4 Ralf L¨

ammel and Andrei Varanovich

The aspect of XML transformation:

constraint

a

ﬀ

ects

:

C

#

_×

RuntimeObjects

transformation

XmlSerializer

.

Serialize

:

RuntimeObjects

_→

XML

anXmlDoc

�

_∈

XML

anXmlDoc

�

:

aSchema

a

ﬀ

ects

(

aProgram

,

anObject

)

XmlSerializer

.

Serialize

(

anObject

)

_�→

anXmlDoc

�

The aspect of a constrained target language:

constraint

O

/

X

:

C

#

O

/

X

(

anObjectModel

)

An alternative form of expression:

language

C

#

₋

O

/

X

C

#

₋

O

/

X

_⊂

C

#

anObjectModel

_∈

C

#

₋

O

/

X

Query language-based definition of target language:

language

C

#

₋

QL

constraint

C

#

₋

QL

₋

evaluator

:

C

#

₋

QL

_×

C

#

ox

.

csharpQl

_∈

C

#

₋

QL

∀

x

_∈

C

#

. x

_∈

C

#

₋

O

/

X

=

_def

C

#

₋

QL

₋

evaluator

(

ox

.

csharpQl

, x

)

Megamodel for the query language:

language

PT

-- Prolog terms

language

PTG

-- Prolog term grammars

constraint

runPtg

.

pro

:

PTG

_×

PT

artifact

csharpQl

.

ptg

-- a grammar for

C

#

₋

QL

csharpQl

.

ptg

_∈

PTG

∀

x

_∈

PT

. x

:

csharpQl

.

ptg

=

_def

runPtg

.

pro

(

csharpQl

.

ptg

, x

)

(38)

Megamodels -- language summary

Syntax

Megamodels

Entities

Relationships

Definitions

Bindings (omitted)

Entity parameters (omitted)

Static semantics = coherence checks on relationships

Dynamic semantics = constraint/transformation execution

Inference = match parametric models with actual projects

(39)

Megamodels

2 Ralf L¨

ammel and Andrei Varanovich

function) [[

_·

]] :

S

_→

(

U

_→

B

) where

U

_⊇

L

is again a suitable universe (in fact,

a language) from which to draw elements for inquiring membership for

L

and

B

denotes the Boolean value domain

_{

T

,

F

_}

. Thus, the generalized solution to the

membership problem for

L

_⊆

U

specified by

s

_∈

S

is stated as follows:

∀

x

_∈

U. x

_∈

L

_⇐⇒

[[

s

]]

x

=

T

For instance, a context-free grammar

G

is interpreted as follows:

[[

G

]]

x

=

�

T

,

if

root

(

G

)

_⇒

+

_G

x

F

,

otherwise

Inspired by the grammar view, we also say that [[

s

]] denotes an acceptor for

L

.

Any acceptor for

L

with associated universe

U

_⊇

L

should be a function of type

U

_→

B

. Among all conceivable acceptors, [[

s

]] stands out by being essentially

derived from a specification. In practice, we may indeed consider acceptors that

are essentially black boxes, i.e., they are not declared to be derived from a

specification. For instance, a parser in a compiler may be handwritten or its

status may simply be unknown.

3 Megamodels

Megamodels:

mm

= (“

import

”

name

)

∗

“

megamodel

”

name

“

_{

”

(

entity

_|

rel

_|

def

_|

bind

)

∗

“

_}

”

Entities:

entity

= “

language

”

name

|

“

artifact

”

name

|

“

constraint

”

name

“:”

_{

name

“

_×

”

_}

+

|

“

transformation

”

name

“:”

_{

name

“

_×

”

_}

+

“

_→

”

_{

name

“

_×

”

_}

+

Relationships:

rel

=

name

“:”

name

|

name

“

_∈

”

name

|

name

“

_⊂

”

name

|

name

“

_⊆

”

name

|

name

“(”

_{

name

“

,

”

_}

+

“)”

|

name

“(”

_{

name

“

,

”

_}

+

“)” “

_�→

”

name

|

name

“(”

_{

name

“

,

”

_}

+

“)” “

_�→

” “(”

_{

name

“

,

”

_}

+

“)”

Definitions:

(40)

Entities

2 Ralf L¨

ammel and Andrei Varanovich

function) [[

_·

]] :

S

_→

(

U

_→

B

) where

U

_⊇

L

is again a suitable universe (in fact,

a language) from which to draw elements for inquiring membership for

L

and

B

denotes the Boolean value domain

_{

T

,

F

_}

. Thus, the generalized solution to the

membership problem for

L

_⊆

U

specified by

s

_∈

S

is stated as follows:

∀

x

_∈

U. x

_∈

L

_⇐⇒

[[

s

]]

x

=

T

For instance, a context-free grammar

G

is interpreted as follows:

[[

G

]]

x

=

�

T

,

if

root

(

G

)

_⇒

+

_G

x

F

,

otherwise

Inspired by the grammar view, we also say that [[

s

]] denotes an acceptor for

L

.

Any acceptor for

L

with associated universe

U

_⊇

L

should be a function of type

U

_→

B

. Among all conceivable acceptors, [[

s

]] stands out by being essentially

derived from a specification. In practice, we may indeed consider acceptors that

are essentially black boxes, i.e., they are not declared to be derived from a

specification. For instance, a parser in a compiler may be handwritten or its

status may simply be unknown.

3 Megamodels

Megamodels:

mm

= (“

import

”

name

)

∗

“

megamodel

”

name

“

_{

”

(

entity

_|

rel

_|

def

_|

bind

)

∗

“

_}

”

Entities:

entity

= “

language

”

name

|

“

artifact

”

name

|

“

constraint

”

name

“:”

_{

name

“

_×

”

_}

+

|

“

transformation

”

name

“:”

_{

name

“

_×

”

_}

+

“

_→

”

_{

name

“

_×

”

_}

+

Relationships:

rel

=

name

“:”

name

|

name

“

_∈

”

name

|

name

“

_⊂

”

name

|

name

“

_⊆

”

name

|

name

“(”

_{

name

“

,

”

_}

+

“)”

|

name

“(”

_{

name

“

,

”

_}

+

“)” “

_�→

”

name

|

name

“(”

_{

name

“

,

”

_}

+

“)” “

_�→

” “(”

_{

name

“

,

”

_}

+

“)”

Definitions:

(41)

Relationships

2 Ralf L¨

ammel and Andrei Varanovich

function) [[

_·

]] :

S

_→

(

U

_→

B

) where

U

_⊇

L

is again a suitable universe (in fact,

a language) from which to draw elements for inquiring membership for

L

and

B

denotes the Boolean value domain

_{

T

,

F

_}

. Thus, the generalized solution to the

membership problem for

L

_⊆

U

specified by

s

_∈

S

is stated as follows:

∀

x

_∈

U. x

_∈

L

_⇐⇒

[[

s

]]

x

=

T

For instance, a context-free grammar

G

is interpreted as follows:

[[

G

]]

x

=

�

T

,

if

root

(

G

)

_⇒

+

_G

x

F

,

otherwise

Inspired by the grammar view, we also say that [[

s

]] denotes an acceptor for

L

.

Any acceptor for

L

with associated universe

U

_⊇

L

should be a function of type

U

_→

B

. Among all conceivable acceptors, [[

s

]] stands out by being essentially

derived from a specification. In practice, we may indeed consider acceptors that