49
Design and Implementation of Domain-specific Languages Jaroslav Porubän [email protected] JKU Linz, April 2009

here - Hornad - TUKE

  • Upload
    others

  • View
    4

  • Download
    0

Embed Size (px)

Citation preview

Page 1: here - Hornad - TUKE

Design and Implementation of

Domain-specific Languages

Jaroslav Porubä[email protected]

JKU Linz, April 2009

Page 2: here - Hornad - TUKE

2

Outline1. Domain-specific languages2. Language anatomy – concrete and

abstract syntax, semantics3. Concrete syntax - textual and graphical

form4. Embedded DSLs5. Standalone DSLs6. Language Environments7. Language transformations, artifact

generation8. Case Study: DSL development

Page 3: here - Hornad - TUKE

3

DSL Project The marks for this course will be based on the

project evaluation Choose any domain (other than state machine

charts) Create a simple DSL for the selected domain Minimal Requirements

1 domain class 1 domain relationship (reference) 1 artifact generator simple model validation

If you have any problems with DSL project send an email

Send the DSL project to [email protected]

Deadline: June 10, 2010

Page 4: here - Hornad - TUKE

4

Literature[1] J. Greenfield, K. Short, S. Cook, S. Kent: Software

Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools. Wiley, 2004, 500 pp. ISBN 0471202843.

[2] S. Cook, G. Jones, S. Kent, A. C. Wills: Domain Specific Development With Visual Studio DSL Tools. Addison-Wesley, 2007, 576 pp. ISBN 0321398203. http://www.domainspecificdevelopment.com/

[3] M. Fowler: Domain Specific Languages. 2009, http://martinfowler.com/dslwip.

[4] T. Stahl, M. Voelter: Model-Driven Software Development: Technology, Engineering, Management. Wiley, 2006, 444 pp. ISBN 0470025700.

[5] K. Czarnecki, U. Eisenecker. Generative Programming: Methods, Tools, and Applications. Addison-Wesley, 2000, 832 pp. ISBN 0201309777.

[6] M. Mernik, J. Heering, A. M. Sloane: When and how to develop domain-specific languages. ACM Computing Surveys, 37(4):316–344, 2005.

Page 5: here - Hornad - TUKE

5

Language Language - the words, their

pronunciation, and the methods of combining them used and understood by a community

“Merriam-Webster Dictionary” Natural Language

human-human interaction Computer Language

human-computer interaction computer-computer interaction

Basic tool for communication Effective communication is crucial

Page 6: here - Hornad - TUKE

6

Computer Language Artificial languages used in

computers created by humans general purpose programming

languages domain-specific languages modeling and meta-modeling

languages data models ontologies

Formal Language – suitable for machine processing

Page 7: here - Hornad - TUKE

7

Computer language engineering is the application of a systematic, disciplined, quantifiable approach to the development, use, and maintenance of computer languages

Concerned with all phases of the lifecycle design implementation documentation testing deployment evolution recovery

Computer Language Engineering

Page 8: here - Hornad - TUKE

8

The Role of Computer Languages

Computer Languages

Paradigm•functional•modular•object-oriented•aspect-oriented•domain-specific

Form•textual•graphical•mixed

Tool, environments,platforms

Secur

ity

Usability

Performance

System

Flexibility

Functionality

PrinciplesApproachesExperienceMethods

Page 9: here - Hornad - TUKE

9

Human-computer interaction Effective to be comprehend Effective to be processed

The Effective Communication

XMLXMLSGMLSGMLnatural

languagenaturallanguage

binaryformatbinaryformat

GPLGPL

YAMLYAML??????

Page 10: here - Hornad - TUKE

10

GPL - General-purpose Programming Language Useful for expressing algorithms in

general Design without specific domain in mind Programming paradigm - fundamental

style of computer programming General-purpose programming language

are Turing-complete Examples:

Java Pascal Haskell C#

Page 11: here - Hornad - TUKE

11

General vs. Specific ToolsGeneral Purpose

ToolDomain Specific

Tool

domain specific usagesimpler to comprehendhigher effectiveness

wide usage - frequently usedtakes longer to comprehendonce learned - do anything

Page 12: here - Hornad - TUKE

12

DSL - Domain Specific Language A Domain-Specific Language is a

language that targets a problem domain, which it describes and validates in terms native to the domain

Examples: HTML - HyperText Markup Language CSS - Cascading Style Sheets SQL - Structured Query Language SVG - Scalable Vector Graphics VHDL - VHSIC hardware description

language BNF - Backus–Naur Form

Page 13: here - Hornad - TUKE

13

DSL - Domain Specific Language

DSLs trade generality for expressiveness in a limited domain

DSLs are also called application-oriented special purpose specialized task-specific little languages

Page 14: here - Hornad - TUKE

14

Bridging the Worlds

Implementation Domain

General-purpose programming

language

Problem Domain

From a machine to a domain

From a domain modeling to machine execution

Domain-specificlanguages

Page 15: here - Hornad - TUKE

15

Advantages Ability to work in terms of the problem

domain, with less scope for making the errors that come from representing it in a GPL

Can make the models more accessible to people not familiar with the implementation technology (business people)

Models expressed using DSL can be validated at the level of abstraction of the problem domain

Business knowledge is captured in a model Standardization of domain vocabulary and

notation

Page 16: here - Hornad - TUKE

16

Advantages Easier to migrate a solution from one

technology to another, or between versions of the same technology – technological independence

Models can be used to configure an implementation consisting of multiple technologies of different types - reduce the skill and effort required to implement a solution using these technologies

Models can also be used to generate other artifacts - configure other systems, networks, and products

Page 17: here - Hornad - TUKE

17

Disadvantages The necessity to build DSL tools

parsers/compilers model validators editors code completion support tools visualizers document support tools

Page 18: here - Hornad - TUKE

18

Domain Reflection in GPL

public void dit(BObject b1, BObject b2, double k) {

if (k > 0 && b1.esm() > k) { b1.hbe(k); b2.ppo(k); } else { //... }}

The Importance of Identifiers in GPL

public void transfer(Account from, Account to, double ammount) {

if (ammount > 0 && from.getDisposableBalance() > ammount) {

from.withdraw(ammount); to.deposit(ammount); } else { //... }}

Page 19: here - Hornad - TUKE

19

Language Anatomy

Concrete syntax

Abstract syntax

Semantics

Page 20: here - Hornad - TUKE

20

State Machine Language - SML Informal definition of the SML

abstract syntax (domain concepts) State machine has at least one state

and at least one transition State machine has exactly one start

state Every state has its unique name Transition is connection between two

states

Page 21: here - Hornad - TUKE

21

Abstract Syntax Characterizes in an abstract form

kinds of elements that make up the language rules for how those elements may be

combined There are

atomic elements composite elements

Useful for the definition of semantics Formally defined by

BNF Metamodels

Page 22: here - Hornad - TUKE

22

Abstract Syntax - SML BNF

StateMachine ::= StartState State+ Transition+State ::= IdentifierStartState ::= IdentifierTransition ::= Identifier Identifier

Metamodel

Page 23: here - Hornad - TUKE

23

Concrete Syntax Defines how the language elements

appear in a concrete, human-usable form (computer-human interaction) textual graphical

Another term for concrete syntax is notation

A serialization syntax is used to persist and interchange language expressions in serialized form (computer-computer interaction)

Page 24: here - Hornad - TUKE

24

Concrete Syntax - SML BNF

StateMachine ::= StartState State+ Transition+StartState ::= 'start' IdentifierState ::= 'state' IdentifierTransition ::= 'transition' 'from' Identifier 'to'

IdentifierIdentifier::= ['a'-'z''A'-'Z']+

Textual form – sentencestart Readystate Readystate Runningstate Unsafetransition from Ready to Runningtransition from Running to Readytransition from Running to Unsafetransition from Unsafe to Running

Page 25: here - Hornad - TUKE

25

Concrete Syntax - SML Graphical form - sentence

Ready Running Unsafe

Page 26: here - Hornad - TUKE

26

Semantics The semantics of a language

define its meaning Translation semantics

translate expression of a language under study into another language that already has semantics

Trace-Based Semantics defines the meaning of a language in

terms of execution traces

Page 27: here - Hornad - TUKE

27

DSL Usage Scenario

Generatedartifacts

(Language)

Model(DSL concrete

syntax)

Model(in memory

representation)

Metamodel Templates

GeneratorParser

instance of

uses

Page 28: here - Hornad - TUKE

Parsing DSL

Jaroslav Porubä[email protected]

JKU Linz, April 2009

Page 29: here - Hornad - TUKE

29

Approaches to DSL Implementation - Parsing

Approaches (are explained on examples) Standalone DSL (External DSL)

hand-crafted parser parser generator

Embedded DSL (Internal DSL) XML YAML Language Environments (aka

Workbenches)

Page 30: here - Hornad - TUKE

30

Standalone DSL Standalone textual DSL requires

specific language processor – parser Operates on pure text input Hand-crafted Parser

Line (delimiter) parser Recursive Descent Parser

Generated Parser Parser Generators

Page 31: here - Hornad - TUKE

31

Parser Generator Parser generator generates parser from a

language definition YACC, Bison, JavaCC, ANTLR, Coco/R

Parser is produced usually as source code in a GPL

ParserSource Code

ParserGenerator

generates

Sentence

1 + (2 – 7)

LanguageDefinitionGrammar

Attribute Grammar

reads

Page 32: here - Hornad - TUKE

32

Standalone DSL – pros and cons + Concrete DSL syntax is fully under the control

of language designer - Parser generators are complex tools with their

own DSLs“Implementing a textual DSL by implementing its grammar can be a difficult and error-prone task, requiring significant expertise in language design and the use of a parser-generator” [1]“Implementing a parser-generator is definitely an expert task, because a grammar might be ambiguous or inconsistent, or might require a long look-ahead to decide what to do.” [1]“DSL development is hard, requiring both domain knowledge and language development expertise. Few people have both.” [6]

Page 33: here - Hornad - TUKE

33

Embedded DSL Implemented in a host language –

usually GPL (e.g. Java, C#, Ruby) It is not required to create language

parser DSL source code is developed using

a standard programming environment (and also with support from the environment)

Embedded DSL design patterns are explained in [3], [6]

Page 34: here - Hornad - TUKE

34

Embedded DSL – SMLpublic abstract class StateMachineBuilder { public StateMachine create() { define(); } protected abstract void define(); protected void start(String name) { ... } protected void state(String name) { ... } protected void transition(String fromName, String toName) { ... }}

public class TestMachine extends StateMachineBuilder { protected void define() { start("Ready"); state("Ready"); state("Running"); state("Unsafe"); transition("Ready", "Running"); transition("Running", "Ready"); transition("Running", "Unsafe"); transition("Unsafe", "Running"); }}

Page 35: here - Hornad - TUKE

35

Embedded DSL – pros and cons + It is not required to write a DSL parser + Standard programming environment

can help with DSL source code creation - Concrete syntax is influenced by host

language syntax - Standard programming environment is

not enough restrictive when DSL source code is created

Page 36: here - Hornad - TUKE

36

XML - Extensible Markup Language XML is a technology concerned with the

description and structuring of data XML document is platform (machine)

independent form of storing data XML is standard for creating

languages that meet the XML criteria Example

<person> <name nickname="007"> <first>James</first> <last>Bond</last> </name></person>

Page 37: here - Hornad - TUKE

37

XML - SML

<machine start="Ready"><state name="Ready" /><state name="Running" /><state name="Unsafe" />

<transition from="Ready" to="Running" /><transition from="Running" to="Ready" /><transition from="Running" to="Unsafe" /><transition from="Unsafe" to="Running" />

</machine>

Page 38: here - Hornad - TUKE

38

XML – pros and cons + Good tool support + Industrial XML language processor + Syntax defined through standard

formats (DTD, XSD, Relax NG) - Too verbose for the human

readers/writers - DSL’s syntax must follow XML spec

1 + 2 * 7 <add> <number>1</number> <mul> <number>2</number> <number>7</number> </mul></add>

Page 39: here - Hornad - TUKE

39

YAML - YAML Ain't a Markup Language

YAML is a human-readable and human-writable data serialization

Notation list hash

Style indented inline

Example- {name: John Black, age: 29}- name: Joan Red age: 25

JSON (JavaScript Object Notation) is subset of YAML

Page 40: here - Hornad - TUKE

40

YAML - SML{ start: Ready

states: [Ready, Running, Unsafe]transitions:

- {from=Ready, to=Running}- {from=Running, to=Ready}- {from=Running, to=Unsafe}- {from=Unsafe, to=Running}

}

Page 41: here - Hornad - TUKE

41

YAML – pros and cons + Industrial YAML processor + Human friendlier than XML - Lack of schema formats - DSL’s syntax must follow YAML

spec

Page 42: here - Hornad - TUKE

42

Language Environments Tools that support creating DSLs in

the style of modern IDEs Generates language tools from the

language definition (DSL) code completion graphical editors refactoring tools other support tools

Page 43: here - Hornad - TUKE

43

Microsoft Visual Studio DSL Tools

Page 44: here - Hornad - TUKE

44

Microsoft Visual Studio DSL Tools

Page 45: here - Hornad - TUKE

45

Language Environment – pros and cons

+ Simplifies the development of DSL + Rapid language development with

support tools - Only starts to widespread, LE are

in early stages

Page 46: here - Hornad - TUKE

Generating Artifacts

Jaroslav Porubä[email protected]

JKU Linz, April 2009

Page 47: here - Hornad - TUKE

47

Transforming Artifacts

DSL2 Artifacts

DSL1 Artifacts

DSL3 Artifacts

vertical transformation

horizontal transformation

GPL Artifacts

Page 48: here - Hornad - TUKE

48

Approaches to Artifacts Generation

Approaches (are explained on examples) Transformed Generation Templated Generation XSLT Transformation

Page 49: here - Hornad - TUKE

49

Conclusions DSLs vs. GPLs Programming vs. Modeling Concrete vs. Abstract Language

Syntax Standalone vs. Embedded DSLs vs.

Language Environments Transformed Generation vs.

Templated Generation