The document introduces model-driven development and domain-specific languages. It discusses how programming languages have evolved from being close to hardware to more abstract representations. Domain-specific languages allow focusing on specific concerns using natural notations for stakeholders. DSLs can be executed by transforming models into general purpose programs. The document provides examples of DSLs and discusses tools and standards for model-driven development.

1. Model-Driven Development An Introduction Markus Voelter Independent/itemis voelter@acm.org

4.  A littleHistory

5. programming started closetothehardware abstractions  computing chips

6. abstractions  computing bits

7. abstractions  computing C

8. abstractions  computing? Java

9. abstractions  computing? SQL

11. ?

13. generalpurpose

14. domainspecific

15. tailormade effective++ specialized, limited usedbyexperts togetherwithother specializedtools

17.  Domain SpecificLanguages

18. DSL A DSL is a focussed, processablelanguage for describing a specific concern when building a system in a specific domain. The abstractions and notations used are natural/suitablefor the stakeholders who specify that particular concern.

19. DSL A DSL is a focussed, processablelanguage for describing a specific concern when building a system in a specific domain. The abstractions and notations used are natural/suitablefor the stakeholders who specify that particular concern.

20. DSL A DSL is a focussed, processablelanguage for describing a specific concern when building a system in a specific domain. The abstractions and notations used are natural/suitablefor the stakeholders who specify that particular concern.

21. DSL A DSL is a focussed, processablelanguage for describing a specific concern when building a system in a specific domain. The abstractions and notations used are natural/suitablefor the stakeholders who specify that particular concern.

22. DSL A DSL is a focussed, processablelanguage for describing a specific concern when building a system in a specific domain. The abstractions and notations used are natural/suitablefor the stakeholders who specify that particular concern.

23. DSL A DSL is a focussed, processablelanguage for describing a specific concern when building a system in a specific domain. The abstractions and notations used are natural/suitablefor the stakeholders who specify that particular concern.

24. DSL A DSL is a focussed, processablelanguage for describing a specific concern when building a system in a specific domain. The abstractions and notations used are natural/suitablefor the stakeholders who specify that particular concern.

25. DSL A DSL is a focussed, processablelanguage for describing a specific concern when building a system in a specific domain. The abstractions and notations used are natural/suitablefor the stakeholders who specify that particular concern.

26. DSL A DSL is a focussed, processablelanguage for describing a specific concern when building a system in a specific domain. The abstractions and notations used are natural/suitablefor the stakeholders who specify that particular concern.

28. execute?

29. map

30. DSL Program (aka Model) map automated! GPL Program

31. map Generation Transformation Compilation Interpretation

34. Activities Analysing Domains DefiningLanguages Adapting/Selecting Building EditorsTransforming Models Building Generators Building Frameworks

35. Activities Analysing Domains DefiningLanguages Adapting/Selecting Building EditorsTransforming Models Building Generators Building Frameworks … andusing all ofthattobuildapps

37. internal vs. external

38. compiled vs. interpreted

39. customization vs. configuration

40. graphical vs. textual

42.  Examples

43. Textual DSL forTesting

44. BPEL Designer

45. Block DiagramforControlApps

46. Legacy Data Import

47. DSL Architecture Definition

48. DSL for DSL Semantics

50.  Tools

51. Tooling!

52. Tooling! Editor

53. Tooling! Editor, Debugger

54. Tooling! Editor, Debugger,Testing

55. Tooling! Editor, Debugger,Testing, Groupware

56. Tooling! Editor, Debugger,Testing, Groupware, Scalable

57. Tooling! Editor, Debugger,Testing, Groupware, Scalable, „All in Eclipse“

59. Tools Tooling Language Definition Tools abstractsyntax, concretesyntax, constraints Editor Frameworks Transformation Languages Code Generation Tools

61. EMF Ecore meta meta model + Editing Transactions Validation Query Distribution/Persistence

62. EMF Metamodel As Tree can also be editedas UML-like diagram

63. EMF Constraints with OCLand dialects

64. GMF Graphical Box/Line editors based on EMF

65. TMF / Xtext Building Textual Editors

66. TMF / Xtext Building Textual Editors

67. M2M Model-to-Model Transformations INRIA’s ATL QVTXtend

68. M2T Model-to-Text Transformations JET: Java Emitter TemplatesXpand: oAW’s template engine

69. M2T Model-to-Text Transformations Extensions to modularize complex expressions

70. openArchitectureWare www.openarchitectureware.org One Stop Toolkit for DSLs + X Version 4.3.1 is current Lively ecosystem of tools and extensions Proven track record in various domains & project contexts Stable, productive and helpful developer, support and user communities Integration with Eclipse: Uses EMF as a basis Graphical editors based on GMF All editors and tooling based on Eclipse

71. openArchitectureWare

72. oAW 5 To be released in June Xpand, Xtend, Check, MWE migrated to Eclipse projects Completely new, much more powerful Xtext/TMF

74.  Benefits

75. Automation faster, deterministic

76. Increased Quality well definedstructuresallthroughthesystem

77. Meaningful Validation moresemantics in the model

78. Capture Domain Knowledge formalizedintolanguagesandmodels

79. SuitableNotations textual, graphical, tabular

80. Technology Independence generate „technologygluecode“

81. Abstraction w/o Runtime Overhead generator „optimizesaway“

82. Capture ImplementationStrategy in thegenerators

83. Everythingis a model includingforexamplehardware (some) hardware

85.  Standards

87. Youcan model everything with

88. Youcan model everything with somehow!

89. Problem Shoehorningdomainabstractionsintothe genericlanguage

90. Problem Sidetrackedbyexistingabstractionsandnotations

91. Problem Very LimitedTool Support! Notations/ Abstractionsextensiblevia Profiles

92. Problem Meta Model Complexity!

93. But! Butdon‘treinventthewheeleither.

94. Wherearestandardsuseful?

95. Peoplehavetolearnunderlying concepts anyway.

96. Is UML witha profilestill a standardlanguage?

97. On whichmetaleveldo I wanttostandardize? M2 (UML), M3 (MOF)?

98. Isn‘t a DSLbased on MOFas „standard“ as a profilebased on UML?

99. Introduce an intermediate language

100. separate DSL viewpoints UML + DSL DS Model

102. THE END. .coordinates web email skypexinglinkedin www.voelter.devoelter@acm.orgschogglad http://www.xing.com/profile/Markus_Voelter http://www.linkedin.com/pub/0/377/a31

103. .coordinates web email skypexinglinkedin www.voelter.devoelter@acm.orgschogglad http://www.xing.com/profile/Markus_Voelter http://www.linkedin.com/pub/0/377/a31