[PPT] - Multi-Paradigm Language Engineering and Equation-Based PowerPoint Presentation

SLIDE 1

8 July 2008 Equation-based Object-Oriented Languages and Tools Paphos, Cyprus

Multi-Paradigm Language Engineering and Equation-Based Object-Oriented Languages

Hans Vangheluwe

Modelling, Simulation and Design Lab (MSDL) School of Computer Science, McGill University, Montr´ eal, Canada

Hans Vangheluwe hv@cs.mcgill.ca MPM and EOOLs 1

SLIDE 2

Overview

1. Multi-Paradigm Modelling (MPM)
2. Domain-Specific Modelling
3. Language Engineering and MPM Tools
4. MPM for EOOLT
5. EOOLT for MPM
6. Conclusions

Hans Vangheluwe hv@cs.mcgill.ca MPM and EOOLs 2

SLIDE 3

Modelling a Variety of Complex Systems . . .

Multi-Paradigm modelling (minimize accidental complexity)

at most appropriate level of abstraction
using most appropriate formalism(s)
with transformations as first-class models

Pieter J. Mosterman and Hans Vangheluwe. Computer Automated Multi-Paradigm Modeling: An Introduction. Simulation 80(9):433–450, September 2004. Special Issue: Grand Challenges for Modeling and Simulation. Hans Vangheluwe hv@cs.mcgill.ca MPM and EOOLs 3

SLIDE 4

Domain-Specific (Visual) Modelling: Waste Water Treatment Plants (WWTPs)

NATO’s Sarajevo WWTP www.nato.int/sfor/cimic/env-pro/waterpla.htm

Hans Vangheluwe hv@cs.mcgill.ca MPM and EOOLs 4

SLIDE 5

DS(V)M Environment

www.hemmis.com/products/west/

Henk Vanhooren, Jurgen Meirlaen, Youri Amerlinck, Filip Claeys, Hans Vangheluwe, and Peter A. Vanrolleghem. WEST: Modelling biological wastewater treatment. Journal of Hydroinformatics, 5(1):27-50, 2003. Hans Vangheluwe hv@cs.mcgill.ca MPM and EOOLs 5

SLIDE 6

WWTP (domain-specific) model

influent mixer aeration_tank settler effluent f_influent f_mixed f_processed f_out f_bacteria

Hans Vangheluwe hv@cs.mcgill.ca MPM and EOOLs 6

SLIDE 7

Transformation from WWTP to . . .

influent f_influent f_influent C_influent 0.0

OUT

mixer f_influent f_bacteria f_mixed f_bacteria f_influent f_mixed

I OUT

C_aeration 0.9 aeration_tank f_mixed aeration_fraction f_processed f_processed f_mixed

TRANSFORM TRANSFORM TRANSFORM

Hans Vangheluwe hv@cs.mcgill.ca MPM and EOOLs 7

SLIDE 8

... its meaning (steady-state abstraction): Causal Block Diagram (CBD)

C_influent 10.0

OUT

C_settling 0.6

I OUT I OUT

− 1.0

OUT

effluent

I OUT

f_influent f_bacteria f_mixed settling_fraction

ne

negated dump_fraction f_out C_aeration 0.9 aeration_fraction f_processed

Hans Vangheluwe hv@cs.mcgill.ca MPM and EOOLs 8

SLIDE 9

Meaning of the CBD

       

C_influent 10.0 OUT C_bacteria 1.0 C_settling 0.6 I OUT I OUT − 1.0 OUT effluent dump I OUT f_influent f_bacteria f_mixed settling_fraction

ne

negated dump_fraction f_dump f_out C_aeration 0.9 aeration_fraction f_processed

        =                     

f influent = C influent f bacteria = C bacteria f mixed = f influent + f bacteria aeration fraction = C aeration f processed = aeration fraction ∗ f mixed settling fraction = C settling negated = −settling fraction

ne

= 1 dump fraction =

ne + negated

f dump = f processed ∗ dump fraction f out = settling fraction ∗ f processed Hans Vangheluwe hv@cs.mcgill.ca MPM and EOOLs 9

SLIDE 10

DS(V)M example application: conference registration (Google Android)

Hans Vangheluwe hv@cs.mcgill.ca MPM and EOOLs 10

SLIDE 11

DS(V)M example application, the PhoneApps Domain-Specific model

Hans Vangheluwe hv@cs.mcgill.ca MPM and EOOLs 11

SLIDE 12

Only transform . . .

ConferenceRegistrationApps StateCharts AndroidAppScreens AndroidAppFiles Actual files (AndroidManifest.xml, PhoneApp.java, PhoneAppStateChart.java, screen_*.xml) PhoneApps 1 2 3 4 5 6 Hans Vangheluwe hv@cs.mcgill.ca MPM and EOOLs 12

SLIDE 13

Why DS(V)M ? (as opposed to General Purpose modelling)

match the user’s mental model of the problem domain
maximally constrain the user (to the problem at hand)

⇒ easier to learn ⇒ avoid errors

separate domain-expert’s work

from analysis/transformation expert’s work Anecdotal evidence of 5 to 10 times speedup

Steven Kelly and Juha-Pekka Tolvanen. Domain-Specific Modeling: Enabling Full Code Generation. Wiley 2008. Hans Vangheluwe hv@cs.mcgill.ca MPM and EOOLs 13

SLIDE 14

Building (DS)(V)M Tools Effectively . . .

development cost of DS(V)M Tools may be prohibitive !
we want to effectively (rapidly, correctly, re-usably, . . . )
1. Specify DS(V)L syntax:

– abstract ⇒ meta-modelling – concrete (textual/visual)

2. Specify DS(V)L semantics:

transformation

3. Model (and analyze and execute) model transformations:

⇒ graph rewriting

⇒ model everything

(in the most appropriate formalism, at the appropriate level of abstraction)

Hans Vangheluwe hv@cs.mcgill.ca MPM and EOOLs 14

SLIDE 15

Dissecting a Formalism

Hans Vangheluwe hv@cs.mcgill.ca MPM and EOOLs 15

SLIDE 16

Modelling Modelling Languages

Hans Vangheluwe hv@cs.mcgill.ca MPM and EOOLs 16

SLIDE 17

From now on: use AToM3

Juan de Lara and Hans Vangheluwe. AToM3: A tool for multi-formalism and meta-modelling. Fundamental Approaches to Software Engineering (FASE). LNCS 2306, pages 174 – 188, 2002. Hans Vangheluwe hv@cs.mcgill.ca MPM and EOOLs 17

SLIDE 18

A model in the PacMan Formalism

Your score

(thanks to Reiko Heckel)

Hans Vangheluwe hv@cs.mcgill.ca MPM and EOOLs 18

SLIDE 19

Modelling Abstract Syntax (meta-model)

Cardinalities:

To gridBottomV3: 0 to N
From gridBottomV3: 0 to N
From pacLinkV3: 0 to N
From foodLinkV3: 0 to N
From scoreLinkV3: 0 to N
To gridLeftV3: 0 to N
From gridLeftV3: 0 to N
To gridRightV3: 0 to N
From gridRightV3: 0 to N
To gridTopV3: 0 to N
From gridTopV3: 0 to N
From ghostLinkV3: 0 to N

gridNodeCenter Cardinalities:

To pacLinkV3: 0 to N

pacmanV3 Cardinalities:

To foodLinkV3: 0 to N

pacFoodV3 Attributes:

score :: Integer

Actions: > create Cardinalities:

To scoreLinkV3: 0 to N

ScoreBoard Cardinalities:

To ghostLinkV3: 0 to N

ghostV3 gridLeftV3 Cardinalities:

To gridNodeCenter: 0 to 1
From gridNodeCenter: 0 to 1

gridTopV3 Cardinalities:

To gridNodeCenter: 0 to 1
From gridNodeCenter: 0 to 1

gridBottomV3 Cardinalities:

To gridNodeCenter: 0 to 1
From gridNodeCenter: 0 to 1

gridRightV3 Cardinalities:

To gridNodeCenter: 0 to 1
From gridNodeCenter: 0 to 1

ghostLinkV3 Cardinalities:

To gridNodeCenter: 0 to N
From ghostV3: 0 to N

scoreLinkV3 Cardinalities:

To gridNodeCenter: 0 to N
From ScoreBoard: 0 to N

pacLinkV3 Cardinalities:

To gridNodeCenter: 0 to N
From pacmanV3: 0 to N

foodLinkV3 Cardinalities:

To gridNodeCenter: 0 to N
From pacFoodV3: 0 to N

Hans Vangheluwe hv@cs.mcgill.ca MPM and EOOLs 19

SLIDE 20

Modelling Ghost Concrete Visual Syntax

Hans Vangheluwe hv@cs.mcgill.ca MPM and EOOLs 20

SLIDE 21

GhostLink Concrete Visual Syntax

# Get n1, n2 end-points of the link n1 = self.in_connections_[0] n2 = self.out_connections_[0] # g1 and g2 are the graphEntity visual objects g0 = self.graphObject_ # the link g1 = n1.graphObject_ # first end-point g2 = n2.graphObject_ # second end-poing # Get the high level constraint helper and solver from Qoca.atom3constraints.OffsetConstraints import OffsetConstraints

c = OffsetConstraints(self.parent.qocaSolver)

# The constraints

c.CenterX((g1, g2, g0))
c.CenterY((g1, g2, g0))
c.resolve()

Hans Vangheluwe hv@cs.mcgill.ca MPM and EOOLs 21

SLIDE 22

Model the GUI’s Reactive Behaviour ! in the Statechart formalism (++)

challenge: find optimal formalism to specify GUI reactive behaviour

Hans Vangheluwe hv@cs.mcgill.ca MPM and EOOLs 22

SLIDE 23

Modelling Modelling Languages

Hans Vangheluwe hv@cs.mcgill.ca MPM and EOOLs 23

SLIDE 24

Specifying Model Transformations

What is the “optimal” formalism ? Models are often graph-like ⇒ natural to express model transformation by means of graph transformation models. Tools: GME/GReAT, PROGRES, Fujaba, AGG, AToM3, GROOVE, . . . First three used in large industrial applications.

Ehrig, H., G. Engels, H.-J. Kreowski, and G. Rozenberg. Handbook of graph grammars and computing by graph transformation.

1999. World Scientific.

Hans Vangheluwe hv@cs.mcgill.ca MPM and EOOLs 24

SLIDE 25

Modellling PacMan Operational Semantics using Graph Grammar models

note: for Denotational Semantics: map for example onto Petri Net

Hans Vangheluwe hv@cs.mcgill.ca MPM and EOOLs 25

SLIDE 26

Model Operational Semantics using GT

Hans Vangheluwe hv@cs.mcgill.ca MPM and EOOLs 26

SLIDE 27

PacMan Die rule

Hans Vangheluwe hv@cs.mcgill.ca MPM and EOOLs 27

SLIDE 28

PacMan Die rule LHS

2 4 1 3 5

Hans Vangheluwe hv@cs.mcgill.ca MPM and EOOLs 28

SLIDE 29

PacMan Die rule RHS

1 3 5

Hans Vangheluwe hv@cs.mcgill.ca MPM and EOOLs 29

SLIDE 30

PacMan Eat rule LHS

2 5 1 3 4

Hans Vangheluwe hv@cs.mcgill.ca MPM and EOOLs 30

SLIDE 31

PacMan Eat rule RHS

2 5 1

scoreBoard = None scoreBoards = atom3i.ASGroot.listNodes[’ScoreBoard’] if (not scoreBoards): return else: scoreBoard = scoreBoards[0] scoreVal = scoreBoard.score.getValue() scoreBoard.score.setValue(scoreVal+1) scoreBoard.graphObject_.ModifyAttribute(’score’,scoreVal+1)

Hans Vangheluwe hv@cs.mcgill.ca MPM and EOOLs 31

SLIDE 32

PacMan Move rule LHS

7 8 6 9 10

Hans Vangheluwe hv@cs.mcgill.ca MPM and EOOLs 32

SLIDE 33

PacMan Move rule RHS

7 1 6 9 10

Hans Vangheluwe hv@cs.mcgill.ca MPM and EOOLs 33

SLIDE 34

MPM for EOOLT

Domain-Specific Languages (e.g., WWTP):

– model abstract syntax, including domain constraints – model concrete syntax – model mapping onto EOOL (note: need trace-ability)

Rule-based specification of EOOLT model transformations
Graph patterns for variable structure formalisms

Hans Vangheluwe hv@cs.mcgill.ca MPM and EOOLs 34

SLIDE 35

Visual Modelling Environment for DEVS

Hans Vangheluwe hv@cs.mcgill.ca MPM and EOOLs 35

SLIDE 36

EOOLT for MPM

add declarative constraint equations to (meta-)models
model consistency, co-evolution (with TGGs)

Hans Vangheluwe hv@cs.mcgill.ca MPM and EOOLs 36

SLIDE 37

Meta-triple/Triple Graph Grammar(TGG)

SE-Part

+Geometry

SE-Assembly Relationship

* 1 1 *

Axial Align Planar Align Planar mate

2 +constrains 1

Model

1 *

Body Geometric Feature

+Type 1 *

Relationship Axial Align Planar Align Planar mate Plane Axis/Line

1 * * +has 1 1 * 2 +constrains 1

SolidEdge meta-model Association meta-model Modelica meta-model for SolidEdge Library

Assembly-Model-Link Part-Link Relation-Link

+* 1 1 1 1 1 1 1 1 1 1..* 1 1 1 1

Andy Sch¨

urr. Specification of Graph Translators with Triple Graph Grammars.

LNCS 903. pages 151–163, 1994. Hans Vangheluwe hv@cs.mcgill.ca MPM and EOOLs 37

SLIDE 38

Conclusions

Multi-Paradigm Modelling (MPM)
Domain-Specific Modelling
Language Engineering and MPM Tools
MPM for EOOLT
EOOLT for MPM

model everything !

Hans Vangheluwe hv@cs.mcgill.ca MPM and EOOLs 38

SLIDE 39

Model Based Development: some Open Problems

1. deal with legacy models (code)
2. consistency (TGGs + modularity), multi-user modelling
3. multi-view modelling, (semantic) consistency
4. version control, (meta-) model evolution
5. trace-ability (backward links)
6. multi-formalism modelling
7. model refinement
8. automated design-space exploration
9. automated testing (of models and model transformations)
10. transformation models are first-class models ⇒

higher-order transformation

11. deal with concrete syntax (arbitrary mix of textual, visual) in a unified manner
12. concrete visual syntax: web-based (SVG+Ajax)

Hans Vangheluwe hv@cs.mcgill.ca MPM and EOOLs 39