Code generation
Upcoming SlideShare
Loading in...5
×
 

Code generation

on

  • 1,199 views

 

Statistics

Views

Total Views
1,199
Slideshare-icon Views on SlideShare
946
Embed Views
253

Actions

Likes
1
Downloads
7
Comments
0

7 Embeds 253

http://blog.abstratt.com 172
http://abstratt.com 71
http://paper.li 3
https://www.linkedin.com 3
http://www.linkedin.com 2
https://twitter.com 1
http://newsblur.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • code generator = a program that produces other programs
  • Code generation is just a tool   Productivity   Automate what can be automated    What problem does it solve?   To extract architectural decisions as reusable artifacts   To reduce time to market   To ensure consistency (developers like to pretend they are robots)
  • Code generation is just a tool   Productivity   Automate what can be automated    What problem does it solve?   To extract architectural decisions as reusable artifacts   To reduce time to market   To ensure consistency (developers like to pretend they are robots)

Code generation Code generation Presentation Transcript

  • Code generation: Going all the way Rafael Chaves [email_address] http://alphasimple.com
  • Defining "code generation"
  • Code generation is everywhere
    • IDE wizards
    • Web Frameworks (RoR, Grails, Spring Roo, Django...)
    •  
    • JSP -> Servlet compiler
    •  
    • ORM tools (HQL -> SQL, LINQ -> SQL)
    • XML tools (JAXB)
    •  
    • Any compiler (object code)
    • Modeling tools
    <<< this will be our focus
  • Step 1: basic code generation from models
  •  
  • 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 */     } }
  • Step 1
    • Good:
      • generates boilerplate (example: getters/setters)
      • can take advantage of richer modeling features (multiplicity) into account
    •   Bad:
      • empty methods need to be filled in manually
      • regenerating will destroy manual changes
        • generate once and take it from there?
    • Solution:
      • protected regions
  • Step 2: using protected regions
  • 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         }    ... }
  • Step 2: Protected regions
    • Good:
      • Can regenerate whenever model changes
        • Manual changes are preserved
    •  
    • Bad:
      • Not supported by all code generation tools
      • Generated artifact or manual artifact?
        • no gains w.r.t. cognitive load
        • SCM
    •  
    • Solution:
      • &quot; generation gap &quot; pattern [Vlissides]
    •  
    •  
  • Step 3: applying the Generation Gap pattern
  • Source: IBM Research
  • // 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     } }
  • 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;     } }
  • Step 3: generation gap
    • Good:
      • tool support not required
      • clean separation between generated and hand-written code
      • cognitive load win
      • only handwritten code (and models) in SCM
    • Bad:
      • domain behavior still has to be written by hand
      • ugly duality: structure in models, behavior in code
      • how much are we really gaining?
    • Solution:
      • ?
  • What problem are we trying to solve again?
  • 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, ...
  • Two dimensions of enterprise software
    • Completely different beasts
      • change rate
      • abstraction level
      • tools
      • skills
      • reuse
    •  
    •  
    •  
    •  
    Why do we treat them the same? Business Technical
      • processes
      • entities 
      • attributes and relationships
      • constraints
      • actions
      • queries
      • technical architecture
      • design patterns
      • programming idioms
      • best practices
  • Problem hypothesis: lack of separation between technical and domain concerns is the root of all evil
  • Solutions Using ordinary 3GL + reflection/AOP   Model-driven development with DSLs   Model-driven development with a GPL (like UML)
  • Using ordinary 3GL + reflection/AOP
      • Examples: Ruby On Rails, Grails, Django, Spring Roo, EJB
      • Pros
        • you can model using your existing programming language
        • when done at runtime, avoids generation step
      • Cons
        • you can model using your existing programming language
          • not meant for conceptual modeling
          • ties development time to deployment time
        • too much magic?
  • Model-driven development (with DSL or GPL)
      • Examples: MetaEdit+, Xtext, MPS, WebRatio, Mendix, Bridgepoint UML, AlphaSimple
      • Pros
        • Can use the best tool for the job: language optimized for conceptual modeling
        • platform independence*
      • Cons
        • DSL: need to build/maintain the language
        • GPL: may need to extend language (a bit like 3GLs)
        • Significant change in mindset/workflow
  • Solution hypothesis: Model-driven development with a GPL and full code generation
  • Models in software
      • brainstorming
      • communicating
      • documenting
      • understanding (rev. eng.)
    That is not what MDD is about
  • Models in MDD
      • are the central artifacts in software (re: source vs. object code)
      • are well-formed
      • are precise
      • are complete
      • are executable (directly/code generation)
      • while still technology-independent
  • Demo: Executable modeling and full code generation with AlphaSimple
  • Validating hypotheses
  • How disappointed would you be if AlphaSimple 1.0 didn't allow you to:
      • write your own templates
      • generate JPA code out-of-the-box
      • generate the entire code (back to partial code gen)
      • model behavior
      • run a prototype off of your model 
      • visualize your model as a class diagram
      • run code generation using Maven 
      • add your own!
    •  
    • Alternatives
      • very disappointed
      • somewhat disappointed
      • not disappointed
  • Model-driven development is not about taking work (or fun) away from developers, but making their work more meaningful and valuable
  • Code generation: Going all the way Rafael Chaves [email_address] http://alphasimple.com