Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Introduction To MDD

2,370 views

Published on

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

Published in: Technology
  • Be the first to comment

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 />

×