the pisa project

In collaboration with

The PISA ProjectA Model Driven Development case study

Pedro J. Molina, PhD.

May 19th, 2007

© 2007 Capgemini - All rights reserved

The PISA Project, May 19th 2007

1

Capgemini Spain / Tecnology Services

Contents

� Introduction

� Goals

� Foundations

� Design aspects & Trade-offs

� Demo

� Problems found

� Facts & Results



2


Q&A

Timetable

Presentation

65 min.

10 min.

15:30 H

16:35 H

16:45 H



3


Introduction

�Collaboration project between:

• Bancaja is a Spanish bank with 1000 branches across Spain

− Headquarters located in Valencia

• Capgemini is a global company with 50.000 employees providing solutions for consulting, technology & outsourcing.

PISA: Architecture for software & infrastructure platform.



4


PISA Scope

• Migration of the Financial Terminal

− 2 years, 15 people involved (avg. full-time)

−O.S. migration in the front-end

Windows NT � Windows XP … � Windows Vista

− Components written in VC++, VB4. Recompiled and migrated to VC++ & C# .NET

− Redesign of the financial platform to take advantage of the new capabilities

− Family of 2500 business functions to be migrated

− Semi-automated tools to migrate old applications to the new model



5


Infrastructure Scope

� Back-end

• Host based IBM CICS system

• Oracle DBs

• Sql Server DBs

• 3rd parties Web Services

� Front-End

• 5000 computers

• across 1000 branches

• Windows XP

• Specialized Financial Devices

− Check’s scanners

− Financial Printers

Back-end

Front-end

Middle-ware

BD



6


Contents

� Introduction

� Goals

� Foundations


� Demo

� Problems found

� Facts & Results



7


Goals

�Productivity gain

�Better workload variability management

�Technology independence

�Protection of the house processes and Know-How against future migration waves

�Reduce maintenance costs• Unique IDE (integrated development environment)



8


Contents

� Introduction

� Goals

� Foundations


� Demo

� Problems found

� Facts & Results



9


Foundations

� Model Driven Development• Usage of models to capture business in a declarative way• Models used to lead & drive the software life cycle

− From analysis to implementation− Models validated formally

� Separation of Concerns• Separation of core-business from technological issues

� Code Generation and automated deploy• Used to guarantee:

− No human errors, robust code− Compliance with standards − Controlled execution environment− Reduce tampering opportunities

� Pragmatic approach• Full 100% Code Generation seen as an utopia• Looking to solve 80%-20% scenarios



10


Novak’s Rule

“Automatic Programming is defined as the synthesisof a program from a specification.

If automatic programming is to be useful, the specification must be smaller and easier to write than the program would be if written in a conventional programming language.”

G.S. Novak.



11


Economics of MDD

�Economies of Scale• The condition where inputs like resources are combined to produce multiples instances of a single product.

• However multiple instances in SW are valueless.

− SW copy cost � 0 €

�Economies of Scope• The condition where inputs are combined to produce different instances of products. The cost of producing them together is smaller than producing them in different production lines. Saving is achieved thanks to the reuse of common parts.



12


Domain Engineering & Software Factory Approach

Domain Engineering

Application Engineering

Application Development

Workbench

Aplications

Feedback:

� Customer suggestions

� App. Engineers suggestions

ROI

Investment



13


Model Driven Development

Model / PIM

Design Model / PSM

Refine /

Transform

Applications

…

Characteristics:

• Forward Engineering (no reverse engineering)

• Value is in the model. Code is discarded in each iteration.

• Technology Independent.

Tools:

• Editors / Modelers

• Validators

• Code Generators

• 3Gen Development tools



14


Economics

� Traditional cost = N · CT

� Domain engineering cost = I + N · CF

Family members1 2 3 4 5

5 CT

4 CT

3 CT

2 CT

CT

Costs

I

Saving

SF = CT - CF

ROI

In this domain, there is an order of

magnitude of 2000-2500

business applications!!



15


Contents

� Introduction

� Goals

� Foundations


� Demo

� Problems found

� Facts & Results



16


Modelling the business

� Aspects to be model

• Navigation diagrams

• Presentation

• Presentation logic

• Flow Mapping

• Service Consumption

� Possible representations

• Graphical / Visual DSL

• Graphical / 2D layout

• Textual / Grammatical based

• Hierarchical (tree) form

• Tabular form

� Selection:

• Each aspect requires an specific representation form



17


Defining the Metamodel

� 6 moths working with experts in the domain

�Studding the domain and deciding:• The Variable part � To be modelled

• The Immutable part � To be incorporated in the runtime

�Trade-off between Parameterization vs Standardization

“Lo bueno, si breve, dos veces bueno.”

B. Gracián, (XVII)

“Everything should be as simple as possible, but no simpler.”

A. Einstein, (XX)



18


Solution

�Solution provided• Design of the new platform

• Component Migration

• Development of the new components

• Design and implementation of an specification for all business functions based on XML, Schema and a tailored abstract-action language.

• Design and implementation of a full DSL language workbench for specifying business functions independently of the implementation technology

• Design and implementation of a code generation to produce the working implementation over the platform.

• Implementation of semi-automatic migration tools to help in the transition between models.



19


Technology

�Platform• .NET Platform, C# and Interop to legacy C++ DLL

�Application Workbench• Visual Studio (full integration)

• MS DSL Tools

• Custom parser for a customized language (Antlr based)

• Extension Packages to provide Custom Parsing in VS2005

• Code generator implemented in C#

−Generates 100% of code. Fully automated.

− No manual code is allowed to be inserted in the implementation



20


Workbench Architecture Overview



21


Tools implemented

�PISA Workbench• Modelling tool built on the top of Visual Studio 2005

− VS extensibility, parsers, intellisense™, DSL Tools

�PISA Validator• Checks a model and reports errors & warnings

�PISA Code Generator• Converts an specification into a 100% executable C# .NET code

�PISA Runtime• Components and helper libraries to support the runtime enviroment



22


MS DSL Tools

� In beta for 2 years

� Version 1.00 released in September 2006

� Early adopters, but not sure about it feasibility till v. 1.0

� Now already integrated into the solution

� Used for designing the User Interface navigation of the business

application in terms of views and navigation.

� DSL has a moderate/high learning curve. Once learned it is

productive to build new diagrams.



23


Example DSL. Navigational Diagram



24


Development Workbench 1/4

� Workbench integrated in Visual Studio



25



� Custom action language

� Colored syntax

� Intellisense support



26



� Error handling integrated in Visual Studio



27



� DSL example

� Navigational diagram



28


Contents

� Introduction

� Goals

� Foundations


� Demo

� Problems found

� Facts & Results

In collaboration with

Demo

Recording:

Modelling a simple Business Function



30


Contents

� Introduction

� Goals

� Foundations


� Demo

� Problems found

� Facts & Results



31


Problems 1/3

� People reluctant to change• Part of the traditional programmers feel conformable and

productive with their current tools.

• They are experts in such tools and are reluctant to change to a new work method.

� How to address it• Involve them in the design

• Show the benefits of the new approach

• Educate the developers to be able to take full advantage of the new system



32


Problems 2/3

� Code escapes• The platform is closed enough to keep process under control,

safety and homogeneous.

• However from time to time, new functionality has to be added or plugged to the system.

• The system should be ready to incorporate these extensions quickly.

• Otherwise, creative programmers will be tempted to by-pass the platform and add manual code in the wrong place.

� How to address it• Have a dedicated team to study & implement new functionality

required not present in the current system

• Give high priority to extensions to the platform without equivalents workarounds



33


Problems 3/3

� Debugging tools• A MDD approach raises the abstraction level from code to a

conceptual one.

• Debugging ideally should be done at such conceptual level.

� How to address it• With the actual technology, this is a hard topic to provide and

implement.

• However animators, interpreters and model checkers could be helpful in the task.

• Generate clean and traceable source code.

− This allows easy debugging in an environment with all this capabilities.



34


Contents

� Introduction

� Goals

� Foundations


� Demo

� Problems found

� Facts & Results



35


Benefits

� Increased Quality • Less coding errors

• Compliance with standards assured by a generator

� Increased Productivity

�Migration cost to incoming technologies will considerably be reduced.

�Unique integrated development environment (IDE)• Covering Modelling, Debugging, Versioning & Deployment



36


Benefits

�Know-How captured in two orthogonal levels:

• Business Know-How: captured in form of specifications: isolated from technological issues

• Technological Know-How: captured in form of best practices and code patterns in the code generator.



37


Distribution & defect cost

Defects

%

Analysis Design Build Maintenance

Traditional life cycle

MDD life cycle

Defect cost

exponential

Snow ball effect

www.capgemini.com

the pisa project

Documents