MDD: Models, frameworks, & code generation

3,708 views

Published on

MDD: Models, frameworks, & code generation.
Some experiences with business software

Presented at the Code Generation 2008 conference

Published in: Technology

MDD: Models, frameworks, & code generation

  1. 1. MDD: Models, frameworks, & code generation Some experiences with business software Session for Code Generation 2008 Cambridge, UK, 26th June Pedro J. Molina, PhD Capgemini Spain
  2. 2. Goal • Share & discuss actual experiences about – Business Modelling – Code Generation – Frameworks adoption – Software Development productivity © Pedro J. Molina 2008. All right reserved. 2
  3. 3. Agenda • Background • Principles • Modelling: UI / Business Logic / Services • Frameworks • Code Generation • Samples • Lessons learned • Opportunities & Future Trends © Pedro J. Molina 2008. All right reserved. 3
  4. 4. Timing • Brief introduction • Content • Question & Answers 10:45 H Presentation Demo 85 min. 12:05 H 12:15 H Q&A 10 min. © Pedro J. Molina 2008. All right reserved. 4
  5. 5. Background • Code generation R&D – OO-Method project (Tech. University of Valencia) (1998-2003) – CARE Technologies / Olivanova Transf. Engines (1999-2004) – Every day code generation practitioner • Code generation in use – PISA project: Capgemini in collaboration with Bancaja (Spanish Bank) – Hermes: code generation for a proprietary framework (Utilities company) – Pársec Project / Capgemini • Model Driven Development effort to increase quality & productivity © Pedro J. Molina 2008. All right reserved. 5
  6. 6. Business & IT • Enterprise Architecture Business Information Systems Definition: Technology Infrastructure EA is the disciple dedicated to align Information Systems & Technology Infrastructure with the Business Strategy to satisfy Business Goals. • Business Processes are supported by IS & TI. • Changes happens in both sides although at different speed rate. © Pedro J. Molina 2008. All right reserved. 6
  7. 7. Business & IT: speeds of change Business Business Information Systems Information Systems Technology Infrastructure Technology Infrastructure Business rules changes Technology changes Driven by: Driven by: • Business evolution • Disruptive technology • Competence • Obsolescence • Market • Lack of support • Economic context • Lack of experienced people • Law / Regulations • High maintenance/TCO • Product release cycles Frequency of change: Frequency of change: • Depends on the domain • Frequent & cyclical waves Changes in both words occur at different speed rates and produce friction. © Pedro J. Molina 2008. All right reserved. 7
  8. 8. How to be ready for changes? • Split Business Know-How from Technological Know- How as much as possible (SoC) • Be ready to throw away, or adapt, or change your SW/HW in any moment for any cause • SW/HW should be flexible enough to follow the business as fast as possible (Time to Market) • Yes but, how to do it? © Pedro J. Molina 2008. All right reserved. 8
  9. 9. Definitions • MDD – Model – Meta-model – Framework – Code generation © Pedro J. Molina 2008. All right reserved. 9
  10. 10. Definitions • MDD: Model Driven Development Definition: The usage of Models as the main artefacts to Drive (or to lead) the software Development. © Pedro J. Molina 2008. All right reserved. 10
  11. 11. Definitions • Model Model Definition: An idealized representation of a subset of the reality discarding non relevant details accordingly to a given level of abstraction and concern. © Pedro J. Molina 2008. All right reserved. 11
  12. 12. Definitions Meta • Meta-model Instance of model Model Definition: A model describing the rules of the game of a family (a kind) of models. A meta-model describes what can be said and fixes the form and semantics of all valid constructions. © Pedro J. Molina 2008. All right reserved. 12
  13. 13. Definitions • Framework Framework Definition: A collection of reusable code (often in form of libraries) intended to facilitate software development – According to [Pree] a software framework consist of: • Frozen spots / constant aspects • Hot spots / variable aspects – An OO framework is used to create a concrete application by applying composition, instantiation, and subclassing of the framework classes. – Usage of the Hollywood Principle: “Don’t call us. We’ll call you.” – Often implemented using the Inversion of Control Pattern (IoC) © Pedro J. Molina 2008. All right reserved. 13
  14. 14. Definitions • Code generation Code Model Assets Generator Definition: The automated synthesis of SW assets like source code, documentation or models using models as input. © Pedro J. Molina 2008. All right reserved. 14
  15. 15. Demo Short Demo • Domain Modelling • Platform independence • Pluggable code generators • Generates – Persistence layer (MS SQL Server) – Logic layer – NHibernate Framework based – Exposed as Web Services © Pedro J. Molina 2008. All right reserved. 15
  16. 16. Axioms • The value is in the Model • Code should be discardable (in any moment) • Forward Engineering – No reverse engineering – With a few exceptions: DB, WS, well defined legacy Interfaces • Modelling focused on Conceptual Modelling – Capturing PIMs (technology agnostic) © Pedro J. Molina 2008. All right reserved. 16
  17. 17. Separation of Concerns (SoC) Know-How captured in two separated buckets: What? – Business Know-How: captured & encapsulated in form of models (specifications): isolated from technological issues How? – Technological Know-How: captured & encapsulated in form of best practices, frameworks, templates & code patterns in code generators & interpreters. © Pedro J. Molina 2008. All right reserved. 17
  18. 18. Principles • Modelling – Simple as possible, but expressiveness (KISS) – Semantically well defined – Canonical (only one way to express the same thing) (DRY) – Separation of Concerns (SoC) – Keep models organized & manageable – Right level of abstraction – Technological agnostic – Practical point of view (If you are not going to use it, don’t model it) © Pedro J. Molina 2008. All right reserved. 18
  19. 19. Principles • Code generation – Forward engineering – The value in in the model the code is discardable (re- factorable whenever its needed) – Technology changes faster than models, especially faster than meta-models (business know-how tends to be more stable than technology) © Pedro J. Molina 2008. All right reserved. 19
  20. 20. Modelling the User Interface • Abstract UI Model • CUIP • Multichannel interfaces • Device constrains © Pedro J. Molina 2008. All right reserved. 20
  21. 21. Abstract UI Model • An abstract UI Models allows – Make the design device independent – Adaptable to future devices – Reusable • Just-UI is an abstract UI model based on CUIPs (Conceptual User Interface Patterns) for modelling Business User Interfaces © Pedro J. Molina 2008. All right reserved. 21
  22. 22. CUIP • Conceptual User Interface Patterns – A collection of conceptual recurrent patterns in business applications in the domain of user interfaces – Increases a lot the level of abstraction (conceptual level) © Pedro J. Molina 2008. All right reserved. 22
  23. 23. CUIP More info about CUIP at http://pjmolina.com/cuip © Pedro J. Molina 2008. All right reserved. 23
  24. 24. Multi-channel user interfaces • The ability to produce UIs for different devices from an unique source (model) • Based on Conceptual User Interface Patterns, the problem of mapping is simplified to: – Map each pattern with a design solution in the specific device © Pedro J. Molina 2008. All right reserved. 24
  25. 25. Device constrains • UIs in different flavours: – Desktop, web, mobile, PDA, aural, 3D, ubiquitous • Each device has its own constrains: – Screen space, colour depth, idioms, language, standards & look & feel to be taken in account – It is 80% safe to select a default mapping for each CUIP in a selected device. – Some times, fine tuning will be needed (20%) (e.g. selecting a secondary pattern implementation) © Pedro J. Molina 2008. All right reserved. 25
  26. 26. Modelling Business Logic • Class Models – Attributes – Relationships • Inheritance, association, aggregation – Constraints (a la OCL) • Preconditions, Postconditions, Class Invariants – Operations • Parameters • Structured language to describe behavioural aspects of the operations © Pedro J. Molina 2008. All right reserved. 26
  27. 27. Architecture • Architecture deals with: – How to organize SW & HW to maximize some goals called principles such us: • Performance • Separation of Concerns • Security • Scalability • Maintainability • Easy deployment • Usability, etc. © Pedro J. Molina 2008. All right reserved. 27
  28. 28. N-layered Architectures • Pros – Scalable PDA Desktop GUI Web UI 3rd apps – Multi-channel – Interoperable • Connection of heterogeneous systems Web Server Exposed • Cons Web Services – Performance penalty Business Logic due to layer overhead Consumed Web Services DB 3rd Web Services © Pedro J. Molina 2008. All right reserved. 28
  29. 29. Frameworks everywhere • Language specific frameworks – Java: J2EE, Apache Struts – C#: WF, WPF, WCF • Inversion of Control – Spring, Castle • Data Access / ORMs – Hibernate, iBatis, Entity Spaces, DataSets • Layered Application development – J2EE, CLSA.NET, MS Application Library • Web development – Struts, Ruby on Rails, Monorails, Symphony • Custom proprietary frameworks – Customers often create its own framework and procedures as a way of standardization. © Pedro J. Molina 2008. All right reserved. 29
  30. 30. Framework selection • Choice already taken vs Architect choice • Selection criteria – Scalability, Performance, Throughput, Maintenance, etc. © Pedro J. Molina 2008. All right reserved. 30
  31. 31. Framework selection • How to make the selection? – Practical experience with frameworks is needed to know their particular pros & cons – Ideally a prototype should be made using the candidate frameworks – After that, the output can be compared in terms of: • Performance & throughput: a loading test can be used to measure them • Maintainability: a code audit can be conducted – However building N prototypes takes too much time unless… © Pedro J. Molina 2008. All right reserved. 31
  32. 32. Unless… • You can use MDD & Code Generation to make this ideal process a reality. – Use abstract models (not influenced by technology or framework aspects in any way) – Define your architectures & supporting frameworks – Create/use a pluggable-code generator framework – Create/use specific code-generators targeting specific frameworks using as input this aseptic input models © Pedro J. Molina 2008. All right reserved. 32
  33. 33. Opportunities to • Keep your models – Fully technology neutral • Benchmarking – It is possible to measure real gains of a new framework/language compared to a previous one – Framework selection can then be done with numbers in your hand • Rapid adaptation to FW or technology change – Reuse all your modelling infrastructure – Create a new code generator for the new output © Pedro J. Molina 2008. All right reserved. 33
  34. 34. Samples 1. UI code generation for multiple devices 2. Financial Terminal for a bank 3. Generating code into pre-existing customers frameworks 4. Hiding complexity in frameworks through modelling 5. Compounds verification in Chemical Plants © Pedro J. Molina 2008. All right reserved. 34
  35. 35. 1. UI Gen for multiple devices • Just-UI is – A model for User Interface Specification – Oriented to Business Applications – Technology independent – Based in Conceptual User Interface Patterns • http://pjmolina.com/cuip © Pedro J. Molina 2008. All right reserved. 35
  36. 36. 1. UI Gen for multiple devices © Pedro J. Molina 2008. All right reserved. 36
  37. 37. 1. UI Gen for multiple devices © Pedro J. Molina 2008. All right reserved. 37
  38. 38. 1. UI Gen for multiple devices © Pedro J. Molina 2008. All right reserved. 38
  39. 39. 2. Financial Terminal for a Bank – A full modelling workbench was developed for Bancaja on the top of Visual Studio. • DSL Tools, Schema, grammars, compilers, code generator to C# – The workbench allows the modelling and development of business functions for a Financial Terminal – The code generated reaches the 100% in this “closed environment” – Technology agnostic: Easily to retarget, just change the code generator © Pedro J. Molina 2008. All right reserved. 39
  40. 40. 2. Financial Terminal for a Bank © Pedro J. Molina 2008. All right reserved. 40
  41. 41. 2. Financial Terminal for a Bank • Workbench integrated in Visual Studio © Pedro J. Molina 2008. All right reserved. 41
  42. 42. 2. Financial Terminal for a Bank • Custom action language • Coloured syntax • Intellisense support © Pedro J. Molina 2008. All right reserved. 42
  43. 43. 2. Financial Terminal for a Bank • Error handling integrated in Visual Studio © Pedro J. Molina 2008. All right reserved. 43
  44. 44. 2. Financial Terminal for a Bank • DSL example • Navigational diagram © Pedro J. Molina 2008. All right reserved. 44
  45. 45. 3. Code gen. for existing Fwks • Corporate customer usually adopt well defined standards & custom or tailored frameworks • When developing a new solution for them, the standards must be fulfilled • Samples: – Layer disposition: 3, 4, 5 layers – Code Frameworks: Spring, Structs, Audit Trail, etc. – Law regulation compliance: SOX, Audit Trail, LOPD – Usability & accessibility compliance: Section 508, W3C- WACG, guide style compliance – Technology addressed: C#/Java, WinForms/WPF © Pedro J. Molina 2008. All right reserved. 45
  46. 46. 4. Hiding complexity with modelling • Context: – Complex application deployment – Based in a Java custom framework & Spring – Based on a myriad of XML Spring configuration files • Solution – Create a DSL (using GMF over Eclipse) to increase the level of abstraction and to provide SoC – Model the application logic, navigation, & data access with the DSL – Generate code and XML config files © Pedro J. Molina 2008. All right reserved. 46
  47. 47. 4. Hiding complexity with modelling © Pedro J. Molina 2008. All right reserved. 47
  48. 48. 4. Hiding complexity with modelling © Pedro J. Molina 2008. All right reserved. 48
  49. 49. 4. Hiding complexity with modelling © Pedro J. Molina 2008. All right reserved. 49
  50. 50. 5. QA in Chemical Plants • Context: – Chemical plant producing a high variety of compounds – Each compound has an specific recipe – Each recipe has different checkpoints for assuring its quality – QA process can be defined in terms of a workflow © Pedro J. Molina 2008. All right reserved. 50
  51. 51. 5. QA in Chemical Plants Advantages: Graphically described Stored in XML Interpreted in runtime Easy & fast to change and adapt without recompilation or redeploy Easy to understand and validate by functional owners Model = 1st documentation © Pedro J. Molina 2008. All right reserved. 51
  52. 52. 5. QA in Chemical Plants Running UI UI Model (interpreted) (stored in the server) View AddRmc label “Premix Generation” show premix show lot show pallet show qty label “AddRMC to Premix:” input inputQty input palletBin label “Input qty, scan Barcode” command End command Form command List © Pedro J. Molina 2008. All right reserved. 52
  53. 53. 5. QA in Chemical Plants WS Adapters Legacy Systems PDA Terminals QA Server WS Inventory Inventory WS Production ProdSystem WS Printing Printing Service WS Log Log Webservices adapters to Legacy Services Windows CE 5.0 Mobile .NET 3.0 C# (to be tunned per deployed plant) NET Compact Framework SOA oriented Repository of Declarative Models © Pedro J. Molina 2008. All right reserved. 53
  54. 54. Meta-modelling Meta-model Model (instance) Association Class Attribute Operation Parameter © Pedro J. Molina 2008. All right reserved. 54
  55. 55. Meta-modelling Meta-model Model (instance) View Navigation Control Property EventHandler © Pedro J. Molina 2008. All right reserved. 55
  56. 56. Meta-modelling Meta-model Model (instance) Table FK Column PK StoredProc Param © Pedro J. Molina 2008. All right reserved. 56
  57. 57. Meta-modelling Meta-model Model (instance) Class Member Property Method Parameter © Pedro J. Molina 2008. All right reserved. 57
  58. 58. Meta-modelling Meta-model Model (instance) ClassMap PKMap PropertyMap FKMaps Strategy © Pedro J. Molina 2008. All right reserved. 58
  59. 59. Meta-modelling Meta-model Model (instance) Solution Project CodeFile ImportedNamespace Type Method ResourceFile Parameter DocFile Code © Pedro J. Molina 2008. All right reserved. 59
  60. 60. Model Transformations – Jump from models to source code can be tricky – Specially if the model does not resembles the form of the code (due to abstraction, etc.) – Code generation can then be scheduled by phases – Refining the abstract model to a design model – Then refine it again till having a model close to the code – This strategy helps the debugging of the code generator & introduce opportunities to change strategies in the code generation (design choices) – Application Code Generation can be seen in this context as applying a Code Generation Chain © Pedro J. Molina 2008. All right reserved. 60
  61. 61. Code Generation • Architecture • Tools: DSL, Parsers, XML, template engines © Pedro J. Molina 2008. All right reserved. 61
  62. 62. Code Generation. Architecture Translator Specification 1. Load Explicit Specification Memory Structures 2. Inference Templates 3. Generation Algorithms sis he Transformations nt Sy Source Code © Pedro J. Molina 2008. All right reserved. 62
  63. 63. Code Generation. Tools • DSL – MS DSL Tools – GMF / EMF • XML & Schema • Parsers – Antlr, Lex & Yacc • Template engines – StringTemplate, Velocity © Pedro J. Molina 2008. All right reserved. 63
  64. 64. Code Generation Chain Persistence DB Specific DB DB Generator Model Generator Scripts Abstract ORM ORM Specific ORM ORM Model Generator Model Generator Mappings Bz Logic Logic Design Specific Bz Layer Generator Model Generator Code UI Specific UI UI UI Model Generator Code Generator © Pedro J. Molina 2008. All right reserved. 64
  65. 65. Code Generation Space Programs Models Template Meta-model Mappings Abstraction Classes / Transformation Abstraction Types Algorithms Instances Instanciation is h es nt Sy Source Specification Reverse Code Engineering © Pedro J. Molina 2008. All right reserved. 65
  66. 66. Defect Cost & Distribution Traditional life cycle MDD life cycle Defect cost Defects exponential % Analysis Design Build Maintenance Snow ball effect © Pedro J. Molina 2008. All right reserved. 66
  67. 67. Lessons learned – Forward engineering • Reverse engineering sceptical • If the abstraction delta is high true reverse engineering could be impossible • In general, current tools are not enough with some exceptions, e.g. structure gathering: – data model from DB – (Legacy) APIs (e.g. Web Services) © Pedro J. Molina 2008. All right reserved. 67
  68. 68. Lessons learned The value is in the model © Pedro J. Molina 2008. All right reserved. 68
  69. 69. Lessons learned – Separation of Know-how: Business KH vs Technological KH – Models more perdurable than code generators pluggable code gen. architecture © Pedro J. Molina 2008. All right reserved. 69
  70. 70. Models survives code generators – Business Know-How could change frequently – Meta-models change little – But this KH is alive and survives • A technology wave adoption • A change in the code generator Technology A Technology B Code Generator Targeting A Code Generator Targeting B © Pedro J. Molina 2008. All right reserved. 70
  71. 71. Opportunities & Future Trends – Multi-channel user interfaces, ubiquitous computing – Benchmarking and selection of frameworks • Same prototype model generated using different generators • Common Unit, Performance & Load tests – SOA & Enterprise Integration • Orchestration of business logic (BPL) • Service consumption & aggregation © Pedro J. Molina 2008. All right reserved. 71
  72. 72. Questions? Answers!? © Pedro J. Molina 2008. All right reserved. 72
  73. 73. Thank you! www.capgemini.com © Pedro J. Molina 2008. All right reserved. 73

×