Model Driven Software Developmentand Domain Specific Languages

in a Nutshell

Inspired by the Discussion Track

„Domain Specific Modeling Languages“

during the

Model Driven Development Experience Day

at Siemens (2009-11-12 in Erlangen)

Ulrich Dinger

mail@ulrich-dinger.de2009-11-16

Education is the ability to listen to almost anything without losing your temper or your self-confidence.

Bildung ist die Fähigkeit, fast alles anhören zu können, ohne die Ruhe zu verlieren oder das Selbstvertrauen.

[Robert Frost]

Overview

Goal:

• Introduction to Model Driven Software Development• Clarification of relation of terms like DSL, UML etc• What benefits do I get from MDSD/DSLs

Target audience

• Software Architects/Developers• (technically interested) managers

Contents

• General concepts and terms

• Example: A revolutionary IPhone Application

• What is needed for developing a domain model/DSL?

General concepts and terms 1/3

Model-Driven Software-Development (MDSD) key concepts

• Provide optimal level of abstraction for each role in the (software-development) process

• Separation of concerns (e.g. separate app-logic from user interface)

• Avoid storing redundant information (use single source of information)

Provide custom domain-models/„languages“ and tools

The languages can be called „Domain Specific Languages (DSL)“

Meta-Meta-Model(e.g.: Ecore)

Meta-Grammar(e.g. (E)BNF )

Meta-Model / Data Model / Domain Model /

Schema / …

Grammar

Model(Instance)

Valid sentence of grammar

Model-Driven Software-Development (MDSD)Domain-concepts independent of presentation (= „abstract syntax“)

Domain specific lanuages (DSL)

Textual and graphical presentation of the concepts

Example: Java as a DSL for the domain „object-oriented programming“

Instance of

ANTLR(another tool for language recognition)

Java ProgrammingLanguage (Grammar)

Java-Class (e.g. FireDetector.java)

Terms in parser/compiler construction

Terms in model-driven software development

General concepts and terms 2/3

UML is a set of standardized modeling languages for different purposesClass Diagram = static structuresActivity Diagram = flow of controlSequence Diagram = interactions between classes…See also

http://www.smartdraw.com/resources/tutorials/Introduction-to-UML

Not sufficient for all cases/projects we need to define our own languages

UML – Unified Modeling LanguageGeneral concepts and terms 3/3

ExampleIPhone Application „Screen-Saver“= show a red background sell this application via IPhone-App-

Store (and make a hell lot of money)Code looks something like (Pseudo-Java):

class ScreenSaver {

public static void main(String[] args) {

Shell shell = new Shell();

shell.setBackGround(Color.RED);

…

}

}

customers love the product one potential customer says

I like it in general, BUT I would like to have it in GREEN

How to realize?1.) Copy/duplicate the code

Bad idea, because redundant information Hard to manage different versions of code/merge

changes …

class ScreenSaver {

public static void main(String[] args) {

Shell shell = new Shell();

shell.setBackGround(Color.RED);

…

}

}

class ScreenSaver {

public static void main(String[] args) {

Shell shell = new Shell();

shell.setBackGround(Color.GREEN);

…

}

}

2.) Make it configurable Good idea; but how to realize? 2.1) Traditional approach

Create a config/property-file Extend your program to read this file Use the values in your program Bad approach

No formalization of the content of the config-file/your domain knowlegde -> tight coupling with with target technology

No documentation (or hand-written)

A lot of hand-written code (although you can use existing frameworks to read property-files)

Untyped programming interface (only key-value-pairs)

If you change „backGround“ to „background“ in your property-file, you will get no compilation-error will see some problems during runtime (maybe too late) = No validation of config-file possible

backGround = red

class ScreenSaver {

public static void main(String[] args) {

Shell shell = new Shell();

Map<String, String> config = readConfig(…);

if (config.get(„backGround“).equals(„red“)) {

shell.setBackGround(Color.RED);

} else {

…

}

…

}

private Map<String, String> readConfig(..) {

…

}

}

2.) Make it configurable 2.2) Model driven approach

Central ideas: (platform independent) formalization of the domain

knowledge Generate (platform dependent) artefacts from these

information Create a domain-model/domain specific language that

contains all your knowledge about the domain „screen saver“

we can use UML class diagrams (or the Ecore-Modeling Language in the Eclipse-environment) for this purpose

(Description: We have an application/domain „ScreenSaver“. It has a user interface. Its background is either RED or GREEN.)

= domain model = meta-model = abstract syntax of DSL

What is needed for a complete DSL? Meta-model = abstract syntax of our DSL

To make it a DSL, we need some concrete syntax Textual format/syntax Graphical format/syntax XML-based format/syntax Database (schema) … Depends on purpose and personal

preferences

Additionally needed to work with the DSL Documentation/Specification of the DSL Programming interfaces (for create, read,

update and delete information/configuration/instances)

Editors/Tooling to manipulate instances

backGround = red

<ScreenSaver>

<userInterface

backGround=„RED“/>

</ScreenSaver>

DocumentationProgramming Interface (API)

Persistency Presentation

UML-Class-DiagramsWIKIHTML/WebDokumente (Word/Open Office...)...

C++Java...

XMLBinary formatDatabase...

Web (Thin-Client)Editor...

Advantages of the model driven approach (technical) 1/2Meta-Model

(ScreenSaver UML)Model(*.mot)

Generate (>90%)

Instance of

read/write

use

Model(*.mot)

Model(instances/concrete

configurations)

manipulate

Generate (>90%)

The meta-model is the formalization of domain knowledge independent of implementation

It is used as single source of information

Other artefacts are generated from it

Advantages of the model driven approach (technical) 2/2

no tight coupling with target technology; implementation can be exchanged

From meta-model you can generate documentation in various formats Programming interfaces to read/write the data Various persistence formats Tooling/editors=> Everything is kept in sync!!!

You can validate your data/configurations against the „schema“/meta-model

Less error prone save coding „boring“ stuff …

Advantages of the model driven approach (management point of view)

Less code to write less costs Less error prone less costs

Documentation available better quality Documentation in sync with implementation

better quality

Domain knowledge stored independently of target technology less risks

…

Back to the example… Sample implementation using

UML/Ecore as modeling language + some existing tooling

1.) Using the configuration-information

1.1) Generated programming interface (API) + usage in the code (= interpretative approach) Use typed API (there exist classes

called „ScreenSaver“, „UserInterface“ and „Color“ that represent your domain concepts)

Code is much more readable Changes in the meta-model will

lead to compilation errors detect problems as early as possible

Good idea: development of domain-framework (e.g. in Java); sample: map from your modeling of „my.Color“ to color-concept in programming language; develop against this framework

class ScreenSaver {

public static void main(String[] args) {

Shell shell = new Shell();

ScreenSaver config = readConfig(…);

if (config.getUserInterface().getBackGround() == my.Color.RED) {

shell.setBackGround(Color.RED);

} else {

…

}

…

}

private ScreenSaver readConfig(..) {

… // use generated code to read the config-file

}

}

1.2) Generative approach (alternative to 1.1)

class ScreenSaver {

public static void main(String[] args) {

Shell shell = new Shell();

shell.setBackGround(Color.GREEN);

}

}

<ScreenSaver>

<userInterface

backGround=„GREEN“/>

</ScreenSaver>

Goal: minimal amout of code at customer-site + better performance

Write a code-generator Input: configuration-

file/model/instance + a template

Output: customer-specific code

= avoidance of redundancy (everything is in template)

Note: Technology of generator (+ its input) is independent of code to generate!!! (e.g. use Java-based generator to generate C#-Code)

class ScreenSaver {

public static void main(String[] args) {

Shell shell = new Shell();

shell.setBackGround(Color.${config.userInterface.backGround});

}

}

Generator-Engine

Model/configurationTemplate

Resulting code

Modern modeling frameworks include mapping to XML-based representation

Validation of instances is supportedNo need to do additional workMapping to data-base (OR-Mapping)

supported by some of the frameworksIf you want special „syntax“

Write a parser (for text-based syntax)Write an graphical editor that

manipulates the instances (using the generated programming interface)

<ScreenSaver>

<userInterface

backGround=„RED“/>

</ScreenSaver>

2) Concrete syntax

It‘s important to document your meta-model/DSL

In a structured way.Using (mixture)

Text (pseudo) XML-Schema UML-class-diagrams …

meta-model is central source of information if changes regenerate documentation

General purpose tools (Word etc) do not support that approach

3) Documentation

The documentation of the ScreenSaver-DSL rendered as HTML

In first step, the tooling is for you internally (not shipped with product) makes your life easier

Can be generated directly from your meta-model + is customizeable

If the customer is „intelligent enough“, you can allow him to configure his product by himself tooling becomes part of your product makes customers life easier

it‘s a good idea to have the tooling in the same technology as your product (if possible); e.g. Eclipse RCP; OR have generators both for IDE and target technology

Customize your tooling with textual/graphical editors if required

4) Custom Tooling

Advanced things to think aboutYour meta-model/DSL will change

over time; how to support Updating the existing instances Marking parts of the meta-model as

„deprecated“ …

Defining (semantic) constraints E.g. using Object Constraint

Language (OCL)Tool integrated into the

development environment/IDE vs. standalone-tools

Reusing meta-modelsReferencing between

models/instances (tooling has to support that)

…

Integration of DSL into the development process

[C. Wienands; Siemens SCR]

How to create a DSL/Editor using CDF-Editor without writing one line of code

http://www.ulrich-dinger.de/cdf/cde.html

CDF Development

Tutorial

Ulrich Dinger

Those are my principles, and if you don't like them... well, I have others.

Ich habe eiserne Prinzipien. Wenn sie Ihnen nicht gefallen, habe ich auch noch andere.

[Groucho Marx]