Model Driven Software Development and Domain Specific Languages in a Nutshell

1. 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 mail@ulrich-dinger.de 2009-11-16

2. 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]

3. 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?

4. 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)“

5. General concepts and terms 2/3 Model-Driven Software-Development (MDSD) Domain-concepts independent of presentation (= „abstract syntax“) Domain specific lanuages (DSL) Textual and graphical presentation of the concepts Java-Class (e.g. FireDetector.java) Valid sentence of grammar Model (Instance) Java Programming Language (Grammar) Grammar Meta-Model / Data Model / Domain Model / Schema / … ANTLR (another tool for language recognition) Meta-Grammar (e.g. (E)BNF ) Meta-Meta-Model (e.g.: Ecore) Example: Java as a DSL for the domain „object-oriented programming“ Terms in model-driven software development Terms in parser/compiler construction Instance of

6. General concepts and terms 3/3 UML – Unified Modeling Language • UML is a set of standardized modeling languages for different purposes • Class Diagram = static structures • Activity Diagram = flow of control • Sequence 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

7. Example • IPhone 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); … } }

8. 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.GREEN); … } } class ScreenSaver { public static void main(String[] args) { Shell shell = new Shell(); shell.setBackGround(Color.RED); … } }

9. backGround = red 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 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(..) { … } }

10. 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

11. 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>

12. Advantages of the model driven approach (technical) 1/2 Meta-Model (ScreenSaver UML) Model (instances/concrete configurations) Model (*.mot) Model (*.mot) Instance of Generate (>90%) Generate (>90%) manipulate read/write use 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

13. 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 • …

14. 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 • …

15. 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 } }

16. 1.2) Generative approach (alternative to 1.1) Template Model/configuration class ScreenSaver { public static void main(String[] args) { Shell shell = new Shell(); shell.setBackGround(Color.${config.userInterface.backGround}); } } • 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) <ScreenSaver> <userInterface backGround=„GREEN“/> </ScreenSaver> Generator-Engine class ScreenSaver { public static void main(String[] args) { Shell shell = new Shell(); shell.setBackGround(Color.GREEN); } } Resulting code

17. 2) Concrete syntax <ScreenSaver> <userInterface backGround=„RED“/> </ScreenSaver> • Modern modeling frameworks include mapping to XML-based representation • Validation of instances is supported • No need to do additional work • Mapping to data-base (OR-Mapping) supported by some of the frameworks • If you want special „syntax“ • Write a parser (for text-based syntax) • Write an graphical editor that manipulates the instances (using the generated programming interface)

18. 3) Documentation • 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 The documentation of the ScreenSaver-DSL rendered as HTML

19. 4) Custom Tooling • 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

20. Advanced things to think about • Your 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-models • Referencing between models/instances (tooling has to support that) • … Integration of DSL into the development process [C. Wienands; Siemens SCR]

21. Tutorial CDF Development • How to create a DSL/Editor using CDF-Editor without writing one line of code http://www.ulrich-dinger.de/cdf/cde.html Ulrich Dinger

22. 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]