Pragmatic Model Driven Development (MDD) using openArchitectureWare Michael Vorburger & Laurent Medioni Odyssey Financial Technologies 1640

2 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

3 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

4 >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

5 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

6 Positioning - MDA >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.

7 Positioning - MDD >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…

8 >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) Positioning - DSL Abstract representation (ecore) Storage representation (XMI) Store (EMF) Generate (oAW) Executable representatio n (java, xml, …) Projection (GMF) Editable representation (GMF editor) Import (oAW)

9 BOM centric >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, …

10 Positioning - Target Eclipse designers Technical target oAW Import existing artefactGenerate artefact Constraint checking Model to model transf.

11 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

12 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

13 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 3 rd -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

14 openArchitectureWare Overview 1.Model Verification using Constraints 2.Code Generation 3.Integrating gen. code with hand-written code 4.Model Modification/Completion 5.Model-to-model Transformation 6.Loading/Storing Models 7.Model Editing using UML Tools 8.Model Editing using Textual Editors 9.Model Editing using GMF Editors

15 openArchitectureWare Screenshots 1/2 Xpand Editor Xpand Syntax Highlighting Content Outline Syntax analysis Code Completion Error reporting

16 openArchitectureWare Screenshots 2/2 Textual DSLs with xText

17 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: - Nice. (In fact, at least two... also With oAW becoming integrated into eclipse.org/gmt and maybe later eclipse.org/modeling, hopefully we’ll see more coherence over time?)

18 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: – – –Other oAW presentations & articles on-line ( Article-FromFrontendToCode-MDSDInPractice/article.html good starter!) Article-FromFrontendToCode-MDSDInPractice/article.html >PS: 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.)

19 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

20 OFS Workbench (Eclipse) 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

21 Odyssey Financial Studio Eclipse project >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)

22 Pageflow designer >State diagram With specific meta-data

23 Process designer >BPMN-like In-house engine (for the moment)

24 Rule designer >Purchased from Innovations AG Fully compliant With OFS

25 BOM designer Not graphical (yet)

26 Inter-designer communication >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 !

27 Business sketching Business analyst Customer requirements Draft new models Alter existing models Documentation Technical analyst Fills blanks Optimizations Integration Production KPI results New artifact version Draft model >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, …

28 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

29 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 Laurent Odyssey Financial Technologies