"CompuwareCorporation Model Driven Architecture for J2EE Development Promise and Practice David Herst OptimalJ Product Consultant Compuware david herst compuware com CompuwareCorporation"
CompuwareCorporation Model-Driven Architecture for J2EE Development Promise and Practice David Herst OptimalJ Product Consultant, Compuware firstname.lastname@example.org CompuwareCorporation Model-Driven Architecture Introduction CompuwareCorporation Page 3 Assumptions We’re building complex, long-lived systems We care about “architecture” We accept basic best practices We want an agile methodology CompuwareCorporation Page 4 What is a Model? An abstraction of some part of our system – Helps us focus on essentials of a problem to better understand it – Helps us move toward an effective solution But models, traditionally, don’t generate the implementation CompuwareCorporation Page 5 What is Model-Driven Development? A paradigm where the blueprint builds the house MDD can automate many development artifacts – Database tier: SQL – Business tier: EJBs, DAOs, other persistence logic – Web tier: standard pages, Struts actions, etc – Testing scripts – Whatever has to be there every time CompuwareCorporation Page 6 What is Model-Driven Architecture? A standard for model-driven development From the Object Management Group (OMG) Built upon MOF MDA defines multiple levels of models… CompuwareCorporation Page 7 MDA Basics Platform-Independent Model (PIM) Automated Transformation Platform-Specific Model (PSM) Automated Transformation Code CompuwareCorporation Page 8 Why a PIM (Business Model)? Can’t build a business system if you don’t understand the business Need a way to talk to business analysts Some design choices transcend / permeate system architecture CompuwareCorporation Page 9 Why a PSM (Architectural Model)? Keep technical architecture separate from business model Many J2EE specifics can be modeled – Web pages, web flow – Interdependence of business logic components – Integration – Testing J2EE-specific metadata has advantages CompuwareCorporation Page 10 OptimalJ: Model Driven, Pattern Based Development Define and maintain business domain model – Platform Independent Model – Just enough modeling Built-in UML Modeling Domain Model Supports external Modeling tools (e.g. (PIM) Rational Rose) Automated transformations to application model(s) Application – Platform Specific Models Model (PSM) – J2EE Architecture Automated code generation – 100% Industry standard code Code – Robust, secure, scalable, maintainable Model – Working code (not stubs or skeletons) – Agile, Iterative Automated application packaging and deployment Web Server DBMS – Supports all standard deployment Application … environments Server – No lock-in CompuwareCorporation Page 11 MDA / OptimalJ Demonstration CompuwareCorporation Model-Driven Architecture Promise CompuwareCorporation Page 14 Promises of MDA Faster implementation Agile development Better quality code Greater reusability Easier maintenance Flexibility / extensibility CompuwareCorporation Page 15 Promise: Faster Implementation In any given application, Custom code (10%) how much code must be written manually? Semi-generic code What if developers focus (40%) exclusively on custom code? Greater productivity Generic plumbing code (50%) CompuwareCorporation Page 16 Promise: Better Quality Code More Reliable – Gen’d code requires less testing/debugging – Model can generate testing tools Cleaner, more consisent Higher Quality – Transformations can (should) embody design patterns – Gen’d code will be architecturally sound CompuwareCorporation Page 17 Promise: Easier Maintenance Maintenance constitutes a huge portion of TCO – App must respond to changes in business and technology How much work is required to… – …add attributes to a Customer class? – …refactor web tier when a use case changes? – …integrate external resources? – …plug in a different persistence technology? More model-driven code == less manual refactoring CompuwareCorporation Page 18 Agile Development Agile methodology calls for: – Frequent, tangible working software – Close communications btw business & IT participants – Flexible response to changes in requirements MDA supports this by letting you – build working, well architected software immediately and continuously – build iteratively – propagate changes quickly through code CompuwareCorporation Page 19 Promise: Greater Reusability Design patterns can evolve at model levels – How to structure domain classes – How to structure UI components for standard tasks Domain models can be stored in libraries – Reused in new applications Business and technical architectures are kept separate CompuwareCorporation Page 20 Promise: Flexibility / Extensibility MDA transformations aren’t black boxes – More like white boxes – They can be modified / extended for different results For example: – Use Webwork or Swing instead of Struts – Use Hibernate or JDO instead of EJB CompuwareCorporation Page 21 Bottom Line MDA holds promise of Better design Greater productivity Higher probability of success CompuwareCorporation Model-Driven Architecture Practice CompuwareCorporation Page 23 Issues: Keeping perspective New development paradigm – Model-centric development – Model-centric design – Trusting generated code CompuwareCorporation Page 24 Issue: Keeping Perspective Modeling doesn’t guarantee good apps – To model something, you must understand it – A bad model can still produce a bad app MDA isn’t suited for every type of app MDA doesn’t compensate for lack of – good people – a good process CompuwareCorporation Page 25 Issue: Changing Developers’ Paradigm Developers traditionally view development in code-centric terms: – Code production == progress – Code-centric design – “If I can’t see it, I don’t trust it” MDA requires a new paradigm CompuwareCorporation Page 26 New Paradigm: Model-Centric Development Old Paradigm New Paradigm Code == progress Models are focal point of solutions Models are a hindrance Code is a byproduct of development Solve design problems at highest possible level CompuwareCorporation Page 27 New Paradigm: Model-Centric Design Old Paradigm New Paradigm “The code is the model” “The model is the code” Design centers on code Design centers on model – J2EE patterns – PIM is critical – Refactoring Model is source code – Little sense of independent – Validated, debugged business model – Preserved Models are expendable – Temporary aids Changes are made at highest possible level – Not considered source CompuwareCorporation Page 28 New Paradigm: Trusting Generated Code Old Paradigm New Paradigm “If I can’t see it, I don’t Validate the code transformations trust it” Then trust them to write “If I didn’t write it, I reliable code for well don’t trust it” understood operations Modify them to address special needs CompuwareCorporation Page 29 Bottom Line MDA is not a magic bullet MDA must be factored into a development process MDA will have a learning curve MDA will produce its own set of best practices Thank you CompuwareCorporation Questions?