• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Eclipse EDT - EGL Inner Workings - June 2011
 

Eclipse EDT - EGL Inner Workings - June 2011

on

  • 60,213 views

See www.eclipse.org/edt for more details.

See www.eclipse.org/edt for more details.

Statistics

Views

Total Views
60,213
Views on SlideShare
1,723
Embed Views
58,490

Actions

Likes
1
Downloads
32
Comments
0

15 Embeds 58,490

http://www.eclipse.org 50974
http://eclipse.org 7147
https://www.eclipse.org 258
http://translate.googleusercontent.com 85
http://cache.baidu.com 5
http://webcache.googleusercontent.com 4
http://fanyi.youdao.com 4
https://eclipse.org 3
http://207.46.192.232 2
http://131.253.14.66 2
https://translate.googleusercontent.com 2
http://hghltd.yandex.net 1
http://dev.eclipse.org 1
http://localhost 1
http://translate.yandex.net 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
  • Author Notes: This is the PowerPoint template for the Innovate 2011 Track Sessions ALL FINAL FILES MUST BE CONVERTED TO LOTUS SYMPHONY. Learn more here: http://w3.ibm.com/connections/wikis/home?lang=en#/wiki/Rational%27s%20Phased%20Approach%20in%20Migrating%20to%20Lotus%20Symphony Additional IBM Rational presentation resources can be found on Rational’s Managing the Brand W3 Intranet site: https://w3-03.ibm.com/software/marketing/marksite.nsf/AllMarketingPages/Brand-Rational-rt_rtb?opendocument?opendocument Third party material cannot be used in a presentation without written permission (this includes product and Web page screen shots). Images must be acquired from a ‘royalty-free to use’ source such as: Microsoft Clip Art library http://www.freebyte.com/clipart_images_photos_icons/#freevectorgraphics http:// www.freedigitalphotos.net / IBMers can use images from: IBM image library: https://w3-03.ibm.com/software/marketing/marksite.nsf/AllMarketingPages/Brand-Rational-rt_rtb?OpenDocument&ExpandSection=3,2#_Section3 Royalty free images in Marketing Asset Manager database (you will need to register to access this site) : http://217.28.164.25/IBM001/templates/login.html

Eclipse EDT - EGL Inner Workings - June 2011 Eclipse EDT - EGL Inner Workings - June 2011 Presentation Transcript

  • The Inner Workings of EGL: a Solution to the Complexities of Modern Application Development Tim W Wilson STSM & EGL Chief Architect, IBM [email_address]
  • Agenda
    • Motivation for an Open EGL
    • Structure of EGL language
    • Extending the EGL language
      • Adding abstract concepts
      • Extending Code Generation
    • Demo
      • Extended Java code generation for native Android application
  • Evolution of Language Abstraction Hardware OS Runtime Platform Assembler C, COBOL Java EGL One One One One One One One Many Many Many One Single Machine Multiple Machine Future One Many Evolution of Execution Environment Evolution of Programming Languages Range of Deployment Options
  • Model Driven Development (MDD) and Platform Independence
    • MDD uses UML to define Platform Independent Models (PIMs)
    • Model Compilers read these models and ‘compile’ them to Platform Specific Models (PSMs)
      • Abstract concepts mapped to concrete implementations for a given platform
    • If all programming can stay at the PIM level then one can say that the programming language is Platform Independent
    • UML is just another programming language when used to program an entire application without ever dropping down into the generated code
      • Why should it be the only programming language that does this?
  • EGL Compiler as Model Compiler
    • EGL is a programming language mixed together with a modeling mechanism and extensible model compiler
      • Designed with the intention of expressing precise execution semantics
    • What is an Extensible Model Compiler?
      • New concepts added to programming model
        • e.g. Entity, UI programming model, new Datatypes (i.e. ZonedUnicodeDecimal)
      • Existing compiler extended to map instances of new concepts used in the code to appropriate runtime
      • Very high fidelity interleaving of new extended code generation into existing code generation
        • Can override/extend any aspect down to low level Expressions
    • The term ‘Extension’ in the context of EGL means anything added in the programming model that requires the code generation be extended to implement the specified semantics of the extensions
  • Motivation for Open EGL: EGL Development Tools on Eclipse (EDT)
    • EGL can target diverse platforms for the same code because it models everything in a platform independent way
      • Platform specifics are stated as input to model compiler
    • IBM has been the only one able to define new abstractions and transformations
    • General interest in this approach can only occur if others can do the same thing
    • The purpose of EDT is to provide others the ability to:
      • create domain specific extensions, i.e. UI programming, DB IO, etc
      • create new or extend existing transforms to make concrete the new extensions
      • have development environment (IDE) able to use these extended compilers
        • i.e. debug at EGL source code level for java and javascript target environments
  • Agenda
    • Motivation for an Open EGL
    • Structure of EGL language
    • Extending the EGL language
      • Adding abstract concepts
      • Extending Code Generation
    • Demo
      • Extended Java code generation for native Android application
  • EGL Basic Concepts
    • Various component types that programmers can define
      • Data Item – Creates a Type alias from extended data declaration
      • Record - aggregate of typed fields into new type
      • Program - Main program starts run unit – used for batch processing
      • Library – Static set of data and functions – local to run-unit
      • Service – Remotable set of functions
      • Interface – Abstract definition of a Service
      • Handler – Object-based component containing instance data and functions
      • ExternalType – Abstract type definition of a type implementation that exists outside of EGL
    • Annotations and Stereotypes
      • Meta data applied to program elements
      • Drives transformations as well as tooling
    • Abstract Statements meant to be extended
      • get, add, delete, replace, close, call, etc.
  • EGL Syntactic Structure All type definitions are in a package Imports of types outside current package Declaration of a program Data and Function declarations Statements and Expressions Extensible IO Statement Function invocation
  • Extending EGL
    • Extension means:
      • Any addition that requires the compiler be extended to map the extension to an appropriate runtime
    • Categories of Extension
      • Native Types
        • Type definitions that are abstract only and depend on the compiler to map them to appropriate runtime type
      • Simple Types - types that have no internal structure
        • Is a special kind of native type
      • Stereotypes, Annotations - metadata applied to types and members
      • Extensible Action Statements
        • Statements sensitive to the Stereotype metadata associated with its operands
  • EGL Extensions: Simple Types
    • There are no built-in ‘primitive types’ in EGL
    • All types have an explicit definition
    • Simple types highlighted as keywords are aliases for some explicit type definition
    • Types aliases are configurable
    • All valid operators are defined on each type
    • Valid conversions between types defined explicitly
    decimal  egl.lang.AnyDecimal string  egl.lang.AnyString
  • Simple Type Example: egl.lang.AnyDecimal
    • All Simple Types are externaltype declarations
      • External types denote the implementation is outside of EGL
      • The type declaration signifies to the compiler how the type can be used
      • Code generation will map the use of these types to appropriate runtime
    Previous code example
  • EGL Extensions: Native Types
    • Native types are abstract definitions that represent some native implementation
    • The compiler is responsible for mapping uses of a given type to an implementation
    • SysLib is a Native Type
    • The function writeStdOut () is mapped to platform specific implementation
      • Java: System.out.println()
      • COBOL: DISPLAY…
    • Native types allow modeling of platform independent concepts
    • Extensible code generation allows the use of these types to be folded into an existing compiler
  • Native Type Example: egl.lang.SysLib Completely abstract API – concrete implementations dependent on target platform
  • EGL Extensions: Stereotypes and Annotations
    • Stereotypes allow typed metadata to be applied to any type
    • Annotations allow typed metadata to be applied to any member (field, function…)
  • EGL Extensions: Extensible Action Statements
    • EGL contains a set of abstract ‘Action’ statements
      • add, close, delete, get, open, replace, etc
    • Action statements have an abstract execution specification that is made concrete by the metadata associated with the given operands
      • get – read an object from a data source
      • add – add an object to a data source
    • This example shows the use of a variable in which its type has the ‘ Entity ’ stereotype applied
    • The abstract semantic of GET plus the supplied metadata of ‘ Entity ’ allows a concrete specification
    • Code generator extended to implement the GET as an SQL SELECT statement
      • Entity metadata supplied the necessary mapping to the database tables
  • EDT – Code compilation process Java EGL Source Code EGL Compiler Model Extensible Code Generation Framework Java JavaScript C/C++ .Net … Pluggable Generators Eclipse JEE Dojo Pluggable Extension Examples Possible Android COBOL CICS/IMS
  • EGL Structure: The EGL Model
  • EGL Model So – how are all these classes defined?
  • EGL Program Definition: Detail
    • All EGL Model Classes are a subclass of Element
    • All EGL Model Classes are instances of EClass as denoted by the <<EClass>> stereotyping in the diagram
    • What is an EClass?
  • The MOF (Meta Object Framework) Model
  • EDT MOF Framework
    • All values are instances of EObject – including EClass
    • All EObject values have a reference to their EClass instance
    • Dynamic interface for manipulating EObjects
      • e.g. myEObject.eGet( “field1” )
    • Serialization to Binary or XML form
      • Abstracted such that other serializations possible
      • Replaces Intermediate Representation (IR) files seen in RBD today
    • Java Class generator for creating specific java classes for each EClass
      • High performance
      • Easier programming
    • Transformation framework
      • Initial java class implementations of each EClass generated using this framework
      • All EGL code generators based off same framework
  • The EDT Modeling Framework: org.eclipse.edt.mof
    • MOF (Meta Object Framework) Model
      • Meta model used to create other models
      • Used to create the EGL Model
    • EGL Model
      • Meta model used by compiler to create EGL elements
      • Program, Record, Expression, etc
    • EGL syntax can be used to define both MOF and EGL model elements
      • EGL Compiler can create instances of either model
      • EGL can therefore be used to define arbitrary models
    MOF Model EGL Model
  • Using EGL to define a Model
    • EGL Meta Model defined by EGL itself
    • Special Stereotype MofClass tells compiler to create EClass instances instead of ExternalType instances
    Compiler creates EClass instance because of MofClass Stereotype Compiler creates normal Externaltype instance
  • XML Serialization of EClass - StructPart This object is an instance of org.eclipse.edt.mof.EClass Instances of org.eclipse.edt.mof.egl.Field
  • XML Serialization of ExternalType - Customer This object is an instance of org.eclipse.edt.mof.egl.ExternalType Instances of org.eclipse.edt.mof.egl.Field
  • Agenda
    • Motivation for an Open EGL
    • Structure of EGL language
    • Extending the EGL language
      • Adding abstract concepts
      • Extending Code Generation
    • Demo
      • Extended Java code generation for native Android application
  • Module Structure of EDT: org.eclipse.edt org.eclipse.edt.ide org.eclipse.edt.core org.eclipse.edt.gen
  • Extensible Model Compilers: org.eclipse.edt.gen
    • Core Model Transformation framework
      • Model to Model, i.e. EDT MOF model to EMF model
      • Model to Text, i.e. EGL Model model to Java
    • All EDT code generation based upon this framework
    • Simple and lightweight and highly extensible
    • Extensibility comes from configurable ‘Templates’
      • A Template is simply a java Class
      • Each model element has a Template associated with it
      • Each Template implements methods that perform some transformation on its given model element
      • All template method invocation follows the inheritance hierarchy of the given model
        • If a given template method does not exist in the specific template of the model element method lookup will go up the super type chain
      • Extending an existing transformation is simply a matter of adding and replacing templates with new ones that:
        • Add new
        • Replace the original
        • Extend the original
  • Content of a Generator
    • The purpose of a ‘Generator’ is to transform instances of some model into either text or instances of some other model
    • A ‘Generator’ is composed of a set of ‘Templates’
      • Each Template is a simple Java class
      • Each model class has an associated Template
      • All transformations handled in the templates
        • Validation
        • Model to Model transformation (M2M)
        • Model to Text (M2T)
    • Extending a Generator means:
      • Adding new templates
      • Overriding existing templates
        • Complete override
        • Pre/post processing with invocation of super class methods
  • The EDT Code Generation Framework: org.eclipse.edt.mof.codegen.api
    • Framework composed of two basic classes
      • org.eclipse.edt.mof.codegen.api.Template
        • Transformation/validation implementation
        • Usually one Template class per Model class that needs transformation
      • org.eclipse.edt.mof.codegen.api.Context
        • Contains the global state of a transformation
        • Implements dynamic template method Invocation
    • Context implements dynamic invocation of methods on Templates
      • Object invoke (String methodName, Object object, Object…args)
      • Object invokeSuper (String methodName, Object object, Object…args)
    • Dynamic invocation means:
      • Look up the template associated with Class of the second parameter - Object object
      • Look up the method with the given method name methodName and signature based on the args Object…args
      • Invoke method on the template passing object and args
  • EGL Model to Template Associations
    • Each Model Class has associated Template
    • Each Template implements sets of methods for various purposes
      • Analysis, Validation, Code generation
      • Methods in each set implement a particular API clients invoke for particular situations
    • Templates themselves do NOT follow inheritance of the model
      • Dynamic template method invocation follows the inheritance chain of the model
      • Allows for easy overriding of Template classes
        • Replacing Template classes does not interfere with any Template hierarchy
    ProgramTemplate ClassTemplate StructTemplate ClassifierTemplate NamedElementTemplate ElementTemplate
  • Mapping File of EDT Core Java Generator EGL Model type signature=Template java class type signature
  • Dynamic Template Method Invocation Example: Java Generation of Program
    • Appropriate Template looked up based on Class of part argument
      • Program  ProgramTemplate
    • genPart() method lookup in ProgramTemplate
      • If not found go up the super type chain of Program and look for the genPart() method in the associated Template for that super type
        • EGLClass  ClassTemplate
    • If not found continue up the chain until found
    • Invoke genPart(part, context, out)
    This approach allows one to think about transformation implementation as if the methods were actually implemented in the model classes themselves
  • Dynamic Invocation Example: Field Template Lookup starts at Field but moves up to NamedElement
    • FieldTemplate
    • genDeclaration ()
    • MemberTemplate
    • genDeclaration ()
    • NamedElementTemplate
    • genName()
    ElementTemplate
  • EDT Core Generators
    • EDT will provide ‘core’ generators for Java and JavaScript
    • A ‘core’ generator is one that implements a transformation to a target runtime technology that adheres to the semantics of the ‘Core’ EGL Language
    • EGL Core will be the EGL specification containing:
      • Syntax and semantics for declaring EGL definitions
      • Execution semantics for statements and expressions
      • Semantic descriptions for extensible IO statements
        • GET, ADD, etc. with no description for specifics like SQL access
    • EGL Core will not specify any metadata specifications except for those necessary to define other metadata
      • Annotation and Stereotype are types themselves known to the compiler
    Core generators
  • EDT Extended Generators
    • An Extended Generator contains:
      • Specific set of metadata types, i.e. SQLRecord, TextProgram, etc
      • Extension to a core generator with new templates built for new set of metadata types
      • Runtime support libraries if necessary
    • EDT will also provide a set of extended generators to support common platforms
    • JEE Generator extends core Java generator
      • Support of Web Services, JPA, etc.
    • Core JavaScript Generator extended to handle current RUI programming model
    Extended generators
  • Android Generator: an example
  • UI Programming Model Example: Define Native Types
    • Abstract concepts derived from concepts common across UI frameworks
      • Window – deployable UI unit
        • Android – Activity
        • Web – HTML Page
      • View – Super type of all UI controls
        • Android – View
        • SWT – Widget
      • ViewGroup – contains View children
        • Android – ViewGroup
        • Dojo – Container
      • TableLayout – kind of ViewGroup for Tables
    Window View ViewGroup TableLayout 1 contentView * children
  • UI Programming Model Example: Define Native Types in EGL Abstract concepts defined using Externaltype with AbstractType stereotype Event handlers modeled as Delegates Inheritance modeled directly Externaltype declarations allow for full Class modeling
  • UI Programming Model Example: Define Concepts in EGL Core UI Concepts Stereotypes for implementation Concrete Widgets
  • UI Programming Model Example: Define Stereotypes for Implementation
    • Native Types by definition are abstract and have no specific EGL implementation
    • Stereotypes allow EGL implementation definitions to be part of an object model introduced with the native types.
    • defaultSuperType setting means that any handler stereotyped by WindowHandler will subclass the Window native type
    • Allows abstract API of Window to be accessed anywhere within a handler stereotyped by WindowHandler
    • Extended Generator will fold in appropriate implementation for the abstract API anywhere in the code it is accessed
  • Example Usage: Mortgage Calculator Event handler declaration Stereotype used to implement a Window Similar conceptually to RUIHandler Invocation of the Amortize Service Declaration of Widgets and properties
  • Mapping to Target Platform: Android and Dojo
    • Abstract concepts need concrete mapping to intended runtime platform
    • Native Android is a Java framework
      • Android generator would be an extension of the core EDT Java generator
    • Dojo is a JavaScript framework
      • Dojo generator would be an extension of the core EDT JavaScript generator
    • This example shows a simple mapping to Android platform
      • Use of widgets and layout
      • Calling a web service
  • Mapping File of EDT Core Java Generator EGL Model type signature=Template java class type signature
  • Map Android Model to Android Templates Mapping of model classes to their templates Overrides of EGL Core Java Templates
  • Create Necessary Templates Override existing method from Template from Base Java Generator Template method invocation
  • Android Mortgage Calculator Example
  • Android Mortgage Calculator Detail Native type abstract API access
  • Mapping Native Types to Runtime Types EGL native type type signature = Runtime java class type signature
  • Native Type Template Example: TextViewTemplate
    • All native type API access handled in the template associated with particular native type
    • Native type templates understand the mapping of the model to the runtime
      • Will use the runtime java class API
    • Delegation will occur for the following Expression types:
      • Assignment
      • Name, MemberAccess
      • FunctionInvocation
    aTextView.text = “123”; aTextView.setText(“123”); EGL Generated Java aStr = aTextView.text; aStr = aTextView.getText();
  • Create the AndroidGenerator Command Line Tool Android generator extends core Java generator Adds command line parameters as necessary Define where the configuration is for adding and overriding code generation templates Define where the configuration is for mapping native types to concrete classes in the runtime
  • Plugging Android Generator into the IDE
    • Implement a few simple classes in an IDE plug-in
      • GeneratorProvider
      • TabProvider
      • Extension of the command line generator to be invoked by EGL builder
    • Example Android IDE plug-in classes
      • acme.generator.android.ide.AndroidGeneratorProvider
      • acme.generator.android.ide.AndroidTabProvider
      • acme.generator.android.ide.EclipseAndroidGenerator
  • Workspace Preferences: EGL Compiler
    • Multiple EGL Compilers in the IDE
    • Each compiler can have multiple generators associated with it
    • Workspace preference defines default settings for EGL Compiler for a new EGL Project
    • Project specific settings can override these defaults for each EGL Project
  • For more information visit our project page
    • Project schedules
      • Including detailed 0.7.0 iteration/milestone plans
    • Downloadable builds and source
    • Committers and status
    • New and noteworthy
    • Documentation
    • Presentations
    • Access to bugs and requirements
    http://www.eclipse.org/edt/ EDT 0.7.0 M1 now available!
  • Thank You