Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Code generation

2.356 visualizaciones

Publicado el

Publicado en: Tecnología
  • Inicia sesión para ver los comentarios

Code generation

  1. 1. Code generation: Going all the way Rafael Chaves [email_address] http://alphasimple.com
  2. 2. Defining "code generation"
  3. 3. Code generation is everywhere <ul><li>IDE wizards </li></ul><ul><li>Web Frameworks (RoR, Grails, Spring Roo, Django...) </li></ul><ul><li>  </li></ul><ul><li>JSP -> Servlet compiler </li></ul><ul><li>  </li></ul><ul><li>ORM tools (HQL -> SQL, LINQ -> SQL) </li></ul><ul><li>XML tools (JAXB) </li></ul><ul><li>  </li></ul><ul><li>Any compiler (object code) </li></ul><ul><li>Modeling tools </li></ul><<< this will be our focus
  4. 4. Step 1: basic code generation from models
  5. 6. package banking; public class Account {     private Double balance;     public Double getBalance() {         return this.balance;     }     public void setBalance(Double balance) {         assert balance != null;         this.balance = balance;     }     public void deposit(Double amount) {         /* FILL ME IN */     }     public void withdraw(Double amount) {         /* FILL ME IN */     } }
  6. 7. Step 1 <ul><li>Good: </li></ul><ul><ul><li>generates boilerplate (example: getters/setters) </li></ul></ul><ul><ul><li>can take advantage of richer modeling features (multiplicity) into account </li></ul></ul><ul><li>  Bad: </li></ul><ul><ul><li>empty methods need to be filled in manually </li></ul></ul><ul><ul><li>regenerating will destroy manual changes </li></ul></ul><ul><ul><ul><li>generate once and take it from there? </li></ul></ul></ul><ul><li>Solution: </li></ul><ul><ul><li>protected regions </li></ul></ul>
  7. 8. Step 2: using protected regions
  8. 9. package banking; public class Account {     private Double balance;     public Double getBalance() {         return this.balance;     }     public void setBalance(Double balance) {         assert balance != null;         this.balance = balance;     }     public void deposit(Double amount) {         //BEGIN-USER-CODE         this.balance = this.balance + amount;         //END-USER-CODE         }    ... }
  9. 10. Step 2: Protected regions <ul><li>Good: </li></ul><ul><ul><li>Can regenerate whenever model changes </li></ul></ul><ul><ul><ul><li>Manual changes are preserved </li></ul></ul></ul><ul><li>  </li></ul><ul><li>Bad: </li></ul><ul><ul><li>Not supported by all code generation tools </li></ul></ul><ul><ul><li>Generated artifact or manual artifact? </li></ul></ul><ul><ul><ul><li>no gains w.r.t. cognitive load </li></ul></ul></ul><ul><ul><ul><li>SCM </li></ul></ul></ul><ul><li>  </li></ul><ul><li>Solution: </li></ul><ul><ul><li>&quot; generation gap &quot; pattern [Vlissides] </li></ul></ul><ul><li>  </li></ul><ul><li>  </li></ul>
  10. 11. Step 3: applying the Generation Gap pattern
  11. 12. Source: IBM Research
  12. 13. // GENERATED - DO NOT MODIFY package banking; public class AccountCore {     protected Double balance;     public Double getBalance() {         return this.balance;     }     public void setBalance(Double balance) {         assert balance != null;         this.balance = balance;     }     public void deposit(Double amount) {         // override me     }     public void withdraw(Double amount) {         // override me     } }
  13. 14. package banking; public class Account extends AccountCore {     public void deposit(Double amount) {         this.balance = this.balance + amount;     }     public void withdraw(Double amount) {         this.balance = this.balance - amount;     } }
  14. 15. Step 3: generation gap <ul><li>Good: </li></ul><ul><ul><li>tool support not required </li></ul></ul><ul><ul><li>clean separation between generated and hand-written code </li></ul></ul><ul><ul><li>cognitive load win </li></ul></ul><ul><ul><li>only handwritten code (and models) in SCM </li></ul></ul><ul><li>Bad: </li></ul><ul><ul><li>domain behavior still has to be written by hand </li></ul></ul><ul><ul><li>ugly duality: structure in models, behavior in code </li></ul></ul><ul><ul><li>how much are we really gaining? </li></ul></ul><ul><li>Solution: </li></ul><ul><ul><li>? </li></ul></ul>
  15. 16. What problem are we trying to solve again?
  16. 17. Enterprise software is much harder than it should be Problem domains are typically not very complex (information management + business rules) How come? Secondary concerns abound persistence, concurrency, (a)synchronism, distribution, transactions, security, caching, replication, logging, ...
  17. 18. Two dimensions of enterprise software <ul><li>Completely different beasts </li></ul><ul><ul><li>change rate </li></ul></ul><ul><ul><li>abstraction level </li></ul></ul><ul><ul><li>tools </li></ul></ul><ul><ul><li>skills </li></ul></ul><ul><ul><li>reuse </li></ul></ul><ul><li>  </li></ul><ul><li>  </li></ul><ul><li>  </li></ul><ul><li>  </li></ul>Why do we treat them the same? Business Technical <ul><ul><li>processes </li></ul></ul><ul><ul><li>entities  </li></ul></ul><ul><ul><li>attributes and relationships </li></ul></ul><ul><ul><li>constraints </li></ul></ul><ul><ul><li>actions </li></ul></ul><ul><ul><li>queries </li></ul></ul><ul><ul><li>technical architecture </li></ul></ul><ul><ul><li>design patterns </li></ul></ul><ul><ul><li>programming idioms </li></ul></ul><ul><ul><li>best practices </li></ul></ul>
  18. 19. Problem hypothesis: lack of separation between technical and domain concerns is the root of all evil
  19. 20. Solutions Using ordinary 3GL + reflection/AOP   Model-driven development with DSLs   Model-driven development with a GPL (like UML)
  20. 21. Using ordinary 3GL + reflection/AOP <ul><ul><li>Examples: Ruby On Rails, Grails, Django, Spring Roo, EJB </li></ul></ul><ul><ul><li>Pros </li></ul></ul><ul><ul><ul><li>you can model using your existing programming language </li></ul></ul></ul><ul><ul><ul><li>when done at runtime, avoids generation step </li></ul></ul></ul><ul><ul><li>Cons </li></ul></ul><ul><ul><ul><li>you can model using your existing programming language </li></ul></ul></ul><ul><ul><ul><ul><li>not meant for conceptual modeling </li></ul></ul></ul></ul><ul><ul><ul><ul><li>ties development time to deployment time </li></ul></ul></ul></ul><ul><ul><ul><li>too much magic? </li></ul></ul></ul>
  21. 22. Model-driven development (with DSL or GPL) <ul><ul><li>Examples: MetaEdit+, Xtext, MPS, WebRatio, Mendix, Bridgepoint UML, AlphaSimple </li></ul></ul><ul><ul><li>Pros </li></ul></ul><ul><ul><ul><li>Can use the best tool for the job: language optimized for conceptual modeling </li></ul></ul></ul><ul><ul><ul><li>platform independence* </li></ul></ul></ul><ul><ul><li>Cons </li></ul></ul><ul><ul><ul><li>DSL: need to build/maintain the language </li></ul></ul></ul><ul><ul><ul><li>GPL: may need to extend language (a bit like 3GLs) </li></ul></ul></ul><ul><ul><ul><li>Significant change in mindset/workflow </li></ul></ul></ul>
  22. 23. Solution hypothesis: Model-driven development with a GPL and full code generation
  23. 24. Models in software <ul><ul><li>brainstorming </li></ul></ul><ul><ul><li>communicating </li></ul></ul><ul><ul><li>documenting </li></ul></ul><ul><ul><li>understanding (rev. eng.) </li></ul></ul>That is not what MDD is about
  24. 25. Models in MDD <ul><ul><li>are the central artifacts in software (re: source vs. object code) </li></ul></ul><ul><ul><li>are well-formed </li></ul></ul><ul><ul><li>are precise </li></ul></ul><ul><ul><li>are complete </li></ul></ul><ul><ul><li>are executable (directly/code generation) </li></ul></ul><ul><ul><li>while still technology-independent </li></ul></ul>
  25. 26. Demo: Executable modeling and full code generation with AlphaSimple
  26. 27. Validating hypotheses
  27. 28. How disappointed would you be if AlphaSimple 1.0 didn't allow you to: <ul><ul><li>write your own templates </li></ul></ul><ul><ul><li>generate JPA code out-of-the-box </li></ul></ul><ul><ul><li>generate the entire code (back to partial code gen) </li></ul></ul><ul><ul><li>model behavior </li></ul></ul><ul><ul><li>run a prototype off of your model  </li></ul></ul><ul><ul><li>visualize your model as a class diagram </li></ul></ul><ul><ul><li>run code generation using Maven  </li></ul></ul><ul><ul><li>add your own! </li></ul></ul><ul><li>  </li></ul><ul><li>Alternatives </li></ul><ul><ul><li>very disappointed </li></ul></ul><ul><ul><li>somewhat disappointed </li></ul></ul><ul><ul><li>not disappointed </li></ul></ul>
  28. 29. Model-driven development is not about taking work (or fun) away from developers, but making their work more meaningful and valuable
  29. 30. Code generation: Going all the way Rafael Chaves [email_address] http://alphasimple.com

×