300 likes | 481 Vues
Pragmatic Model Driven Development (MDD) using openArchitectureWare. Michael Vorburger & Laurent Medioni Odyssey Financial Technologies 1640. AGENDA. Goal of Pragmatic MDD using openArchitectureWare at Odyssey Positioning of approach within the larger MDD / MDA picture
E N D
Pragmatic Model Driven Development (MDD) using openArchitectureWare • Michael Vorburger & Laurent Medioni • Odyssey Financial Technologies • 1640
AGENDA • Goal of Pragmatic MDD using openArchitectureWare at Odyssey • Positioning of approach within the larger MDD / MDA picture • openArchitectureWare, briefly: What? How? • Our Eclipse-based Designers • Software Demo • Q & A
AGENDA • Goal of Pragmatic MDD using openArchitectureWare at Odyssey • Positioning of approach within the larger MDD / MDA picture • openArchitectureWare, briefly: What? How? • Our Eclipse-based Designers • Software Demo • Q & A
Today Complexity of functional developments and inconsistencies due to complex and heterogeneous technical frameworks (due to historical reasons, acquisitions, etc.) Customization not always addressed in architecture, requiring strong technical skills Difficulty to tackle technological swaps (no big bang upgrades) because functional feature code is highly dependant on technical plumbing Tomorrow Reduced cost of new in-house functional developments, with higher quality Reduced implementation time for customizations, requiring less technical skills Suitable level of abstraction, enabling “behind the scene” changes of technical layers How? Consistent approach to frame all development work (frame-work), internal and for customizations, using code generation tools and high-level visual designers based on comprehensive application models Goal of Pragmatic MDD using openArchitectureWare at Odyssey
AGENDA • Goal of Pragmatic MDD using openArchitectureWare at Odyssey • Positioning of approach within the larger MDD / MDA picture • openArchitectureWare, briefly: What? How? • Our Eclipse-based Designers • Software Demo • Q & A
Model Driven Architecture ™ http://en.wikipedia.org/wiki/Model-driven_architecture … not entering any philosophical polemic… Standards, standards ? (well, XMI, ok…) Ready ? A few promising implementations… Analysis result: Not suitable for a solution provider context High customizability (platform-wide but also surgical customization) Migration of legacy artifacts (future “Architecture Driven Modernization” kind but… now !) Cohabitation between newly generated and legacy artifacts in the same containers. “Big Bang” not possible, neither internally, nor for customer sites. Positioning - MDA
MD Development (or MD Engineering, not OMG™) No functional Use Cases (and stratospheric PIM…) design attempt Practical models for technical artifacts (P[I/S]M) No overweight models overloaded with meta-data Local and tactical models, each one customizable through dedicated tools Always use generated code from models when a model exists Models express 100% of what should be manually coded (“framed” use of the frameworks) No manual “custom sections” in generated code, already enough merging issues on models… But also recognize that not everything can be modeled Only most highly customized artifact types MDA, the Eclipse way… Positioning - MDD
A Domain Specific Language for each artifact type A model for the abstract representation (ecore) A storage mechanism to persist the abstract representation (EMF does it!) A designer for editing the abstract representation using a graphical projection (helped by GMF) A generator for translating the abstract representation into an executable representation (oAW) Projection (GMF) Editable representation (GMF editor) Positioning - DSL Store (EMF) Executable representation (java, xml, …) Storage representation (XMI) Abstract representation (ecore) Generate (oAW) Import (oAW) http://martinfowler.com/articles/languageWorkbench.html
The Business Object Model contains declaration of: Classes and their attributes Associations Enums, translations, … The BOM is used for generating default models (CRUD basic pageflows and pages, validation rules, …) and technical artifacts (persistence, …) to propose a default skeleton to the applications (CRUD basic administration) to provide reusable bricks for more complex usage Nearly all DSLs need to be aware of the BOM BO are in and out parameters of services, rules, … BO are stored in the various contexts of session scope, pageflows, processes, … BOM centric
Positioning - Target Technical target Model to model transf. Eclipse designers Import existing artefact Generate artefact oAW Constraint checking
AGENDA • Goal of Pragmatic MDD using openArchitectureWare at Odyssey • Positioning of approach within the larger MDD / MDA picture • openArchitectureWare, briefly: What? How? • Our Eclipse-based Designers • Software Demo • Q & A
openArchitectureWare • oAW is a Framework & Tools to: • Work with different meta meta models (Ecore, XML, JavaBeans) • Read models (parsing EMF XMI, UML2, UML tools, other XML, …) • Check models for well defined integrity constraint violations, during editing • Transform models into other models via a functional language • Generate textual “code” (Java, XML, ...) from models via templates • Build editors for models: Textual & Graphical (DSLs) • Specific actual cartridges are not in the core of oAW • Fully open-source (Eclipse Public License v1.0, EPL), strong community • v4 is part of Eclipse.org’s Generative Modeling Technologies (GMT) project • Formerly on openarchitectureware.org & SourceForge • Packaged & delivered as flexible & modular Eclipse feature
openArchitectureWare Acronymland • Workflow Engine: Tying it all together ... run from Eclipse, ant, etc. • Xpand: Template language & engine, model to text (M2T) transformations(Velocity / FreeMarker / EMF JET –ish, but with an oAW-aware Eclipse editor etc.) • Xtend: Functional model to model (M2M) transformation language, also used to 'extend' meta types with additional behaviour in a non-invasive manner. (Alt: ATL) • Check: Model validation with OCL-like declaratively defined constraints (or use Java API for semi-declarative constraint checking, or real OCL with 3rd-party lib) • Recipe: Checks and generate hints on manually to-be implemented code • xText: Cartridge which from a DSL defined in EBNF generates Ecore meta model, parser, and Eclipse editor with syntax highlighting, completion & outline. • GMF: Eclipse‘s EMF + GEF (Graphical Editing Framework), with oAW checks • EMF: Eclipse‘s meta model (Ecore) / beans / editors / XML binding framework
openArchitectureWare Overview • Model Verificationusing Constraints • Code Generation • Integrating gen. codewith hand-written code • Model Modification/Completion • Model-to-model Transformation • Loading/Storing Models • Model Editing using UML Tools • Model Editing using Textual Editors • Model Editing using GMF Editors http://www.eclipse.org/gmt/oaw/diagram.php
openArchitectureWare Screenshots 1/2 Xpand Syntax Highlighting Content Outline • Xpand Editor Syntax analysis Code Completion Error reporting
openArchitectureWare Screenshots 2/2 • Textual DSLs with xText
openArchitectureWare growing “Ecosystem” • oAW is not a “standalone” tool (even before formally being in Eclipse,and since its acceptance into Eclipse.org hopefully increasingly less so) • Different aspects to this, e.g. specific “cartridges”, model input/output, Model To Text (M2T: Xpand, JET, MTL? Xpand chosen over JET for GMF 2.0) and Model To Model (M2M: Xtend, ATL, QVT) projects on eclipse.org, a shared “model bus” in MDDi, etc. • For example, the other day, we had this discussion about using SCM branching for “customizing” models, and the problems you would have when re-integrating the next vendor branch in a merge. Manually diff-ing XMI-stored models didn’t really sound too appealing - but oh, look, somebody appears to already be working on that: http://www.eclipse.org/emft/projects/compare/ - Nice.(In fact, at least two... also http://www.eclipse.org/gmt/amw/usecases/diff/. With oAW becoming integrated into eclipse.org/gmt and maybe later eclipse.org/modeling, hopefully we’ll see more coherence over time?)
openArchitectureWare Wrap-Up • Sorry we don‘t have time to go more in-depth about oAW itself here! • If all of this sounds interesting to you, check out: • http://www.eclipse.org/gmt/oaw • http://www.openarchitectureware.org • Other oAW presentations & articles on-line (http://www.eclipse.org/articles/ Article-FromFrontendToCode-MDSDInPractice/article.html good starter!) • PS: http://www.andromda.org/ is another of several such toolkits. AndroMDA appears to focus more on UML models and specific cartridges, while oAW probably positions itself as a more generic Eclipse-centric MDD platform. (Fornax is a project for building similar cartridges for oAW.)
AGENDA • Goal of Pragmatic MDD using openArchitectureWare at Odyssey • Positioning of approach within the larger MDD / MDA picture • openArchitectureWare, briefly: What? How? • Our Eclipse-based Designers • Software Demo • Q & A
Eclipse-based Workbench, in two “editions”: Business Edition: Simplified Eclipse RCP version Only proposes what is necessary for non-technical users (models). An OFS feature grouping all designers. Developer Edition Full Eclipse IDE + OFS feature Able to support full development projects OFS Workbench (Eclipse)
An OFS project is the container for the various types of models An OFS explorer has been designed to: filter access to models hide technical details (model and layout files, 2 in 1) encapsulate customization handling(a customized artifact is a copy of the original) Eclipse Common Navigator based Each type of model is editable through a dedicated designer (backed-up with a DSL) Odyssey Financial Studio Eclipse project
State diagram With specific meta-data Pageflow designer
BPMN-like In-house engine (for the moment) Process designer
Purchased from Innovations AG Fully compliant With OFS Rule designer
BOM designer • Not graphical (yet)
In a first time, all designers are “vertically” isolated No inter-designer communication Ex: The pageflow contains page URIs DSL models restricted to what can be expressed in our current target frameworks Except documentation In a second time, designers will be communicating DSL models can directly reference other models Ex: Pages can be drag & dropped in pageflows Business model is known to everyone Ex: An entity attribute can be drag & dropped in a page, corresponding visual representation is displayed Current frameworks will be extended to reflect model extensions Ex: Define a context for a pageflow, map page events to pageflow transitions, … Refactoring to be handled… But fortunately customization is only about adding ! Inter-designer communication
Business and Technical analysts work on the same artifact models Exchanged models also hold documentation Reduce “interpretation” and a convenient way of providing “local” documentation (DITA based) Simple customization operations do not even require technical skills, any more Ex: add attributes to entities, move fields in pages, reroute pageflows, … Business sketching Business analyst Customer requirements Draft new models Alter existing models Documentation Technical analyst Fills blanks Optimizations Integration Draft model New artifact version KPI results Production
AGENDA • Goal of Pragmatic MDD using openArchitectureWare at Odyssey • Positioning of approach within the larger MDD / MDA picture • openArchitectureWare, briefly: What? How? • Our Eclipse-based Designers • Software Demo • Q & A
AGENDA • Goal of Pragmatic MDD using openArchitectureWare at Odyssey • Positioning of approach within the larger MDD / MDA picture • openArchitectureWare, briefly: What? How? • Our Eclipse-based Designers • Software Demo • Q & A
Michael Vorburger mvorburger@odyssey-group.com Laurent Medioni lmedioni@odyssey-group.com Odyssey Financial Technologies http://www.odyssey-group.com