Pragmatic Model Driven Development MDD using open Architecture

Pragmatic Model Driven Development (MDD) using open. Architecture. Ware Michael Vorburger & Laurent Medioni Odyssey Financial Technologies 1640

2 AGENDA > > > Goal of Pragmatic MDD using open. Architecture. Ware at Odyssey Positioning of approach within the larger MDD / MDA picture open. Architecture. Ware, briefly: What? How? Our Eclipse-based Designers Software Demo Q&A

3 AGENDA > > > Goal of Pragmatic MDD using open. Architecture. Ware at Odyssey Positioning of approach within the larger MDD / MDA picture open. Architecture. Ware, briefly: What? How? Our Eclipse-based Designers Software Demo Q&A

4 Goal of Pragmatic MDD using open. Architecture. Ware at Odyssey > 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

5 AGENDA > > > Goal of Pragmatic MDD using open. Architecture. Ware at Odyssey Positioning of approach within the larger MDD / MDA picture open. Architecture. Ware, briefly: What? How? Our Eclipse-based Designers Software Demo Q&A

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

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 Positioning - DSL > 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 (o. AW) Store (EMF) Projection (GMF) Editable representation (GMF editor) Abstract representation (ecore) Storage representation (XMI) Generate (o. AW) http: //martinfowler. com/articles/language. Workbench. html Import (o. AW) Executable representatio n (java, xml, …)

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 Technical target Model to model transf. Import existing artefact Generate artefact Eclipse designers o. AW Constraint checking

11 AGENDA > > > Goal of Pragmatic MDD using open. Architecture. Ware at Odyssey Positioning of approach within the larger MDD / MDA picture open. Architecture. Ware, briefly: What? How? Our Eclipse-based Designers Software Demo Q&A

12 open. Architecture. Ware > o. AW is a Framework & Tools to: – Work with different meta models (Ecore, XML, Java. Beans) – Read models (parsing EMF XMI, UML 2, 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 o. AW > Fully open-source (Eclipse Public License v 1. 0, EPL), strong community – v 4 is part of Eclipse. org’s Generative Modeling Technologies (GMT) project – Formerly on openarchitectureware. org & Source. Forge > Packaged & delivered as flexible & modular Eclipse feature

13 open. Architecture. Ware Acronymland > Workflow Engine: Tying it all together. . . run from Eclipse, ant, etc. > Xpand: Template language & engine, model to text (M 2 T) transformations (Velocity / Free. Marker / EMF JET –ish, but with an o. AW-aware Eclipse editor etc. ) > Xtend: Functional model to model (M 2 M) 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 > x. Text: 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 o. AW checks > EMF: Eclipse‘s meta model (Ecore) / beans / editors / XML binding framework

14 open. Architecture. Ware Overview 1. Model Verification using Constraints 2. 3. Code Generation Integrating gen. code with hand-written code Model Modification/Completion 4. 5. 6. 7. 8. 9. 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

15 open. Architecture. Ware Screenshots 1/2 Xpand Editor Xpand Syntax Highlighting Content Outline Syntax analysis Code Completion Error reporting

16 open. Architecture. Ware Screenshots 2/2 Textual DSLs with x. Text

17 open. Architecture. Ware growing “Ecosystem” > o. AW 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 (M 2 T: Xpand, JET, MTL? Xpand chosen over JET for GMF 2. 0) and Model To Model (M 2 M: 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 o. AW becoming integrated into eclipse. org/gmt and maybe later eclipse. org/modeling, hopefully we’ll see more coherence over time? )

18 open. Architecture. Ware Wrap-Up > Sorry we don‘t have time to go more in-depth about o. AW itself here! > If all of this sounds interesting to you, check out: – http: //www. eclipse. org/gmt/oaw – http: //www. openarchitectureware. org – Other o. AW presentations & articles on-line (http: //www. eclipse. org/articles/ Article-From. Frontend. To. Code-MDSDIn. Practice/article. html good starter!) > PS: http: //www. andromda. org/ is another of several such toolkits. Andro. MDA appears to focus more on UML models and specific cartridges, while o. AW probably positions itself as a more generic Eclipse-centric MDD platform. (Fornax is a project for building similar cartridges for o. AW. )

19 AGENDA > > > Goal of Pragmatic MDD using open. Architecture. Ware at Odyssey Positioning of approach within the larger MDD / MDA picture open. Architecture. Ware, 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 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 analyst Technical analyst Draft model Customer requirements Draft new models Alter existing models Documentation Fills blanks Optimizations Integration KPI results New artifact version Production

28 AGENDA > > > Goal of Pragmatic MDD using open. Architecture. Ware at Odyssey Positioning of approach within the larger MDD / MDA picture open. Architecture. Ware, briefly: What? How? Our Eclipse-based Designers Software Demo Q&A

29 AGENDA > > > Goal of Pragmatic MDD using open. Architecture. Ware at Odyssey Positioning of approach within the larger MDD / MDA picture open. Architecture. Ware, briefly: What? How? Our Eclipse-based Designers Software Demo Q&A

Michael Vorburger mvorburger@odysseygroup. com Laurent Medioni lmedioni@odyssey-group. com Odyssey Financial Technologies http: //www. odyssey-group. com