Overcoming The Impedance Mismatch Between Source Code And Architecture

Loading...

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

8 comments

Comments 1 - 8 of 8 previous next Post a comment

  • + peterfriese Peter Friese 1 month ago
    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'...
  • + GuenterJantzen GuenterJantzen 1 month ago
    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.
  • + rui_curado Rui Curado 1 month ago
    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...
  • + peterfriese Peter Friese 1 month ago
    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.
  • + peterfriese Peter Friese 1 month ago
    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.
  • + rui_curado Rui Curado 1 month ago
    Sorry, but I do not believe in DSL’s either. For me is just a maintenance catastrophe waiting to happen. Imagine everyone having his own language.

    However I do agree that UML doesn’t cut it, and I believe in models. For a pragmatic approach to MDSD, you should check ABSE (http://www.abse.info).
  • + softwarecarpentry Software Carpentry 1 month ago
    Nice presentation, but I’m not going to believe DSLs are the answer until someone demonstrates DSDs (domain-specific debuggers). We know that debugging and maintenance are the largest lifetime costs in any software project; if a DSL makes it easier for me to express my initial solution, but makes it *harder* for me to track down problems, the odds are it will be a net increase in cost, not a net reduction.
  • + peterfriese Peter Friese 1 month ago
    By the way, if you would like to learn more about DSLs, Model Driven Software Development, Xtext or any other technology mentioned in this talk - just contact me. I am happy to deliver this talk live.

    The same holds true for the other Xtext committers, some of which also have posted slide decks here on SlideShare. See the Xtext group for more presentations: http://www.slideshare.net/group/xtext
Post a comment
Embed Video
Edit your comment Cancel

3 Favorites & 1 Group

Overcoming The Impedance Mismatch Between Source Code And Architecture - Presentation Transcript

  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. 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. 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
  4. UML - One Language To Rule Them All http://en.wikipedia.org/wiki/File:UML_Diagrams.jpg
  5. UML doesn’t cut it!
  6. Increasing Gap
  7. od els M Code Increasing Gap
  8. (UML) Models = Shelfware http://www.flickr.com/photos/misterdna/49841409/
  9. Solution: Two-Way Tools
  10. 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
  11. Solution: Semantic Diagrams <<EntityBean>> Book title: String isbn: String
  12. Instead of being a solution...
  13. ... two-way tools have proven to be a dead-end http://www.flickr.com/photos/cgommel/561929101/
  14. ... two-way tools have proven to be a dead-end http://www.flickr.com/photos/cgommel/561929101/
  15. Let’s step back
  16. What are the real problems?
  17. Boring code
  18. Accidental complexity
  19. Wrong level of abstraction
  20. Anatomy of Modern Software Software artifact
  21. Anatomy of Modern Software manually written code Frameworks Libraries
  22. Anatomy of Modern Software manually written code Frameworks schematic code (manually written) Libraries
  23. (Rote) coding doesn’t cut it either!
  24. (Rote) coding doesn’t cut it either!
  25. Problems
  26. Problems
  27. Problems Can we solve them with models?
  28. Yes, we can!
  29. Code Generation Helps Model manually written code Generator Frameworks schematic code (generated) Libraries
  30. MDSD Metamodel <<instanceof>> generated manually written Model Model code code Generator Platform
  31. MDSD with UML Metamodel <<instanceof>> generated manually written Model Model code code Generator UML Platform
  32. UML and MDSD
  33. A Marriage Made in Heaven?
  34. Not.
  35. UML and MDSD
  36. UML and MDSD ⊕ Existing tools
  37. UML and MDSD ⊕ Existing tools ⊕ Good overview
  38. UML and MDSD ⊕ Existing tools ⊕ Good overview ⊕ Graphical - managers / clients like that
  39. UML and MDSD ⊕ Existing tools ⊕ Good overview ⊕ Graphical - managers / clients like that ⊖ complex meta model
  40. UML and MDSD ⊕ Existing tools ⊕ Good overview ⊕ Graphical - managers / clients like that ⊖ complex meta model ⊖ teamwork challenging at best
  41. UML and MDSD ⊕ Existing tools ⊕ Good overview ⊕ Graphical - managers / clients like that ⊖ complex meta model ⊖ teamwork challenging at best ⊖ model evolution problematic
  42. 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
  43. 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
  44. 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
  45. 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
  46. 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
  47. UML doesn’t cut it!
  48. Looking at the drawbacks...
  49. 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
  50. 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
  51. 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
  52. ... these are promises of DSLs!
  53. What are DSLs?
  54. Suppose...
  55. You’d want to core an apple...
  56. ... for your kids.
  57. ? Right tool for the job?
  58. Your trusty swiss army knife!
  59. You can use it for other stuff, too. E.g., opening a bottle of wine.
  60. Suppose...
  61. You’d want to core a few more apples...
  62. ... for an apple cake.
  63. Still the best tool for the job?
  64. Better use this one.
  65. and this one:
  66. BUT avoid the unitasker!
  67. BUT avoid the unitasker!
  68. A DSL is...
  69. A specific tool for a specific job
  70. A specific tool for a specific job
  71. DSL Samples
  72. select name, salary from employees where salary > 2000 order by salary
  73. <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>
  74. <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>
  75. DSL Advantages
  76. DSL Advantages ⊕ Focussed
  77. DSL Advantages ⊕ Focussed ⊕ Precise metamodel, perfect fit
  78. DSL Advantages ⊕ Focussed ⊕ Precise metamodel, perfect fit ⊕ No misuse / mismodeling (thanks to
  79. DSL Advantages ⊕ Focussed ⊕ Precise metamodel, perfect fit ⊕ No misuse / mismodeling (thanks to constrained meta model)
  80. DSL Advantages ⊕ Focussed ⊕ Precise metamodel, perfect fit ⊕ No misuse / mismodeling (thanks to constrained meta model) ⊕ diff / merge possible
  81. DSL Advantages ⊕ Focussed ⊕ Precise metamodel, perfect fit ⊕ No misuse / mismodeling (thanks to constrained meta model) ⊕ diff / merge possible ⊕ teamwork possible
  82. DSL Advantages ⊕ Focussed ⊕ Precise metamodel, perfect fit ⊕ No misuse / mismodeling (thanks to constrained meta model) ⊕ diff / merge possible ⊕ teamwork possible ⊕ developers like text
  83. 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
  84. 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
  85. 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
  86. DSLs are...
  87. Flexible
  88. Adaptable
  89. Complicated
  90. Expensive
  91. - A DSL for Writing DSLs
  92. Underlying Technology
  93. Model G ra m m ar
  94. ar Model m m ra G Generator
  95. ar Model m m ra G Generator Runtime Superclass Subclass Class LL(*) Parser ECore meta model Editor
  96. ar Model m m ra G Generator Runtime Superclass Subclass Class LL(*) Parser ECore meta model Editor
  97. 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;
  98. 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;
  99. 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;
  100. 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;
  101. 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;
  102. 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;
  103. 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;
  104. 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;
  105. ar Model m m ra G Generator Fragments Generator Runtime Superclass Subclass Class LL(*) Parser ecore meta model editor
  106. ar Model m m ra G Generator Runtime Google Guice Superclass Subclass Class LL(*) Parser ecore meta model editor
  107. Demo
  108. @SuppressWarnings("serial") @Entity @Table(name = "CUSTOMER_INFO") public class CustomerInfo implements Serializable { @Id @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "idSeq") @SequenceGenerator(name = "idSeq", sequenceName = "CUST_SEQ", allocationSize = 1) @Column(name = "CUST_ID", nullable = false) private String customerId; public void setCustomerId(String customerId) { this.customerId = customerId; } public String getCustomerId() { return customerId; } @Column(name = "EMAIL", nullable = false, length = 128) private String emailAddress; public String getEmailAddress() { return emailAddress; } public void setEmailAddress(String emailAddress) { String oldValue = emailAddress; this.emailAddress = emailAddress; firePropertyChangedEvent("emailAddress", oldValue, this.emailAddress); }
  109. @SuppressWarnings("serial") @Entity @Table(name = "CUSTOMER_INFO") public class CustomerInfo implements Serializable { @Id @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "idSeq") @SequenceGenerator(name = "idSeq", sequenceName = "CUST_SEQ", allocationSize = 1) @Column(name = "CUST_ID", nullable = false) private String customerId; public void setCustomerId(String customerId) { this.customerId = customerId; } public String getCustomerId() { return customerId; } @Column(name = "EMAIL", nullable = false, length = 128) private String emailAddress; public String getEmailAddress() { return emailAddress; } public void setEmailAddress(String emailAddress) { String oldValue = emailAddress; this.emailAddress = emailAddress; firePropertyChangedEvent("emailAddress", oldValue, this.emailAddress); }
  110. entity CustomerInfo (id=CUST_ID, sequenceName=CUST_SEQ) { String emailAddress (notNull, length = 128) }
  111. entity CustomerInfo (id=CUST_ID, sequenceName=CUST_SEQ) { String emailAddress (notNull, length = 128) } Bean DAO (POJO)
  112. Do DSLs cut it?
  113. Yes, they do
  114. Yes, they do
  115. Yes, they do
  116. Yes, they do
  117. Concentrate on Essentials
  118. Higher Efficiency
  119. Better Maintainability
  120. No More Boring Code
  121. A New Babylonic Plethora of Languages?
  122. DSLs will improve communication in projects
  123. Committers Heiko Sven Moritz Peter Dennis Jan Patrick Sebastian Michael Knut Behrens Efftinge Eysholdt Friese Hübner Köhnlein Schönbach Zarnekow Clay Wannheden Individual

+ Peter FriesePeter Friese, 1 month ago

custom

1173 views, 3 favs, 0 embeds more stats

In this talk, I show why UML sucks and why develope more

More info about this document

© All Rights Reserved

Go to text version

  • Total Views 1173
    • 1173 on SlideShare
    • 0 from embeds
  • Comments 8
  • Favorites 3
  • Downloads 30
Most viewed embeds

more

All embeds

less

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate. If needed, use the feedback form to let us know more details.

Cancel
File a copyright complaint
Having problems? Go to our helpdesk?

Categories

Groups / Events