The Ladder To Abstraction Matthew Fowler matthew fowlernte

The Ladder To Abstraction Matthew Fowler matthew. fowler@nte. co. uk 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

Jee. Wiz 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 Jee. Wiz 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="get. Attribute. List(). size() > 0" /> // get. Keys gets either the auto. Key or the primary key attributes list public List get. Keys() { init. Lists(); return ( auto. Key. Attribute. List. size() > 0 ) ? auto. Key. Attribute. List : key. Attribute. List; } </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 Web. Sphere JSF J 2 EE Spring Screen Bizobject Java 9

Pluggable Meta-models Class Impl Class J 2 EE Meta-model Cross-MM Inheritance Reference Type Business Object Java Meta-model 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 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: PIM 1 → PIM 2 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 Dot. Net and J 2 EE – Too many similar M 2 Text transforms • One for. NET, another for J 2 EE – Only M 2 Text 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 objects 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

M 2 M Transforms Cross-Tier/MM Patterns 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

2 D 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. 2 D 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, J 2 EE (some similarities) – Struts/JSF (different) 27

Solution 1 2 D Inheritance • Generalise meta-model stack – "Domain-specific generation plug-in" per-level config, naming conventions per-level macros Company Web. Sphere J 2 EE Screen Object Type Ant build. xml config, naming conventions Bizobject transforms Java methods 28

2 D 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

2 D 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 J 2 EE Meta-model Entity EJB Entity JDO Entity 30

Bean model-to-model 2 D Inheritance <this #foreach( $field in $field. List ) #if( $field. readable ) <method access="private"> name="get${field. name. Capitalised}" return-type="${field. type}" access="public" > return ${field. name}; </method> #end #if( $field. writeable ) <method name="set${field. name. Capitalised}" return-type="void" access="public" > <parameter name="${field. name}" type="${field. type}" /> this. ${field. name} = ${field. name}; </method> #end </this> 31

2 D 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

2 D Inheritance Benefits • Incremental creation of generation plug-ins • Use of "inherited" plug-ins – Above M 2 M example works for Java or C# • Plug-in replacements - Struts/JSF/Spring. MVC • 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