Upload
darren
View
43
Download
0
Tags:
Embed Size (px)
DESCRIPTION
Model Driven Software Development and 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 [email protected] 2009-11-16. - PowerPoint PPT Presentation
Citation preview
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
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]