Code Generation, Cambridge, UK

10 April 2014

10:45-12:15

Steven Kelly

© 2014 2 © 2014 2

Contents

Is MDD right for my project?

Hard factors: MDD Economics 101

– Cost

– Time

– Productivity

Soft factors: Fearless Change

– Selling the idea

– Mindshare

– Organizational change

© 2014 3 © 2014 3

Domain-Specific Modelling: DSM your language your code

Productivity increase: 5-10x

500 %

1000 %

750 %

600 %

900 %

500 %

600 %

0 %

100 %

200 %

300 %

400 %

500 %

600 %

700 %

800 %

900 %

1000 %

Embedded UI

applications

Mobile phone

software

Phone switch

features

Call

processing

services

Heart rate

monitor

J2EE web

application

Home

automation

Domains

Percent Increase

Compared to earlier practice (typically hand-coding)

http://metacase.com/blogs/stevek/blogView?entry=3446309083

© 2014 4 © 2014 4

Code ≈ UML ≈ MDA ≠ DSM

http://metacase.com/blogs/stevek/blogView?entry=3446309083

© 2014 5

Domain Idea

Finished Product

Model in DSM

language

Easy! Normal (many)

Done a few times before

Code generator

DSM language

Framework code

What is needed for DSM: put your expert in a tool!

Domain Framework

Generate code

Expert (few)

© 2014 6 © 2014 6

Where to apply DSM?

More than one developer doing similar tasks – Or large portion of the work similar to earlier products

– Or several products made in parallel

Domain expertise needed – Non-programmers can participate

Common cases include: – Product Family

– Platform-based development

– Configuration

– Business rule definitions

– Embedded devices

© 2014 7 © 2014 7

Choosing a good domain for DSM

If you have more than one candidate, pick best

Organizational factors:

Maturity of target business area in company?

Many developers?

Low coupling with external organizations?

Related to other candidate domains?

Extent of customization per customer?

© 2014 8 © 2014 8

Choosing a good domain for DSM

Technical preparedness:

Source code examples exists

– Offers a basis for the generator

In-house framework in use

– Provide guidelines, programming model, best practices (supported by the generator)

Architect & expert developers available

– Never, ever try building DSM with summer interns!

Software development process maturity?

– Should be mature, but not too locked down

http://tinyurl.com/ChoosingDomain

Score your domain(s)!

© 2014 9 © 2014 9

Steps in DSM introduction: proof of concept, pilot, deploy

Effort and calendar time are different things

Proof of concept

Pilot

Deployment

Use

Time

~ Months ~

~ Weeks ~

~ Years ~

© 2014 10 © 2014 10

Hard Factors: MDD Economics 101

© 2014 11 © 2014 11

Limitations of less mature tools

Single user

Single modelling language at a time

Simple metamodels – Focus on objects, basic properties, binary relationships

Simple notation – Box + icon + labels

Resulting modelling tool primitive – Missing majority of functions users expect in such a tool

Updating modelling language invalidates models

Upgrading tool framework invalidates tool

Hosted in IDE – benevolent integration or lock-in? – Is the best UI design for coding also best for modelling?

© 2014 12 © 2014 12

DSM Solution Implementation Time

63 language concepts

XML generator

60 language concepts

C, HTML, script generators

36 language concepts

Assembler generator

77 language concepts

Python generator

Java generator for

simulation

143 language concepts

J2EE generator

Man days

http://metacase.com/blogs/stevek/blogView?entry=3446309083

© 2014 13 © 2014 13

Independent tool comparison: El Kouhen et al. 2012: language

12

6

0.5

5

25

0

5

10

15

20

25

30

RSA GME MetaEdit+ Obeo GMF

Days to implement BPMN

http://tinyurl.com/gerard12

© 2014 14 © 2014 14

Co-opetition tool comparison: LWC 2013: generators & framework

Ensō Más SugarJ

Whole Platform

MPS Onion

MetaEdit+

Rascal

Xtext

Spoofax

0

500

1000

1500

2000

2500

3000

20 30 40 50 60 70 80 90 100

SLOC

% Feature Coverage

Total SLOC vs. Coverage Below/right of curve = better

http://erdweg.org/publications/language-workbench-state.pdf

© 2014 15 © 2014 15

How to solve vendor lock-in?

Use only tools that have interfaces!

– e.g. API, file-based (XML, or better)

Language workbenches usually can’t lock you in

– Can make generators to export data to other tools

– Tools should also allow you to access the metamodels

© 2014 16 © 2014 16

Economics

0

10

20

30

40

50

60

70

80

90

100

0 1 2 3 4 5 6

Cost

Repetitions

Current MDD

© 2014 17 © 2014 17

Return on investment: Elektrobit

10 days for 1st version of language & generators

– Estimate 1 more week for later improvements

Product development with:

– Old way: 10 days

– DSM: 1 day

0 5 10 15 20

DSM

Coding

Days

Creating DSM solution

Test suite 1

Test suite 2

Test suite 3

Test suite 4

Test suite 5

www.thinkmind.org/download.php?articleid=valid_2011_5_20_40049

© 2014 18 © 2014 18

Return on investment: Panasonic

15 days for language and generator

– Apps into touchscreen device

Product development with:

– Old way: 17 days

– DSM: 4 days

0 5 10 15 20 25 30 35

DSM

Coding

Days

Creating DSM solution

Product 1

Product 2

Product 3

Product 4

Product 5

www.dsmforum.org/events/DSM07/papers/safa.pdf

© 2014 19 © 2014 19

Return on investment: Polar

7½ days for language and generator

– Apps for sports computers

Product development with:

– Old way: 23 days

– DSM: 2.3 days

www.dsmforum.org/events/DSM09/Papers/Karna.pdf

© 2014 20 © 2014 20

Economics of DSM ramp-up productivity

Current practice: – 6 developers

– 1 man-month per unit of application

Month 1-4: Creating language and generators – 1 creates the language and generators

– 5 continue to develop applications in old way, 1 unit/month

– 20 application units ready (cf. 24 with the old approach)

Month 5: DSM deployment – 5x more productive

– 1 maintains language/generators

– 5 use DSM, make 5 units/month/dev

– 45 application units ready (cf. 30)

Month 6 – 70 application units ready (cf. 36)

App units in month

0

5

10

15

20

25

30

1 2 3 4 5 6 Month

Ap

p u

nit

s

Current MDD

Current MDD

© 2014 21 © 2014 21

Economics of DSM: costs of tool & modeling work

Value of app unit = 10.000 – Total effort costs

Developer more productive: – 50.000€ of value / month

– 40.000€ extra value / month

Tools cost per developer: – 250€ / month for tools

– Only needed after month 4

Cost per unit down over 75% – From 10.000€ to 2.450€

– Includes tools and language/ generator development

Months: 6 12

Extra app units 34 148

Extra value 340 000 1 480 000

Extra cost 2 500 10 000

Cost of 6 developers / month 60 000

Cost of tools / month 1 250

Total cost /month with MDD 61 250

Units / month with MDD 25

Cost / unit with MDD 2 450

Plug in your own figures!

© 2014 22 © 2014 22

Soft Factors: Fearless Change

© 2014 23 © 2014 23

Organizing for DSM

Building a DSM solution requires few resources

– Quality not quantity: Nokia, Panasonic, Polar 1-2 persons

– For lower-level DSM tools, need to add 3-5 coders

– May be best to start high-level, go low later if needed

Team needs both domain and code expertise

– Best candidates are normally expert developers

All must balance elegance with pragmatism

Look for people who build macros and templates:

– For the whole team, not just themselves

– Prepared to maintain and document them

Start looking for pilot DSM use project early

© 2014 24 © 2014 24

Proof of concept

Implement core subset of DSM solution

– Modelling language, generator, model for simple app.

Shows concrete results to management

– Not just glossy brochures, books – or slide sets!

Preparation:

– Outline scope for DSM, and part to be covered now

– Pick DSM creation team

– Add internal/external DSM expert, if possible

– Set workshop time (2 days), meeting with managers

• Ideally meeting is straight after

• Hard deadline focuses group on making concrete results

© 2014 25 © 2014 25

Presenting things to managers

Polish the presentation

– Nice looking models, animation, simulation

Generated stuff follows known structures

– Documents are in company’s template

– Deployment guides/test etc. look like today’s

Demo creating a model from scratch

– Shows what MDD looks in practice

– Also show larger, pre-made cases

Discuss integration with existing processes/infra

Describe opportunities that MDD makes possible

Describe how it supports management’s goals

© 2014 26 © 2014 26

Defining the DSM solution

The PoC went well, management was happy, you have a good handle on what to do next...

Danger: pitfalls ahead!

– As Machiavelli put it:

"…there is nothing more difficult to carry out, nor more doubtful of success, nor more dangerous to handle than to initiate a new order of things."

Beware of excesses, combat them with "let's see"

– Enthusiasm from managers

– Doubt, worry, conservatism from developers

Take PoC as "build one to throw away"

© 2014 27 © 2014 27

Organizational Change

“Fearless change: Patterns for Introducing New Ideas”

Corporate Angel – Support of high-level manager

Local Leader – Support of immediate boss

Dedicated Champion – DSM included in your job description

Personal Touch – Change happens one individual at a time

Energizer – Encourage those involved to share experiences

“Yes: 50 Scientifically Proven Ways to Be Persuasive”

Who’s who in your case?

© 2014 28 © 2014 28

First things first: preparing for pilot project

1. Modelling language – Concepts and inter-relations

– Rules • Resist tendency to add too many to "protect" modellers

– Notation • Simple for now, easily distinguishable

2. Example models and use scenarios – Try the language out on (semi-) real applications

– Start thinking about clearest model reuse cases

3. Generators and domain framework – Resist temptation to jump in early here

4. Integration to the rest of the process – Minimum necessary at this stage

© 2014 29 © 2014 29

Pilot project

When language & generators ready for 1st real case

– Also need prototype documentation and training

Separate team to test DSM solution

– Must be on a real application (not time critical)

– DSM solution creation team work "over the wall"

Opens up modelling language to change again

– Modelling language was stable when making generator

– Grit your teeth and listen to criticism of your baby!

Prepare for versioning nightmare

– All parts of DSM solution will be changing on the fly

Gather rough productivity statistics and opinions

– They prove nothing, but are evidence nonetheless

© 2014 30 © 2014 30

DSM deployment

Learn about organizational change (Machiavelli!) – Talk to IT department for tool roll-out experience

– Talk to old-time developer for process change experience

Polish the DSM solution – Decent symbols

– Generated code, framework, autobuild fit your standards

– Refactor generators for smooth evolution

– Learning material and training for modellers

– Documentation of solution for later evolution

Introduction and evolution process – Initial installation and upgrades for various DSM parts

Get it right before you “ship” – Bad early experiences colour opinions for a long time

© 2014 31

Europe: MetaCase

Ylistönmäentie 31 FI-40500 Jyväskylä, Finland

Phone +358 14 641 000 Fax +358 420 648 606

USA: MetaCase

5605 North MacArthur Blvd. 11th Floor, Irving, Texas 75038

Phone (972) 819-2039 Fax (480) 247-5501

info@metacase.com www.metacase.com

Thank you!

Questions?

"Very practical and highly recommended" Computing Reviews

"Excellent", Amazon review

© 2014 32 © 2014 32

Literature and references

Kelly & Tolvanen, Domain-Specific Modeling, Wiley, 2008 Panasonic: Safa, L., The Making Of User-Interface

Designer: A Proprietary DSM Tool, Procs of DSM’07, OOPSLA, 2007.

Polar: Kärnä et al., Evaluating the use of DSM in embedded UI application development, Procs of DSM’09, OOPSLA, 2009.

Elektrobit: Puolitaival, O.-P., et al., Utilizing Domain-Specific Modeling for Software Testing, Procs of VALID, 2011

MetaCase, Nokia case study, 2000 Weiss, D. M., Lai, C. T. R., Software Product-line

Engineering: A Family-Based Software Development Process, Addison Wesley Longman, 1999.

Manns & Rising, Fearless Change, 2004 Goldstein, Martin & Cialdini, Yes! 50 Scientifically Proven

Ways to be Persuasive, Free Press, 2009

See also URLs / references on slides

© 2014 33 © 2014 33

Engineer testimonials

“I could define a domain-specific language in about six hours - design, testing and one failed trial included,” says Laurent Safa

“Modeling with MetaEdit+ was indeed quite convenient and a lot easier to accomplish than trying to achieve the same results with Eclipse GMF,” Ulf Hesselbarth

“MetaEdit+ is by far the most advanced tool in DSL category,” Markus Voelter

“MetaEdit+ was the most flexible tool, allowed us to define own language syntax quickly,” David Narraway

“MetaEdit+ is the most sophisticated DSM tool,” Scott Ambler

© 2014 34 © 2014 34

Asking developers opinions

Survey results by Polar of 6 developers in pilot phase (scale 1-5, 5 best)

© 2014 35 © 2014 35

How to get data?

Must balance cost of data vs. quality of proof – 3 main ways to get data:

Feedback from multiple colleagues – Show your samples, or ask them to use MDD

– Effort needed: man-hours

Laboratory study – Implement a small, typical feature

– Several developers, several implementations

– Effort needed: 1-2 man-days

Pilot project – Implement whole product or large portion of product

– Usually by several developers

– Effort needed: man-months

© 2014 36 © 2014 36

Important features in MDD tools

Survey by MediaDev, 2007

0 %

5 %

10 %

15 %

20 %

25 %

30 %

35 %

© 2014 37 © 2014 37

DSM as a continuous process

Keeping the DSM solution team

– Staying with this domain for near term

• Minor consultation to parallel DSM projects

– Later some can become roving internal DSM experts

Evolutionary forces

– Evolution of the domain

– Improvements to the DSM solution

– Broadening the scope of the domain

Sunsetting the domain

– Make sure you mothball all tools and components

Identifying new candidate domains

© 2014 38 © 2014 38

How is DSM different from MDA?

Same idea on using models and transformations, but...

DSM is always full code direct from models – Not OMG MDA (elaborationist) – Simpler in terms of versioning and management

DSM = domain-specific language and generators – MDA is UML-based*

No reverse- or round-trip engineering in DSM – We want a real lift in the level of abstraction – How often do you reverse engineer assembler to code?

Separation of concerns – You are the experts in your domain and code (not the

vendor)

DSM is agile: as much or as little as you want

* official definition, www.omg.org