The ladder to abstraction l.jpg
This presentation is the property of its rightful owner.
Sponsored Links
1 / 37

The Ladder To Abstraction PowerPoint PPT Presentation


  • 468 Views
  • Updated On :
  • Presentation posted in: General

The Ladder To Abstraction. Matthew Fowler [email protected] Agenda. Introduction, Background Techniques Pluggable Meta-models Logical Modelling Externalisation of Control Model-to-model Transforms (Patterns) Two-dimensional inheritance Framework approach Conclusion.

Download Presentation

The Ladder To Abstraction

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


The ladder to abstraction l.jpg

The Ladder To Abstraction

Matthew Fowler

[email protected]


Agenda l.jpg

Agenda

  • Introduction, Background

  • Techniques

    • Pluggable Meta-models

    • Logical Modelling

    • Externalisation of Control

    • Model-to-model Transforms (Patterns)

    • Two-dimensional inheritance

    • Framework approach

  • Conclusion


The ladder of abstraction l.jpg

The Ladder Of Abstraction

  • Chunking up

    • Higher levels of abstraction

      • More power of thought and action

      • Modelling - the more abstract the better/faster

      • Removal of detail

      • Relativity: logical and physical

  • Chunking down: recreating the "lost" information

    • extract from super-classes

    • multiple outputs per concept


Jeewiz introduction l.jpg

JeeWiz Introduction

  • 2001: BEA:

    • "Stop customers messing up Architecture"

  • Pre "MDA"/"MDD"

  • Goal: Express & automate

    • the integration programmers do

    • best practice use of frameworks

  • Large-scale end-to-end system generation

    • UI generation a difficult challenge

    • Challenges => new concepts and techniques


Background l.jpg

Background

1. Pluggable Meta-models

  • Velocity as templating engine

  • Required Java model objects as "the context"

  • Classes for Java Objects = meta-model

  • Problem: construction and maintenance

Templates

Velocity

Model

Java

model objects

Text

class Entity

field name="Customer"

<entity

name="Customer">


Challenges l.jpg

Challenges

Pluggable Meta-models

  • 1. MaintenanceSize of meta-model (Java) codeDifficult to add new features

  • 2. How to do .NET, new frameworks

    • But re-use surrounding pieces


Solution 1 meta models l.jpg

Pluggable Meta-models

Solution 1. Meta-models

  • Define in "Simple XML"

  • Generate Java classes for model obects

    • 75% of meta-class code generated

  • Very simple constructs: (cf EMF)

    • <meta-model>, <meta-class>

    • <property>, <list>, <validator>

    • c-data: Java impl, expressions, descriptions

  • 320 meta-classes in all JeeWiz meta-models

  • (Sometimes we don't bother with MMs)


Example l.jpg

Example

Pluggable Meta-models

<meta-class name="entity"

extends="business-object"

description="..."

>

<property name="table-name" />

<property name="generate-table-schema"

type="boolean"

default="true"/>

<list name="query"

description="Select and finder methods."

>

<validator message="An entity must have at least one attribute"

expression="getAttributeList().size() > 0"

/>

// getKeys gets either the autoKey or the primary key attributes list

public List getKeys()

{

initLists();

return ( autoKeyAttributeList.size() > 0 )

? autoKeyAttributeList

: keyAttributeList;

}

</meta-class>


Solution 2 pluggability l.jpg

Pluggable Meta-models

Solution 2. Pluggability

Company

Company

  • Multiple meta-models per build

    • Current record -13 meta-models in a stack

  • Late binding: configure stack at generate-time

  • Modular

  • Abstract/Physical separation

WebSphere

JSF

J2EE

Spring

Screen

Screen

Bizobject

Bizobject

Java

Java


Cross mm inheritance l.jpg

Cross-MM Inheritance

Pluggable Meta-models

Class

Reference Type

Java Meta-model

Business Object Meta-model

Impl Class

Business Object

Entity

J2EE Meta-model

EJB Entity

Entity

JDO Entity


Benefits l.jpg

Benefits

Pluggable Meta-models

  • Concept inheritance

    • building up the ladder of abstraction

      • as far as you need to go

      • go beyond classes (e.g. page components)

    • inheritance through multiple meta-classes/models

  • Modularity and reusability

  • Pattern for addressing new technologies/processes


Challenges12 l.jpg

Challenges

2. Logical Modelling

  • Modellers & UML Tools

    • One set of concepts (stereotypes)

  • Need to remove concepts (e.g. 'physical' detail)

    • e.g. public/protected/private in Java

    • fixed for business objects and business methods

      • <business-method> => public access

  • Fixups for modelling tool deficiencies

    • e.g. constraints in RSA/RSM

  • Customer modelling requirements


Background13 l.jpg

Background

Logical Modelling

  • Additional models

  • Typically used as control information

  • Additional models normally "Simple XML"

Templates

Model

Java model

object tree

Artifacts

AdditionalModel(s)

Added as second-level

object in tree


Solution l.jpg

Solution

Logical Modelling

  • Modular profile construction

  • No limit on # meta-models/meta-classes

  • Adaptation to UML tools and customer reqts.

Screen

Business Object

Java

CustomisedMeta-model,

ready for

- modelling tool

- customer envt.

UML Tool

Specific

Profile

Screen

Business Object

Java

Filter Spec

Aggregate

Filter

Convert


Benefits15 l.jpg

Benefits

Logical Modelling

  • Separation of concerns

    • Aggregation

    • Filtering (& compensation for UML tool deficiencies)

  • Filter customisation by end user

  • Easy to produce a "logical profile"

    • Any level of abstraction

    • Reduction in number of concepts and detail

  • General - any combinations of meta-models

    • separate adaptation to modelling environment


Interlude l.jpg

Interlude

  • That was the easy bit - building the abstractions

  • Now for the interesting bit:

    • Bridging the semantic gap to operational systems

      • Expansion: adding in the 'physical'

      • Derivation: PIM1 → PIM2 concepts

    • Variation: adapting to customer requirements

    • User Interface generation

    • Incorporating "Best Practice"

      • Smart use of the technical platform


Challenges17 l.jpg

Challenges

3. Externalisation of Control

  • Component assembly from model objects

  • Build automation

    • Move the workflow into the engine

    • "Externalisation of control"

  • Number of configuration properties

  • (Let's face it) We don't like build/configuration in Ant


Solution18 l.jpg

Solution

Externalisation of Control

  • A feature-rich framework for MDD

  • External workflow

    • initialisation (overall and per model object)

    • model-to-model transforms and validation

    • " model-to-artifact" (i.e. create various artifacts using Ant, deploy etc.)

  • Pull in features by well-known names, e.g.

    • "component.properties" sets model object props

    • "build.xml" builds a model object using Ant

    • "uptodate.xml" and avoiding rewriting


Benefits19 l.jpg

Benefits

Externalisation of Control

  • Model-to-model transforms

    • Created model objects produce output

      • No additional config / selection required

    • Automatic expansion of model object tree (x 30)

      • Revisit later

  • Complete generation systems as components

    • use automatically in a larger build

      • e.g. Java Jar build within overall application build

    • e.g. model-driven deployment solution


Challenges20 l.jpg

Challenges

4. Model-to-model Transforms

  • Building DotNet and J2EE

    • Too many similar M2Text transforms

      • One for .NET, another for J2EE

    • Only M2Text available, mixed together

      • intention (give me some data behind a page)

      • implementation (here's a class generation)

    • Aspects difficult to do

      • e.g. change class tracing at one point

  • Jan 03


Operation l.jpg

Operation

Model-to-model Transforms

  • Transforms in templates with well-known names

  • Produce XML text as output

  • Embellishes, or creates new, model objects

  • "Pattern" - practical application of design pattern

Velocity Scripts

Model toModel

Model to

Text

Model

Modelobjects

Artifacts

+

<xml ...>


Sample pattern l.jpg

Sample Pattern

Model-to-model Transforms

  • Entity: fix up for missing keys

  • Various types of patterns:

    • "Fixup" - fix myself or my peers, before validation

    • Create other objects

#if( $keys.size() == 0 )

<this>

<attribute name="oid"

autokey="true"

type="Integer"

/>

</this>

#end


Details l.jpg

Details

Model-to-model Transforms

  • Separation of concerns

    • intention = original model objects

    • elaboration = generated model objects

    • implementation - downstream artifacts produced

      • "<page>" different on Struts/JSP/Spring MVC

  • Do it in place - enhance the input model

  • Completely automatic; regen every run

    • No update by developers

      • This is where architecture is generated

      • Tinkering by developers is a bad idea!


Cross tier mm patterns l.jpg

Cross-Tier/MM Patterns

M2M Transforms

Entity

DAO

Attribute

DAO attribute

Relation

DAO reln

Pages

Search/Select/Edit

MaintenanceSession

DAO

ButtonsCRUD


Benefits25 l.jpg

Benefits

Model-to-model Transforms

  • Implement higher concepts via lower ones?

  • Expansion

    • half of the "fill in the physical part" solution

  • Key to "brains in a box"

    • executable design patterns

    • create architecture, e.g. derived tiers, logically

  • Understandable by developers

    • no new languages to learn; easy to change

  • Intermixing of logic and output architecture


Background26 l.jpg

Background

2D Inheritance

  • Many existing features for variation

    • properties files for system init

    • properties files per model object

    • links to Java

  • But for composability... we need more


The challenge l.jpg

The Challenge

5. 2D Inheritance

  • Reuse of "Renderings"

    • Higher-level concepts build on lower-level impl

    • Customer does too - naming, logging, security, L&F

  • Variant Injection - easy insertion into lower layers

  • Java Inheritance is not enough

  • Variant generation at similar logic levels

    • C#, Java

    • .NET, J2EE (some similarities)

    • Struts/JSF (different)


Solution 1 l.jpg

2D Inheritance

Solution 1

  • Generalise meta-model stack

    • "Domain-specific generation plug-in"

per-level config, namingconventions

Company

per-level macros

WebSphere

J2EE

Screen

Object Type

Bizobject

Ant build.xml

config, namingconventions

transforms

Java

methods


Details29 l.jpg

Details

2D Inheritance

  • Operation

    • Search top-down

    • Merge - add new names (inheritance)

    • Override - existing names

  • Externalisation of control 

    • create well-known name-files at any level

    • only linkage is configuration of stack at build time


Per object inheritance l.jpg

Per-object inheritance

2D Inheritance

  • Second level of inheritance... groundwork:

Class

Reference Type

Java Meta-model

Business Object Meta-model

Bean

Impl Class

Bus. Object

Entity

New

EJB Entity

Entity

J2EE Meta-model

JDO Entity


Bean model to model l.jpg

Bean model-to-model

2D Inheritance

<this access="private">

#foreach( $field in $fieldList )

#if( $field.readable )

<method name="get${field.nameCapitalised}"

return-type="${field.type}"

access="public"

>

return ${field.name};

</method>

#end

#if( $field.writeable )

<method name="set${field.nameCapitalised}"

return-type="void"

access="public"

>

<parameter name="${field.name}"

type="${field.type}"

/>

this.${field.name} = ${field.name};

</method>

#end

#end

</this>


Solution 2 l.jpg

Solution 2

2D Inheritance

  • We need two dimensions of inheritance

    • Model object type (bean → class)

    • Generation plug-in (BOM → Java MM)

  • Details

    • Separate from meta-class (Java) inheritance

    • Under control of meta-programmer

      • 'BOM:bean' says: "now try 'class'" object type

      • Redirections search the whole stack of plug-ins

        • Override at multiple layers/concepts


Benefits33 l.jpg

Benefits

2D Inheritance

  • Incremental creation of generation plug-ins

  • Use of "inherited" plug-ins

    • Above M2M example works for Java or C#

  • Plug-in replacements - Struts/JSF/SpringMVC

  • Variant injection

    • Change small details in a lower-level plug-in

      • e.g. "is()" for beans

  • Flexible approach to climbing down "the ladder"


Challenge l.jpg

Challenge

6. Framework Approach

  • Encapsulating is hard

    • Architecture, design patterns, best practice

    • Sheer volume

  • 1000's of meta-programs


Solution35 l.jpg

Solution

Framework Approach

  • Many other features/refinements

    • Non-model "controls" for generating variant text

      • In Java, Velocity or both

    • OO in Velocity - methods, inheritance, overriding

    • 180 methods

  • Framework (externalisation of control)


Benefits36 l.jpg

Benefits

Framework Approach

  • Less volume in the meta-programs

  • Easier to

    • Express best practice and architecture

    • See the wood for the trees

    • Change


Conclusion l.jpg

Conclusion

  • Feature Checklist

    • Pluggable Meta-models, Logical Modelling

    • Externalisation of Control

    • Model-to-model Transforms (Patterns)

    • Two-dimensional inheritance

    • Framework approach

  • Relevance

    • More powerful frameworks

      • less need for simple codegen

      • more need for

        • integration / best practice / architectural generation


  • Login