Transcript The ladder to abstraction

The Ladder To Abstraction
Matthew Fowler
[email protected]
1
Agenda
• Introduction, Background
• Techniques
–
–
–
–
–
–
Pluggable Meta-models
Logical Modelling
Externalisation of Control
Model-to-model Transforms (Patterns)
Two-dimensional inheritance
Framework approach
• Conclusion
2
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
3
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
4
Background
1. Pluggable Meta-models
• Velocity as templating engine
• Required Java model objects as "the context"
Templates
Model
<entity
name="Customer">
Java
model objects
Velocity
Text
class Entity
field name="Customer"
• Classes for Java Objects = meta-model
• Problem: construction and maintenance
5
Pluggable Meta-models
Challenges
• 1. Maintenance
Size of meta-model (Java) code
Difficult to add new features
• 2. How to do .NET, new frameworks
– But re-use surrounding pieces
6
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)
7
Pluggable Meta-models
Example
<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>
8
Pluggable Meta-models
Solution 2. Pluggability
• Multiple meta-models per
build
– Current record 13 meta-models in a stack
• Late binding: configure
stack at generate-time
• Modular
• Abstract/Physical
separation
Company
Company
WebSphere
JSF
J2EE
Spring
Screen
Screen
Bizobject
Bizobject
Java
Java
9
Pluggable Meta-models
Class
Impl Class
J2EE Meta-model
Cross-MM Inheritance
Reference Type
Business Object
Java Meta-model
Entity
Entity
Business Object
Meta-model
EJB Entity
JDO Entity
10
Pluggable Meta-models
Benefits
• 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
11
2. Logical Modelling
Challenges
• 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
12
Background
Logical Modelling
• Additional models
Templates
Model
Additional
Model(s)
Java model
object tree
Artifacts
Added as second-level
object in tree
• Typically used as control information
• Additional models normally "Simple XML"
13
Solution
Logical Modelling
Screen
Screen
Business Object
Customised
Meta-model,
ready for
- modelling tool
- customer envt.
Business Object
Java
UML Tool
Specific
Profile
Java
Filter Spec
Aggregate
Filter
Convert
• Modular profile construction
• No limit on # meta-models/meta-classes
• Adaptation to UML tools and customer reqts.
14
Logical Modelling
Benefits
• 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
15
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
16
3. Externalisation of Control
Challenges
• 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
17
Externalisation of Control
Solution
• 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
18
Externalisation of Control
Benefits
• 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
19
4. Model-to-model Transforms
Challenges
• 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
20
Operation
Model-to-model Transforms
• Transforms in templates with well-known names
• Produce XML text as output
Velocity Scripts
Model to
Model
Model
objects
Model
Model to
Text
Artifacts
+
<xml ...>
• Embellishes, or creates new, model objects
• "Pattern" - practical application of design pattern
21
Model-to-model Transforms
Sample Pattern
• Entity: fix up for missing keys
#if( $keys.size() == 0 )
<this>
<attribute
name="oid"
autokey="true"
type="Integer"
/>
</this>
#end
• Various types of patterns:
– "Fixup" - fix myself or my peers, before validation
– Create other objects
22
Model-to-model Transforms
Details
• 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!
23
M2M Transforms
Cross-Tier/MM Patterns
DAO
DAO attribute
DAO reln
Pages
Search/Select/Edit
Buttons
CRUD
Entity
Attribute
Relation
Maintenance
Session
DAO
24
Model-to-model Transforms
Benefits
• 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
25
2D Inheritance
Background
• Many existing features for variation
– properties files for system init
– properties files per model object
– links to Java
• But for composability... we need more
26
5. 2D Inheritance
The Challenge
• 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)
27
Solution 1
2D Inheritance
• Generalise meta-model stack
– "Domain-specific generation plug-in"
per-level
config, naming
conventions
per-level
macros
Company
WebSphere
J2EE
Screen
Object Type
Ant build.xml
config, naming
conventions
Bizobject
transforms
Java
methods
28
2D Inheritance
Details
• 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
29
2D Inheritance
Per-object inheritance
• Second level of inheritance... groundwork:
Class
Bean
Reference Type
Impl Class
Java Meta-model
Bus. Object
Entity
Business Object
Meta-model
New
J2EE Meta-model
Entity
EJB Entity
JDO Entity
30
Bean model-to-model
2D Inheritance
<this
#foreach( $field in $fieldList )
#if( $field.readable )
<method
access="private">
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>
31
2D Inheritance
•
Solution 2
We need two dimensions of inheritance
1. Model object type (bean → class)
2. 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
32
2D Inheritance
Benefits
• 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"
33
6. Framework Approach
Challenge
• Encapsulating is hard
– Architecture, design patterns, best practice
– Sheer volume
• 1000's of meta-programs
34
Framework Approach
Solution
• 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)
35
Framework Approach
Benefits
• Less volume in the meta-programs
• Easier to
– Express best practice and architecture
– See the wood for the trees
– Change
36
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
37