domain specific - a binary decision?domain specific - a binary decision? markus voelter...

Domain Specific - a Binary Decision?

Markus VoelterIndependent/itemis

voelter@acm.org

Bernhard MerkleSICK AG

bernhard.merkle@gmail.com

Context &Problem

Viewpoints

Viewpointssuitable

abstractions

notationsfor each

and

Viewpoints

Integrated

references

transitions

symbolic

seamlessand

via

ViewpointsDomain Specific

custompurpose-built

create/include

Viewpoints

CustomNotations

businessexpert integration

real

Domain Specific

ViewpointsGeneral Purpose

predefinedlibrary

configure

Viewpoints

C

LEGO Robot Control

General Purpose

Domain Specific

Viewpoints

C

LEGO Robot Control

Components

State Machines

Sensor Access

General Purpose

Domain Specific

Modeling Tools

Programming Tools!=

Different Worlds

Modeling Tool

Modeling Tool!=

Different Worlds

ConfigurationXOR

OR

x

x

x

From a given set of

configuration options you

select a subset.

Constraints between

configuration options limits

valid combinations

Construction

1 2

Bl 3

A

You define a language that can

be used to define a basically an

unlimited number of variants

You then define a sentence in

that language that describes a

particular variant

Configuration

Construction

Feature Models

Domain Specific Languages

Configuration

Construction

Feature Models

Domain Specific Languages

SolutionApproach

We don‘t want to

we want tomodel,

program!

We don‘t want to

we want tomodel,

program!… at different levels of abstaction

… from different viewpoints

… integrated!

We don‘t want to

we want tomodel,

program!… with different degrees of

… with suitable notations

… with suitable expressiveness

domain-specificity

We don‘t want to

we want tomodel,

program!

precise and tool processableAnd always:

L

ab

c

d

e

f

gh

i

j

k

m

n

o

with many first class concepts!

Big Language?

L

l

Small Language?

and poweful conceptswith a few, orthogonal

my L

a b c

d e f

g h i

j k l

Modular Language

composable conceptswith many optional,

Like frameworksand libraries,

Modular Language

Like frameworksand libraries,

but with syntaxand IDE support

Modular Language

ProjectionalEditing

Parser-basedtext… to tree… to text

Projectionaltree… to text-lookalike (editor)… to other trees … **+… to text

Tree

Programming as Modeling

… (Mostly) GraphicalNotations

… Abstract Syntax Storage

… Projecting Editors

… Different editableviews for model

Programming as Modeling

… (Mostly) Graphical Any kind ofNotations

… Abstract Syntax Storage

… Projecting Editors

… Different editableviews for model

Language

There‘s no parsing.

Unique Language Element Identity.

Unlimted language composition.

Composition

Textual

Graphical

Semi-Graphical

treated the same

can be mixed

like ASCII

box & line

mathematical

Flexible

Notations

Automatic

IDE Extensiontool support is inherent

for languages build withprojectional tools

language definition

IDE definitionimplies

MultipleNotations

… for the same concepts

e.g. in different contextsor for different tasks

PartialProjections

… different views… for different roles/people… only a particular variant

ProgramsLive

think: spreadsheet

a change to one part of programcan lead to (dependent) changesin other parts

Tree Editing

… try to make it feel like text

… takes some getting used tobut: for more flexible notations a more general editing paradigm is needed

… is different from editing text

InfrastructureIntegration

… diff/merge must be in tool

… existing text tools don‘t work

… storage is not text

ProprietaryTools

… no interop

… no standards

JetBrainsMPS

Q3 2009released in

1.5currently

Apache 2.0Open Source under

ExampleScenario

Two Classes in Embedded SystemsDevelopment

(yes, this is a slight simplification)

Incremental Extensionof

Incremental Extensionof Components

TasksState MachinesPhysical UnitsSpecial Data Types

Incremental Extensionof

syntacticallyand semanticallyintegrated

Incremental Extensionof

extensible withdomain-specificconstructs (DSLs)

Demo

The End.

Markus VoelterIndependent/itemis

voelter@acm.org

Bernhard MerkleSICK AG

bernhard.merkle@gmail.com

Language Extension and Composition with Language Workbenches

The End.