Pragmatic Model Driven Development using openArchitectureWare

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





> 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





> 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 attemptPractical models for technical artifacts (P[I/S]M)

– No overweight models overloaded with meta-dataLocal and tactical models, each one customizable through dedicated tools

– Always use generated code from models when a model existsModels 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 modeledOnly 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)

Storage representation (XMI)

Store (EMF)

Generate (oAW)

Executable representation (java, xml, …)

Executable representation (java, xml, …)

Projection (GMF)

Editable representation (GMF editor)

Import (oAW)http://martinfowler.com/articles/languageWorkbench.html

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 artefact Generate artefact

Constraint checking

Model to model transf.

11

AGENDA





> 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

http://www.eclipse.org/gmt/oaw/diagram.php

1. Model Verificationusing Constraints

2. Code Generation

3. Integrating gen. codewith 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: 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?)

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:

– 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.)

19

AGENDA





> Software Demo

> Q & A

20

OFS Workbench (Eclipse)

Eclipse-based Workbench, in two “editions”:

> Business Edition: Simplified Eclipse RCP versionOnly proposes what is necessary for non-technical users(models). An OFS feature grouping all designers.

> Developer EditionFull Eclipse IDE + OFS featureAble 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 diagramWith specific meta-data

23

Process designer> BPMN-like

In-house engine(for the moment)

24

Rule designer> Purchased from Innovations AG

Fully compliantWith OFS

25

BOM designer

Not graphical (yet)

26

Inter-designer communication

> In a first time, all designers are “vertically” isolated

– No inter-designer communicationEx: The pageflow contains page URIs

– DSL models restricted to what can be expressed in our current target frameworksExcept documentation

> In a second time, designers will be communicating

– DSL models can directly reference other modelsEx: Pages can be drag & dropped in pageflows

– Business model is known to everyoneEx: An entity attribute can be drag & dropped in a page, corresponding visual representation is displayed

– Current frameworks will be extended to reflect model extensionsEx: 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 analystCustomer requirementsDraft new modelsAlter existing modelsDocumentation

Technical analystFills blanksOptimizationsIntegration

ProductionKPI results New artifact version

Draft model

> Business and Technical analysts work on the same artifact models

> Exchanged models also hold documentationReduce “interpretation” and a convenient way of providing “local” documentation (DITA based)

> Simple customization operations do not even require technical skills, any moreEx: add attributes to entities, move fields in pages, reroute pageflows, …

28

AGENDA





> Software Demo

> Q & A

29

AGENDA





> Software Demo

> Q & A

Michael Vorburger [email protected]

Laurent Medioni [email protected]

Odyssey Financial Technologies

http://www.odyssey-group.com

Technology

Pragmatic Model Driven Development using openArchitectureWare