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.

Code generation

2,307 views

Published on

Published in: Technology
  • If you are looking for trusted essay writing service I highly recommend ⇒⇒⇒WRITE-MY-PAPER.net ⇐⇐⇐ The service I received was great. I got an A on my final paper which really helped my grade. Knowing that I can count on them in the future has really helped relieve the stress, anxiety and workload. I recommend everyone to give them a try. You'll be glad you did.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

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

×