Overcoming The Impedance Mismatch Between Source Code And Architecture

4,694 views
4,553 views

Published on

In this talk, I show why UML sucks and why developers should move away from writing *boring* code to writing *exciting* code!

Published in: Technology
8 Comments
5 Likes
Statistics
Notes
  • We will certainly see DSLs that gain wider adoption in their respective niche. SQL is a good example for this kind of DSL: very specific, very much to the point, and gained a huge adoption.

    However, I think most DSLs will be written in projects and they will *not* be written to be adopted widely. Why? Because they are specific to the project. Come to think of it, maybe I should coin the term 'project specific language'...
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • There will be an evolution of DSLs (similar to the general evolution of programming languages). Only intuitive understandable languages or languages that are derived from a common domain driven design will be used and will survive.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • While I agree that using and ’speaking’ a common DSL in a team results in higher productivity, I am not so sure about its maintenance. While the DSL may survive team changes, I still predict some organizational problems, like team relationships in a larger project. Well, honestly, any approach has its own problems. It’s just a matter of recognizing which ones are worse...
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Re: Everybody is having his own language, I address this problem on the last slides of the presentation. It’s not written on the slides, but my answer to this issue is: yes, we will have more languages than before and people will have to learn how to build good languages. However, you should develop a DSL for your particular project, e.g. an architectural DSL. If you do so, the DSL will be the language of the project team and they will be using the terms and concepts of this language even in their spoken communication. This will eventually result in an improved communication in your projects.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Re: debuggers - it’s true that they are missing. But looking at how much we actually have achieved in the field of model driven software development, I believe we’ll have DSL debuggers in less than 3 years from now, see http://students.cis.uab.edu/wuh/ddf/index.html.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
4,694
On SlideShare
0
From Embeds
0
Number of Embeds
9
Actions
Shares
0
Downloads
83
Comments
8
Likes
5
Embeds 0
No embeds

No notes for slide

Overcoming The Impedance Mismatch Between Source Code And Architecture

  1. 1. Overcoming the Impedance Mismatch Between Source Code and Architecture Peter Friese, itemis @peterfriese @xtext (c) 2009 Peter Friese. Distributed under the EDL V1.0 - http://www.eclipse.org/org/documents/edl-v10.php More info: http://www.peterfriese.de / http://www.itemis.com
  2. 2. Stop drawing useless diagrams and writing boring code Peter Friese, itemis @peterfriese @xtext (c) 2009 Peter Friese. Distributed under the EDL V1.0 - http://www.eclipse.org/org/documents/edl-v10.php More info: http://www.peterfriese.de / http://www.itemis.com
  3. 3. UML - One Language To Rule Them All http://en.wikipedia.org/wiki/File:UML_Diagrams.jpg
  4. 4. UML doesn’t cut it!
  5. 5. Increasing Gap
  6. 6. od els M Code Increasing Gap
  7. 7. (UML) Models = Shelfware http://www.flickr.com/photos/misterdna/49841409/
  8. 8. Solution: Two-Way Tools
  9. 9. Result: Bloated Diagrams No-one can understand Person SomeOtherMeaninglessClass User Author Administrator Librarian SomeOtherMeaninglessClass SomeOtherMeaninglessClass Library Fee Book Page SomeOtherMeaninglessClass Shelf Folder SomeOtherMeaninglessClass SomeOtherMeaninglessClass SomeOtherMeaninglessClass SomeOtherMeaninglessClass
  10. 10. Solution: Semantic Diagrams <<EntityBean>> Book title: String isbn: String
  11. 11. Instead of being a solution...
  12. 12. ... two-way tools have proven to be a dead-end http://www.flickr.com/photos/cgommel/561929101/
  13. 13. ... two-way tools have proven to be a dead-end http://www.flickr.com/photos/cgommel/561929101/
  14. 14. Let’s step back
  15. 15. What are the real problems?
  16. 16. Boring code
  17. 17. Accidental complexity
  18. 18. Wrong level of abstraction
  19. 19. Anatomy of Modern Software Software artifact
  20. 20. Anatomy of Modern Software manually written code Frameworks Libraries
  21. 21. Anatomy of Modern Software manually written code Frameworks schematic code (manually written) Libraries
  22. 22. (Rote) coding doesn’t cut it either!
  23. 23. Problems
  24. 24. Problems Can we solve them with models?
  25. 25. Yes, we can!
  26. 26. Code Generation Helps Model manually written code Generator Frameworks schematic code (generated) Libraries
  27. 27. MDSD Metamodel <<instanceof>> generated manually written Model Model code code Generator Platform
  28. 28. MDSD with UML Metamodel <<instanceof>> generated manually written Model Model code code Generator UML Platform
  29. 29. UML and MDSD
  30. 30. A Marriage Made in Heaven?
  31. 31. Not.
  32. 32. UML and MDSD ⊕ Existing tools ⊕ Good overview ⊕ Graphical - managers / clients like that ⊖ complex meta model ⊖ teamwork challenging at best ⊖ model evolution problematic ⊖ UML is too generic, it’s not a DSL ⊖ UML profiles don’t help either ⊖ tools not integrated in IDE ⊖ long round trips ⊖ developers don’t like diagrams that much
  33. 33. UML doesn’t cut it!
  34. 34. Looking at the drawbacks...
  35. 35. UML and MDSD ⊖ complex meta model ⊖ teamwork challenging at best ⊖ model evolution problematic ⊖ UML is too generic, it’s not a DSL ⊖ UML profiles don’t help either ⊖ tools not integrated in IDE ⊖ long round trips ⊖ developers don’t like diagrams that much
  36. 36. ... these are promises of DSLs!
  37. 37. What are DSLs?
  38. 38. Suppose...
  39. 39. You’d want to core an apple...
  40. 40. ... for your kids.
  41. 41. ? Right tool for the job?
  42. 42. Your trusty swiss army knife!
  43. 43. You can use it for other stuff, too. E.g., opening a bottle of wine.
  44. 44. Suppose...
  45. 45. You’d want to core a few more apples...
  46. 46. ... for an apple cake.
  47. 47. Still the best tool for the job?
  48. 48. Better use this one.
  49. 49. and this one:
  50. 50. BUT avoid the unitasker!
  51. 51. BUT avoid the unitasker!
  52. 52. A DSL is...
  53. 53. A specific tool for a specific job
  54. 54. A specific tool for a specific job
  55. 55. DSL Samples
  56. 56. select name, salary from employees where salary > 2000 order by salary
  57. 57. <project name="MyProject" default="dist" basedir="."> <property name="src" location="src"/> <property name="build" location="build"/> <property name="dist" location="dist"/> <target name="init"> <mkdir dir="${build}"/> </target> <target name="compile" depends="init"> <javac srcdir="${src}" destdir="${build}"/> </target> <target name="dist" depends="compile"> <mkdir dir="${dist}/lib"/> <jar jarfile="${dist}/lib/MyProject.jar" basedir="${build}"/> </target> <target name="clean"> <delete dir="${build}"/> <delete dir="${dist}"/> </target> </project>
  58. 58. <project name="MyProject" default="dist" basedir="."> <property name="src" location="src"/> <property name="build" location="build"/> <property name="dist" location="dist"/> <target name="init"> <mkdir dir="${build}"/> </target> <target name="compile" depends="init"> <javac srcdir="${src}" destdir="${build}"/> </target> <target name="dist" depends="compile"> <mkdir dir="${dist}/lib"/> <jar jarfile="${dist}/lib/MyProject.jar" basedir="${build}"/> </target> <target name="clean"> <delete dir="${build}"/> <delete dir="${dist}"/> </target> </project>
  59. 59. DSL Advantages ⊕ Focussed ⊕ Precise metamodel, perfect fit ⊕ No misuse / mismodeling (thanks to constrained meta model) ⊕ diff / merge possible ⊕ teamwork possible ⊕ developers like text ⊖ need to build your own tools
  60. 60. DSL Disadvantages ⊕ Focussed ⊕ Precise metamodel, perfect fit ⊕ No misuse / mismodeling (thanks to constrained meta model) ⊕ diff / merge possible ⊕ teamwork possible ⊕ developers like text ⊖ need to build your own tools
  61. 61. 1)Create ANTLR grammar 2)Generate lexer / parser 3)Parser will create parse tree 4)Transform parse tree to semantic model 5)Iterate model 6)Pass model element(s) to template
  62. 62. DSLs are...
  63. 63. Flexible
  64. 64. Adaptable
  65. 65. Complicated
  66. 66. Expensive
  67. 67. - A DSL for Writing DSLs
  68. 68. Underlying Technology
  69. 69. ar Model m m ra G Generator Runtime Superclass Subclass Class LL(*) Parser ECore meta model Editor
  70. 70. Grammar (similar to EBNF) grammar org.xtext.example.Entity with org.eclipse.xtext.common.Terminals generate entity "http://www.xtext.org/example/Entity" Model: (types+=Type)*; Type: TypeDef | Entity; TypeDef: "typedef" name=ID ("mapsto" mappedType=JAVAID)?; JAVAID: name=ID("." ID)*; Entity: "entity" name=ID ("extends" superEntity=[Entity])? "{" (attributes+=Attribute)* "}"; Attribute: type=[Type] (many?="*")? name=ID;
  71. 71. grammar org.xtext.example.Entity with org.eclipse.xtext.common.Terminals Meta model inference generate entity "http://www.xtext.org/example/Entity" entity Model: (types+=Type)*; Model Type: TypeDef | Entity; types TypeDef: * Type "typedef" name=ID name: EString ("mapsto" mappedType=JAVAID)?; superEntity JAVAID: name=ID("." ID)*; TypeDef Entity Entity: mappedType attributes "entity" name=ID Attribute ("extends" superEntity=[Entity])? JAVAID name: EString "{" name: EString many: EBoolean (attributes+=Attribute)* "}"; type Attribute: type=[Type] (many?="*")? name=ID;
  72. 72. grammar org.xtext.example.Entity with org.eclipse.xtext.common.Terminals Meta model inference generate entity "http://www.xtext.org/example/Entity" entity Rules -> Classes Model: (types+=Type)*; Model Type: TypeDef | Entity; types TypeDef: * Type "typedef" name=ID name: EString ("mapsto" mappedType=JAVAID)?; superEntity JAVAID: name=ID("." ID)*; TypeDef Entity Entity: mappedType attributes "entity" name=ID Attribute ("extends" superEntity=[Entity])? JAVAID name: EString "{" name: EString many: EBoolean (attributes+=Attribute)* "}"; type Attribute: type=[Type] (many?="*")? name=ID;
  73. 73. grammar org.xtext.example.Entity with org.eclipse.xtext.common.Terminals Meta model inference generate entity "http://www.xtext.org/example/Entity" entity Alternatives -> Hierarchy Model: (types+=Type)*; Model Type: TypeDef | Entity; types TypeDef: * Type "typedef" name=ID name: EString ("mapsto" mappedType=JAVAID)?; superEntity JAVAID: name=ID("." ID)*; TypeDef Entity Entity: mappedType attributes "entity" name=ID Attribute ("extends" superEntity=[Entity])? JAVAID name: EString "{" name: EString many: EBoolean (attributes+=Attribute)* "}"; type Attribute: type=[Type] (many?="*")? name=ID;
  74. 74. grammar org.xtext.example.Entity with org.eclipse.xtext.common.Terminals Meta model inference generate entity "http://www.xtext.org/example/Entity" entity Assignment -> Feature Model: (types+=Type)*; Model Type: TypeDef | Entity; types TypeDef: * Type "typedef" name=ID name: EString ("mapsto" mappedType=JAVAID)?; superEntity JAVAID: name=ID("." ID)*; TypeDef Entity Entity: mappedType attributes "entity" name=ID Attribute ("extends" superEntity=[Entity])? JAVAID name: EString "{" name: EString many: EBoolean (attributes+=Attribute)* "}"; type Attribute: type=[Type] (many?="*")? name=ID;
  75. 75. Demo
  76. 76. Do DSLs cut it?
  77. 77. Yes, they do
  78. 78. Yes, they do
  79. 79. Yes, they do
  80. 80. Yes, they do
  81. 81. Concentrate on Essentials
  82. 82. Higher Efficiency
  83. 83. Better Maintainability
  84. 84. No More Boring Code
  85. 85. A New Babylonic Plethora of Languages?
  86. 86. DSLs will improve communication in projects
  87. 87. Four Things To Take Home Beware of the shelfware trap Stop writing boring code Choose appropriate abstractions Better understand your stakeholders

×