The PISA Project: a MDD case study

In collaboration with

The PISA Project
A Model Driven Development case study
Pedro J. Molina, PhD.
May 19th, 2007

Contents

Introduction
Goals
Foundations
Design aspects & Trade-offs
Demo
Problems found
Facts & Results
Capgemini Spain / Tecnology Services
The PISA Project, May 19th 2007
© 2007 Capgemini - All rights reserved 1

Timetable

15:30 H

Presentation

65 min.
16:35 H

16:45 H
Q&A 10 min.


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.


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


Infrastructure Scope

Back-end
• Host based IBM CICS system
• Oracle DBs
BD Back-end • Sql Server DBs
• 3rd parties Web Services

Front-End
• 5000 computers
Middle-ware • across 1000 branches

• Windows XP
• Specialized Financial Devices
− Check’s scanners
− Financial Printers
Front-end


Contents

Introduction
Goals
Foundations
Demo
Problems found
Facts & Results

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)


Contents

Introduction
Goals
Foundations
Demo
Problems found
Facts & Results

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


Novak’s Rule

“Automatic Programming is defined as the synthesis
of 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.


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.


Domain Engineering & Software Factory Approach
Investment
Domain Engineering

Feedback:
Customer suggestions
Application Development App. Engineers suggestions
Workbench

Application Engineering

ROI
Aplications


Model Driven Development

Model / PIM Characteristics:
• Forward Engineering (no reverse
engineering)
Refine / • Value is in the model. Code is
Transform discarded in each iteration.
• Technology Independent.

Design Model / PSM
Tools:
• Editors / Modelers
… • Validators
• Code Generators
• 3Gen Development tools
Applications


Economics
Traditional cost = N · CT
Domain engineering cost = I + N · CF
Saving
SF = CT - CF
5 CT

4 CT

ROI
3 CT
Costs

2 CT
I
In this domain, there is an order of
magnitude of 2000-2500
CT
business applications!!

1 2 3 4 5
Family members

Contents

Introduction
Goals
Foundations
Demo
Problems found
Facts & Results

Modelling the business

Aspects to be model Possible representations
• Navigation diagrams • Graphical / Visual DSL
• Presentation • Graphical / 2D layout
• Presentation logic • Textual / Grammatical based
• Flow Mapping • Hierarchical (tree) form
• Service Consumption • Tabular form

Selection:
• Each aspect requires an specific
representation form


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)


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.


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


Workbench Architecture Overview


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


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.


Example DSL. Navigational Diagram


Development Workbench 1/4

Workbench
integrated in Visual
Studio



Custom action
language

Colored syntax

Intellisense support



Error handling
integrated in Visual
Studio



DSL example

Navigational
diagram


Contents

Introduction
Goals
Foundations
Demo
Problems found
Facts & Results

In collaboration with

Demo
Recording:
Modelling a simple Business Function

Contents

Introduction
Goals
Foundations
Demo
Problems found
Facts & Results

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


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

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.


Contents

Introduction
Goals
Foundations
Demo
Problems found
Facts & Results

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


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.


Distribution & defect cost
Traditional life cycle
MDD life cycle
Defect cost
Defects
exponential
%

Analysis Design Build Maintenance

Snow ball effect

The PISA Project: a MDD case study

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (20)

Semelhante a The PISA Project: a MDD case study

Semelhante a The PISA Project: a MDD case study (20)

Mais de Pedro J. Molina

Mais de Pedro J. Molina (17)

Último

Último (20)

The PISA Project: a MDD case study