Organization of DSLE part. Overview of DSLE. Model driven software engineering. Engineering. Tooling. Topics:

(1)

Domain Specific Language Domain Specific Language Engineering

Prof.dr. Mark van den Brand GLT 2010/11

• Toolingg

• Eclipse plus EMF

• Xtext, Xtend, Xpand, QVTo and ATL

• Topics:

• Model driven software engineeringModel driven software engineering

− Meta-modeling

− Model transformations

• Domain specific language design and engineering

− Textual

/ Faculteit Wiskunde en Informatica 9-11-2010 PAGE 1

Overview of DSLE

• Model driven software engineering in generalg g g

• Grammars, signatures and meta-models

• DSL Design

• Model transformations

• Code generation

/ Faculteit Wiskunde en Informatica ^9-11-2010 ^{PAGE 2}

Model driven software engineering

• Models are used everywhere y

(2)

• Models are abstractions of real life objectsj

• Models increase the level of abstraction

• used for both hardware and software design

• often manually translated into design documents and code

and code

• no guarantee for consistency between model, design and resulting code

Model driven software engineering

• Whole range of modeling languages are g g g g developed over the years:

• data oriented, e.g., E/R models, class diagrams

b h i i t d t t

• behaviour oriented, e.g., use cases, state

machines, sequence diagrams, activity diagrams

• architecture oriented, e.g., package diagrams, component diagrams

• Standardization initiative of OMG: Standardization initiative of OMG:

• Unified Modeling Language

Model driven software engineering

• UML is unified:

• Class diagrams

• Object diagrams

• Use cases

• State machine diagrams

• Sequence diagrams

• Activity diagrams

• Component diagrams

• etc.

• UML is too “universal”

(3)

• Criticism on UML:

• It contains many diagrams and constructs that are redundant or infrequently used.

• Problems in learning and adopting

• Problems in learning and adopting.

• Linguistic incoherence.

• Capabilities of UML and implementation language

• Dysfunctional interchange format.

• UML is too “universal”: a general purpose modeling g g language

• Domain specific extension via:

P fil di t t th t d l l l t

• Profile diagram operates at the meta model level to show

− stereotypes as classes with the <<stereotype>>

stereotype, and

− profiles as packages with the <<profile>> stereotype

• Meta modeling

Model driven software engineering

• Meta-Object Facility (MOF) is a four-layered architecture:

• M3 Meta-Meta-Model Layer

− defines structure of the meta-metadata

− it provides a meta-meta model at the top layer M2 M t M d l L

• M2 Meta-Model Layer

− defines the structure of the metadata

− the M3-model is used to build meta models

− the most prominent example is the UML meta model the model thatthe most prominent example is the UML meta model, the model that describes the UML itself

• M1 Model Layer

− describes the data in the information layer

− the M2-models describe elements of the M1-layer

− For example, models written in UML

− describes objects or data in the information layer

Model driven software engineering

(4)

• Meta-Object Facility (MOF) is the OMG standardj y ( )

• no implementation

• EMF is the Eclipse implementation of MOF

EMF Model Definition

• What is an EMF “model”?

• Specification of an application’s data

− Object attributes

− Relationships (associations) between objects

− Operations available on each objectOperations available on each object

− Simple constraints (e.g., multiplicity) on objects and relationships

E ti ll th Cl Di b t f UML

• Essentially the Class Diagram subset of UML

Model driven software engineering

• What does EMF provide

• Meta-model

− A general model of models from which any model can be defined

− Models classes, attributes, relationships, data types, etc.

− Referred to as Ecore

− Ecore is just another EMF model

• EMF is used to implement EMF!

• Tooling support within the Eclipse framework

• Runtime environment

− Reflective and dynamic model invocation

− XML/XMI default model serialization

Model driven software engineering

• EMF is middle ground in the modeling vs. programming world

• Focus is on class diagram subset of UML modeling (object model)

• Transforms models into efficient, correct, and easily customizable Java code

• Provides the infrastructure to use models effectively in your code

• Very low cost of entry

• Full scale graphical modeling tool not required

• EMF is free

• Small subset of UML

(5)

• EMF Components

• EMF Core

− Ecore meta model

− Model change notification

− Persistence and serialization

− Reflection API

− Runtime support for generated models

− Change model and recorder

− Validation frameworkValidation framework

• EMF Edit

− Helps integrate models with a rich user interface

− Used to build editors and viewers for your model Includes default reflective model editor

− Includes default reflective model editor

• EMF Codegen

− Code generator for core and edit based components

− Model importers from Rose, XML, or Java interfaces

• EClass models classes

• Simplified Ecore meta-model EClass models classes themselves

• identified by name

• number of attributes Simplified Ecore meta model

number of attributes

• number of reference

• EAttribute models attributes

• has a type

• EDataType represents i l t

simple types

Model driven software engineering

• Simplified Ecore meta-model • EReference models Simplified Ecore meta model

associations between classes

• has a type which must be an ECl

EClass

• containment attribute indicating whether the EReference is used as “whole- EReference is used as whole- part” relationship

Model driven software engineering

• Classes, abstract classes and interfaces

• Attributes and Operations

(6)

• Creation of abstract class

• Associations in the meta-model:

• One way association

• Bidirectional association

Model driven software engineering

• Associations in the meta-model:

• Containment association

• Inherit association

Model driven software engineering

• EMF is suited for modeling domain specific g languages

(7)

• What is a Domain Specific Language (DSL)? p g g ( )

• A DSL is a formal, procesable language targeting at a specific aspect of a system

• Its semantics, flexibility and notation is designed in order to support working with that aspect as good order to support working with that aspect as good as possible

• How do we design a Domain Specific Language?g g g

• Establish needed language concepts

− domain specific b t t

− abstract

− corresponding semantics

• Graphical vs textual representationG ap ca s te tua ep ese tat o

• Develop tooling

Model driven software engineering

• Example of a Domain Specific Languageg g

• Specifying and Implementing the Controllers of Conveyor Belts

− We defined a domain specific language (DSL) for modeling p g g ( ) g communicating systems

− Stepwise refinement to adapt the characteristics of the communication channels to the Lego Mindstorms platform

Model driven software engineering

• State machine based

• combination of:

− graphical models and

− textual modelstextual models

• conditional message exchange

− plus activitiesplus activities

• No data yet

• No timing yet

(8)

• Requirements for a DSL:

• Unambiguous syntax

• Unambiguous semantics

U bi t f bilit

• Unambiguous transformability

• Strongly-typed and deterministic IO

• Encapsulationcapsu at o

• Expressiveness

• Readability

Overview of workshop

• Model driven software engineering in generalg g g

• Grammars, signatures and meta-models

• DSL Design

• Model transformations

• Code generation

Grammars, signatures and meta-models

• Definition of a (programming) language involves:( g g) g g

• abstract syntax, so-called signature

• concrete syntax:

− textual syntaxtextual syntax

− graphical syntax

• semantics:

− static semantics

− dynamic semantics

(9)

Grammar world

Meta-Meta-Model world Grammar world

• The 4-layer architecture

• M3 (E)BNF/SDF grammar

• The 4-layer architecture

• M3 Meta-Meta-Model Layer

− defines structure of the (E)BNF in (E)BNF

• M2 Java grammar

− defines the structure of Java in (E)BNF

− defines structure of the meta-metadata

• M2 Meta-Model Layer

− defines the structure of the metadata( )

• M1 Java program

− describes the manipulation (algorithm) of objects in the object layer

− describes the data in the information layer

• M0 Information Layer

• M0 Object layer

− Objects we wish to manipulate y

− data we wish to describe

• Abstract syntax: y

• defines basic structure of the language

( k l t ) (skeleton)

• is starting point for defining:

defining:

− concrete syntax

− static semantics

d i ti

− dynamic semantics

Grammars, signatures and meta-models

• Abstract syntax is a y

Abstract syntax definition of Booleans:

collection of constructors/-

“true”() -> BoolCon

“false”() -> BoolCon

“con”(BoolCon) -> Bool

functions

• No information about

k d i iti

con (BoolCon) > Bool

“and”(Bool, Bool) -> Bool

“or”(Bool, Bool) -> Bool

“not”(Bool) -> Bool

keywords, priorities, associativities, etc.

nonterminal nonterminal constructor

Grammars, signatures and meta-models

• Definition of a (programming) language involves:

• lexical syntax, so-called tokens:

− identifiers, numbers, strings, “if”, “then”, “class” (keywords)

• context-free syntax, so-called production rules:

− Statement ::= “if” Expression “then” Statements “else” Statements “fi”

• static semantics:

− identification and scope resolution type checking

− type checking

• dynamic semantics:

− operational semantics

− interpretationinterpretation

− compilation

(10)

• There is no standardized way of defining abstract y g syntax

• SSL (specification formalism of the Synthesizer Generator)

• Signature-like

• (Meta-modeling)

• SSL (grammar specification formalism of the (g Synthesizer Generator) describes it as follows:

• A collection of rules that define phyla and operators

• A phylum is a nonempty set of terms

• A term is the application of a k-ary operator to k terms of the appropriate phylum

A k ary operator is a constructor function mapping k terms to

• A k-ary operator is a constructor function mapping k terms to a term

• A phylum can be considered a nonterminal phyl₀: op(phyl₁ phyl₂ … phyl_k)

Grammars, signatures and meta-models

• SSL notation of the definition of the abstract syntax y of Booleans:

boolcon : True() | False() boolcon : True() | False() bool : Con(boolcon)

| And(bool bool)

| Or(bool bool)

Grammars, signatures and meta-models

• Signature describes it as follows:g

• A collection of functions that define sorts and operators

• A sort represents a nonempty set of terms

• A term is the application of a k-ary operator to k terms of the

• A term is the application of a k-ary operator to k terms of the appropriate sort

• A k-ary operator is a constructor function mapping k terms to a term

a term

• A sort can be considered a nonterminal

( )

op(sort₁, sort₂, …, sort_k)  sort₀

(11)

• Signature notation of the definition of the abstract g syntax of Booleans:

“true”()true () > BoolCon-> BoolCon

“false”() -> BoolCon

“con”(BoolCon) -> Bool

“and”(Bool, Bool) -> Bool

“or”(Bool, Bool) -> Bool

“not”(Bool) -> Bool

• Meta-modeling is the analysis, construction and g y development of the frames, rules, constraints, models and theories applicable and useful for modeling a predefined class of problems modeling a predefined class of problems.

• Relation between meta-models and grammars?

• Is every meta-model a context-free grammar?

− …

• Is every context-free grammar a meta-model?

− …

Grammars, signatures and meta-models

• Models and meta-models:

• Warmer et.al.:

− “A model is a description of (part of) a system written in a well- defined language”

− “A meta-model is a model that defines the language for expressing a model”

− “A meta-model is the collection of ‘concepts’ (things, terms, etc.) within a certain domain and an attempt at describing the world within a certain domain and an attempt at describing the world around us for a particular purpose. Meta-models are also referred to as a precise definition of the constructs and rules needed for creating semantic models.”

− “The meta-model of a language, also known as abstract syntax, is a description of all the concepts that can be used in that

language.”

Grammars, signatures and meta-models

Grammar

Program Syntax

Schema

Meta model Document

XML Meta-model

Model

ocu e t MDE

Schema DBMS

Data

(12)

• First alternative meta-model for Booleans:

• Every operator (not, or, and) is modeled as a separate class

• Constructors (true false) are modeled as enumeration

• Constructors (true, false) are modeled as enumeration

• Second alternative meta-model for Booleans:Seco d a te at e eta ode o oo ea s

• Binary operator is modeled as a separate class

• Unary operator is modeled as a separate class

• Operators are modeled as enumerations

• Constructors (true, false) are modeled as enumeration

• First alternative for Boolean meta-model

• Signature:

“false”()false () > BoolCon-> BoolCon BoolCon -> Bool AndBool -> Bool

OrBool -> Bool

OrBool -> Bool NotBool -> Bool

“and”(Bool, Bool) -> AndBool

“or”(Boolor (Bool, Bool) -> OrBool Bool) -> OrBool

“not”(Bool) -> NotBool

Grammars, signatures and meta-models

(13)

• Second alternative for Boolean meta-model

• Signature:

“false”() -> BoolCon BoolCon -> Bool BinaryBool -> Bool UnaryBool -> Bool

“bin”(BinaryOp, Bool, Bool) -> BinaryBool

“una”(UnaryOp, Bool, Bool) -> UnaryBool

“not”() -> UnaryOp

“and”() -> BinaryOp

“or”() -> BinaryOp