Introduction To MDD

2,178 views
2,047 views

Published on

This is my brief standard introduction to Model-Driven Development and DSLs.

Published in: Technology
0 Comments
13 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,178
On SlideShare
0
From Embeds
0
Number of Embeds
9
Actions
Shares
0
Downloads
0
Comments
0
Likes
13
Embeds 0
No embeds

No notes for slide

Introduction To MDD

  1. 1. Model-Driven<br />Development<br />An Introduction<br />Markus Voelter<br />Independent/itemis<br />voelter@acm.org<br />
  2. 2.
  3. 3.
  4. 4. <br />A littleHistory<br />
  5. 5. programming<br />started<br />closetothehardware<br />abstractions<br /><br />computing<br />chips<br />
  6. 6. abstractions<br /><br />computing<br />bits<br />
  7. 7. abstractions<br /><br />computing<br /> C<br />
  8. 8. abstractions<br /><br />computing?<br /> Java<br />
  9. 9. abstractions<br /><br />computing?<br /> SQL<br />
  10. 10.
  11. 11. ?<br />
  12. 12.
  13. 13. generalpurpose<br />
  14. 14. domainspecific<br />
  15. 15. tailormade<br />effective++<br />specialized, limited<br />usedbyexperts<br />togetherwithother<br />specializedtools<br />
  16. 16.
  17. 17. <br />Domain SpecificLanguages<br />
  18. 18. DSL<br />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.<br />
  19. 19. DSL<br />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.<br />
  20. 20. DSL<br />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.<br />
  21. 21. DSL<br />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.<br />
  22. 22. DSL<br />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.<br />
  23. 23. DSL<br />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.<br />
  24. 24. DSL<br />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.<br />
  25. 25. DSL<br />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.<br />
  26. 26. DSL<br />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.<br />
  27. 27.
  28. 28. execute?<br />
  29. 29. map<br />
  30. 30. DSL Program<br />(aka Model)<br />map<br />automated!<br />GPL Program<br />
  31. 31. map<br />Generation<br />Transformation<br />Compilation<br />Interpretation<br />
  32. 32.
  33. 33.
  34. 34. Activities<br />Analysing Domains<br />DefiningLanguages<br />Adapting/Selecting<br />Building EditorsTransforming Models<br />Building Generators<br />Building Frameworks<br />
  35. 35. Activities<br />Analysing Domains<br />DefiningLanguages<br />Adapting/Selecting<br />Building EditorsTransforming Models<br />Building Generators<br />Building Frameworks<br />… andusing all ofthattobuildapps<br />
  36. 36.
  37. 37. internal<br />vs.<br />external<br />
  38. 38. compiled<br />vs.<br />interpreted<br />
  39. 39. customization<br />vs.<br />configuration<br />
  40. 40. graphical<br />vs.<br />textual<br />
  41. 41.
  42. 42. <br />Examples<br />
  43. 43. Textual DSL forTesting<br />
  44. 44. BPEL Designer<br />
  45. 45. Block DiagramforControlApps<br />
  46. 46. Legacy Data Import<br />
  47. 47. DSL Architecture Definition<br />
  48. 48. DSL for DSL Semantics<br />
  49. 49.
  50. 50. <br />Tools<br />
  51. 51. Tooling!<br />
  52. 52. Tooling!<br />Editor<br />
  53. 53. Tooling!<br />Editor, Debugger<br />
  54. 54. Tooling!<br />Editor, Debugger,Testing<br />
  55. 55. Tooling!<br />Editor, Debugger,Testing, Groupware<br />
  56. 56. Tooling!<br />Editor, Debugger,Testing, Groupware, <br />Scalable<br />
  57. 57. Tooling!<br />Editor, Debugger,Testing, Groupware, <br />Scalable, „All in Eclipse“<br />
  58. 58.
  59. 59. Tools Tooling<br />Language Definition Tools <br />abstractsyntax, concretesyntax, constraints<br />Editor Frameworks<br />Transformation Languages<br />Code Generation Tools<br />
  60. 60.
  61. 61. EMF<br />Ecore meta meta model<br /> +<br />Editing<br /> Transactions<br /> Validation<br /> Query<br /> Distribution/Persistence<br />
  62. 62. EMF<br />Metamodel As Tree<br />can also be editedas UML-like diagram<br />
  63. 63. EMF<br />Constraints<br />with OCLand dialects<br />
  64. 64. GMF<br />Graphical Box/Line editors based on EMF<br />
  65. 65. TMF / Xtext<br />Building Textual Editors<br />
  66. 66. TMF / Xtext<br />Building Textual Editors<br />
  67. 67. M2M<br />Model-to-Model Transformations<br /> INRIA’s ATL<br /> QVTXtend<br />
  68. 68. M2T<br />Model-to-Text Transformations<br /> JET: Java Emitter TemplatesXpand: oAW’s<br /> template engine<br />
  69. 69. M2T<br />Model-to-Text Transformations<br /> Extensions to modularize complex expressions<br />
  70. 70. openArchitectureWare<br />www.openarchitectureware.org<br />One Stop Toolkit for DSLs + X<br />Version 4.3.1 is current<br />Lively ecosystem of tools and extensions<br />Proven track record in various domains & project contexts<br />Stable, productive and helpful developer, support and user communities<br />Integration with Eclipse:<br />Uses EMF as a basis<br />Graphical editors based on GMF<br />All editors and tooling based on Eclipse<br />
  71. 71. openArchitectureWare<br />
  72. 72. oAW 5<br />To be released in June<br />Xpand, Xtend, Check, MWE migrated to Eclipse projects<br /> Completely new, much more powerful Xtext/TMF<br />
  73. 73.
  74. 74. <br />Benefits<br />
  75. 75. Automation<br />faster, deterministic<br />
  76. 76. Increased Quality<br />well definedstructuresallthroughthesystem<br />
  77. 77. Meaningful Validation<br />moresemantics in the model<br />
  78. 78. Capture<br />Domain Knowledge<br />formalizedintolanguagesandmodels<br />
  79. 79. SuitableNotations<br />textual, graphical, tabular<br />
  80. 80. Technology Independence<br />generate „technologygluecode“<br />
  81. 81. Abstraction w/o<br />Runtime Overhead<br />generator „optimizesaway“<br />
  82. 82. Capture <br />ImplementationStrategy<br />in thegenerators<br />
  83. 83. Everythingis a model<br />includingforexamplehardware (some) hardware<br />
  84. 84.
  85. 85. <br />Standards<br />
  86. 86.
  87. 87. Youcan model<br />everything<br />with<br />
  88. 88. Youcan model<br />everything<br />with<br />somehow!<br />
  89. 89. Problem<br />Shoehorningdomainabstractionsintothe<br />genericlanguage<br />
  90. 90. Problem<br />Sidetrackedbyexistingabstractionsandnotations<br />
  91. 91. Problem<br />Very LimitedTool Support!<br />Notations/ Abstractionsextensiblevia Profiles<br />
  92. 92. Problem<br />Meta Model<br />Complexity!<br />
  93. 93. But!<br />Butdon‘treinventthewheeleither.<br />
  94. 94. Wherearestandardsuseful?<br />
  95. 95. Peoplehavetolearnunderlying<br />concepts anyway.<br />
  96. 96. Is UML witha profilestill a standardlanguage?<br />
  97. 97. On whichmetaleveldo I wanttostandardize?<br />M2 (UML), M3 (MOF)?<br />
  98. 98. Isn‘t a DSLbased on MOFas „standard“ as a profilebased on UML?<br />
  99. 99. Introduce an <br />intermediate<br />language<br />
  100. 100. separate<br />DSL<br />viewpoints<br />UML + DSL<br />DS Model<br />
  101. 101.
  102. 102. THE END.<br />.coordinates<br />web email skypexinglinkedin<br />www.voelter.devoelter@acm.orgschogglad<br />http://www.xing.com/profile/Markus_Voelter<br />http://www.linkedin.com/pub/0/377/a31<br />
  103. 103. .coordinates<br />web email skypexinglinkedin<br />www.voelter.devoelter@acm.orgschogglad<br />http://www.xing.com/profile/Markus_Voelter<br />http://www.linkedin.com/pub/0/377/a31<br />

×