12 April 2014
Juha-Pekka Tolvanen
The business cases for
modeling and generators
Various styles of modeling
MDD done correctly
 Work at a higher level of abstraction and automatically
produce code, library calls, configuration, s...
Gains
 “The work that earlier took a whole week, is now done
during an afternoon”, an engineer at Elektrobit
 The measur...
MDD research
 Recent empirical research in industry practices found that:
success with modeling is most likely when compa...
Number of railway languages?
1) Mark Blackburn, Peter Denno, Virtual Design and Verification of Cyber-physical Systems: Industrial
Process Plant Design...
Detected productivity increase
* Productivity proportional to earlier practice
500 %
300 %
750 %
600 %
200 %
750 %
500 %
6...
PROCESS abc;
START;
TASK b_subscriber := subscriber_t_find (b_subnum);
DECISION b_subscriber.bill_paid AND reserve_vc (b_v...
Who creates and maintains them?
1. Standardization bodies:
– ISO, OMG, etc.
2. Industry associations and groups:
– ITU, SA...
6 ways to get the tools needed
1. Find an existing and suitable tool
2. Write own tool from scratch
3. Write own tool base...
PSL/PSA
 Defining languages with:
– Objects
– Properties
– Relationships
1 PROCESS hourly-enployee-procesing;
2 /* DATE O...
Eclipse TBK
 Three parts in modeling tool definition:
– Types
• Node and link
– Representation
• Symbols containing shape...
MetaEdit: abstract & concrete syntax
MetaEdit Personal, MetaCase, 1991
 Quality of the language depends on its definition!
 Definition of UML contains rules for elements that have
been remove...
Incremental language development
 Nobody gets the language right at the first try!
 The best way to build languages is i...
Effort to define language (& tool)
 Two insurance-specific languages:
“Insurance experts specify (with a tool) insurance
...
 Big variety in the effort to define DSL:
– Insurance DSL in CodeGen’11: 6 calendar months, 7 persons
– Insurance DSL in ...
 Empirical tool comparison*:
– Same language, different tools
* El Kouhen et al. Evaluation of Modeling Tools Adaptation,...
From products to projects
Product development
 Apply many times
– Several apps/features
 Maintenance
 Predictability
 ...
To apply languages and generators
in project organizations…
 Build them fast
 Accept uncertainty on the language constru...
Time needed to create languages
and generators must be short
63 language concepts XML
generator
60 language concepts
C, HT...
MetaEdit Personal, MetaCase, 1991
Evolution (of language & models)
 Maintenance is the biggest part in development!
 Ins...
Business case in terms of money
 5 months of work:
– By one person: 33.000 USD (or whole team: 233.000 USD)
– What the ot...
Generator development process
 Generator developer needs to master many things:
metamodel (&models), generator language, ...
Generator speed
 A company visiting CodeGen few years ago was using
4-core Pentium machine to run their generator for a
n...
Scalability, Collaboration
 Development is about collaboration!
 MDD is more than a few diagrams, it can be gigabytes of...
MDD solution created correctly
 Work at higher level of abstraction during language
creation too!
 Define only the neede...
Thank you!
For references, contact jpt@metacase.com
* Some of the examples shown are available to download at www.metacase...
Keynote at Code Generation 2014: The business cases of modeling and generators
Keynote at Code Generation 2014: The business cases of modeling and generators
Keynote at Code Generation 2014: The business cases of modeling and generators
Keynote at Code Generation 2014: The business cases of modeling and generators
Keynote at Code Generation 2014: The business cases of modeling and generators
Keynote at Code Generation 2014: The business cases of modeling and generators
Keynote at Code Generation 2014: The business cases of modeling and generators
Keynote at Code Generation 2014: The business cases of modeling and generators
Keynote at Code Generation 2014: The business cases of modeling and generators
Keynote at Code Generation 2014: The business cases of modeling and generators
Keynote at Code Generation 2014: The business cases of modeling and generators
Keynote at Code Generation 2014: The business cases of modeling and generators
Keynote at Code Generation 2014: The business cases of modeling and generators
Keynote at Code Generation 2014: The business cases of modeling and generators
Keynote at Code Generation 2014: The business cases of modeling and generators
Keynote at Code Generation 2014: The business cases of modeling and generators
Keynote at Code Generation 2014: The business cases of modeling and generators
Keynote at Code Generation 2014: The business cases of modeling and generators
Keynote at Code Generation 2014: The business cases of modeling and generators
Keynote at Code Generation 2014: The business cases of modeling and generators
Keynote at Code Generation 2014: The business cases of modeling and generators
Keynote at Code Generation 2014: The business cases of modeling and generators
Keynote at Code Generation 2014: The business cases of modeling and generators
Keynote at Code Generation 2014: The business cases of modeling and generators
Keynote at Code Generation 2014: The business cases of modeling and generators
Keynote at Code Generation 2014: The business cases of modeling and generators
Keynote at Code Generation 2014: The business cases of modeling and generators
Keynote at Code Generation 2014: The business cases of modeling and generators
Keynote at Code Generation 2014: The business cases of modeling and generators
Keynote at Code Generation 2014: The business cases of modeling and generators
Keynote at Code Generation 2014: The business cases of modeling and generators
Keynote at Code Generation 2014: The business cases of modeling and generators
Keynote at Code Generation 2014: The business cases of modeling and generators
Keynote at Code Generation 2014: The business cases of modeling and generators
Keynote at Code Generation 2014: The business cases of modeling and generators
Keynote at Code Generation 2014: The business cases of modeling and generators
Keynote at Code Generation 2014: The business cases of modeling and generators
Keynote at Code Generation 2014: The business cases of modeling and generators
Keynote at Code Generation 2014: The business cases of modeling and generators
Keynote at Code Generation 2014: The business cases of modeling and generators
Keynote at Code Generation 2014: The business cases of modeling and generators
Keynote at Code Generation 2014: The business cases of modeling and generators
Keynote at Code Generation 2014: The business cases of modeling and generators
Keynote at Code Generation 2014: The business cases of modeling and generators
Keynote at Code Generation 2014: The business cases of modeling and generators
Keynote at Code Generation 2014: The business cases of modeling and generators
Keynote at Code Generation 2014: The business cases of modeling and generators
Upcoming SlideShare
Loading in …5
×

Keynote at Code Generation 2014: The business cases of modeling and generators

3,657 views

Published on

There is no business case for modelling and generators – only for a specific language and generator in a specific situation. The right language in the right situation can improve productivity by an order of magnitude; the wrong language will reduce it. So what makes a language “right”?

In this talk we look what kinds of modelling languages and generators tend to be more beneficial than others –from the early days of modelling right up to the latest research. Getting more out of the models than their original creation required, raising the level of abstraction and addressing a specific need seem to be common characteristics of successful modelling and code generation approaches.

To evaluate the full business case we also need to look at the costs and benefits of creating languages, generators and tools. By applying the above principles to language creation itself, we can improve the quality of the resulting modelling language, whilst lowering the time and effort needed to create and maintain it. Other features important to the language developer include enabling tools to support language evolution, and improving tool scalability to tackle larger systems and teams.

Published in: Software, Technology
5 Comments
7 Likes
Statistics
Notes
  • A better resolution png on the family tree of modeling languages and their history is available at: http://www.metacase.com/blogs/jpt/blogView?entry=3575138300.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • @MarkCamp2: did you read the rest of the first sentence: 'There is no business case for modelling and generators – only for a specific language and generator in a specific situation'. JP and I are certainly proponents of modeling, we're just saying that you can't really make a business case for 'modeling' without stating which modeling language you're going to use.

    I definitely agree on the importance of a shared understanding of the requirements. Domain-specific modeling languages should generally be in the language of the problem domain. Rather than have the requirements in a Word document or text fields in DOORS, a good DSM language lets you specify a more precise and often more easily created description of what the system will do. Not every requirement can be expressed in such a nice way, but those parts that can be, should be.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • @Jouko: Thanks. The references mentioned in the slides describe more details on these gains.

    @Mark: I advocate modeling too, but for me the value of modeling and using generators depends on the case and on the type of languages applied. In some cases the productivity gain can be 1000% compared to no modeling or over half of the errors are prevented because of using correct modeling languages. Models provide naturally big value on communication, building understanding etc but that is hard to measure…so in Code Generation Conference I focused on those aspects that are easier to measure. If you know about studies that measure the more “softer” side: communication, understanding, teamwork etc I would be more than interested to read and learn more.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • I don't agree. I think there is a strong business case for modeling. Here is why I think that.

    First, I think the consensus is that IT projects are mostly failing to meet objectives. I've seen a lot of anecdotal evidence and some convincing studies (of federal contracts, over half fail), and not a shred of contrary evidence.

    My own experience confirms this conclusion. Every enterprise and every department that I have encountered is failing to identify requirements thoroughly, concisely, clearly (to the users), and accurately, leaving no hope that tool generation, no matter how well it is done or how it is done, succeeding. If you don't have an accurate user-understandable description of the problem, then there is no way for the implementers to solve the problem.

    The primary cause of failure is equally firmly established...poor identification or communication of business and user requirements. In other words, most projects fail, and most of the failures are due to modeling failures. I don't think it would be hard to proceed from those facts to the conclusion that there is a business case for solving the problem, i.e., completing the modeling phase successfully. It would lead to at least the possibility of success, and its absence is leading directly to failure to provide a return on investment.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Impressive productivity numbers JP!
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
3,657
On SlideShare
0
From Embeds
0
Number of Embeds
1,515
Actions
Shares
0
Downloads
61
Comments
5
Likes
7
Embeds 0
No embeds

No notes for slide

Keynote at Code Generation 2014: The business cases of modeling and generators

  1. 1. 12 April 2014 Juha-Pekka Tolvanen The business cases for modeling and generators
  2. 2. Various styles of modeling
  3. 3. MDD done correctly  Work at a higher level of abstraction and automatically produce code, library calls, configuration, simulation...  Specify less, generate more!
  4. 4. Gains  “The work that earlier took a whole week, is now done during an afternoon”, an engineer at Elektrobit  The measurement (n=6) revealed that Domain-Specific Modeling solution was on average 10 times as productive as the current development approach, study1 at Polar  Productivity improvement is 289%, study2 at USAF – Over 130 tasks, both initial development and maintenance – The differences in the average performance of the subjects are statistically significant at confidence levels exceeding 99% 1) Kärnä, J., et al., Evaluating the Use of Domain-Specific Modeling in Practice, Workshop on DSM, 2007 2) Kieburtz, R., et al. A software engineering experiment in software component generation, ICSE, 1996
  5. 5. MDD research  Recent empirical research in industry practices found that: success with modeling is most likely when companies develop their own bespoke modeling approaches, languages and tools rather than simply applying off-the- shelf solutions 1) Hutchinson, J., Whittle, J., Rouncefield, M. and Kristoffersen, S., “Empirical Assessment of MDE in Industry,” 2011 International Conference on Software Engineering (ICSE), pp.471-480. 2) Hutchinson, J., Rouncefield, M. and Whittle, J., “Model Driven Engineering Practices in Industry,” 2011 International Conference on Software Engineering (ICSE), pp. 633-642.
  6. 6. Number of railway languages?
  7. 7. 1) Mark Blackburn, Peter Denno, Virtual Design and Verification of Cyber-physical Systems: Industrial Process Plant Design, Procedia Computer Science, Volume 28, 2014
  8. 8. Detected productivity increase * Productivity proportional to earlier practice 500 % 300 % 750 % 600 % 200 % 750 % 500 % 600 % 0 % 100 % 200 % 300 % 400 % 500 % 600 % 700 % 800 % Embedded UI applications Message translation & validation Phone switch features Call processing services Adaptive cruise control Heart rate monitor J2EE web application Home automation Domain Percent Increase
  9. 9. PROCESS abc; START; TASK b_subscriber := subscriber_t_find (b_subnum); DECISION b_subscriber.bill_paid AND reserve_vc (b_vc); (T): OUTPUT initiate_answering_s (b_subscriber); NEXTSTATE works_done; (F): OUTPUT setup_nak_s TO cci_party; STOP; ENDDECISION; STATE works_done; INPUT ringing_s; TASK sso_party := SENDER; OUTPUT setup_ack_s TO cci_party; NEXTSTATE waiting_off_hook_s; INPUT input_busy_s; OUTPUT disconnect_fwd_req_s TO cci_party; NEXTSTATE waiting_disconnect_fwd_ack_s; ENDSTATE wait_ringing; STATE waiting_disconnect_fwd_ack_s; INPUT disconnect_fwd_ack_s; STOP; ENDSTATE waiting_disconnect_fwd_ack_s; STATE waiting_off_hook_s; INPUT off_hook_s; ...
  10. 10. Who creates and maintains them? 1. Standardization bodies: – ISO, OMG, etc. 2. Industry associations and groups: – ITU, SAE, AUTOSAR, EAST-ADL association, etc. 3. Tool vendors: – Labview, Simulink, Mendix, etc. 4. In-house: – Language engineers, tool-smiths, generator developers
  11. 11. 6 ways to get the tools needed 1. Find an existing and suitable tool 2. Write own tool from scratch 3. Write own tool based on frameworks 4. Metamodel, generate tool skeleton, add code for the rest 5. Metamodel, generate full tool over a framework 6. Metamodel, configure an existing tool with own language & generator  Use tools to get your tool! – Meta-tools, CASE shells, metasystems, metaCASE tools, DSL tools, language workbenches
  12. 12. PSL/PSA  Defining languages with: – Objects – Properties – Relationships 1 PROCESS hourly-enployee-procesing; 2 /* DATE OF IAST CHIANGE - JUN 26, 1976, 13:56:44 */ 3 DESCRIPTIONS; 4 this process performs those actions needed to interpret 5 time cards to produce a pay statement for each hourly 6 employee.; 7 KEYWORDS: independent; 8 ATTRIBUTES ARE: 9 complexity-level 10 high; 11 GENERATES: pay-statement, error-listing, 12 hourly-employee-report; 13 RECEIVES: time-card; 14 SUBPARTS ARE: hourly-paycheck-validation, hourly-emp-update, 15 h-report-entry-generation, 16 hourly-paycheck-production; 17 PART OF: payroll-processing; 18 DERIVES: pay-statement 19 USING: time-card, hourly-employee-record; 20 DERIVES: hourly-employee-report 21 USING: time-card, hourly-employee-record; 22 DERIVES: error-listing 23 USING: time-card, hourly-employee-record; 24 PROCEDURE; 25 1. compute gross pay from time card data. 26 2. compute tax, from gross pay. 27 3. subtract tax from gross pay to obtain net pay. 28 4. update hourly employee record accordingly. 29 5. update department record accordingly. 30 6. generate paycheck. 31 note: if status code specifies that the employee did not work 32 this week, no processing will be done for this employee.; 33 HAPPENS: 34 number-of-payments TIMES-PER pay-period; 35 TRIGGERED BY: hourly-emp-processing-event; 36 TERMINATION-CAUSES: 37 new-employee-processing-event; 38 SECURITY IS: company-only; Teichroew, D., Hershey, E., PSL/PSA, IEEE Trans. on Software Engineering, Vol SE-3 , 1, 1977
  13. 13. Eclipse TBK  Three parts in modeling tool definition: – Types • Node and link – Representation • Symbols containing shapes – UI • Menus, selectors… MacRoibeaird, S., Developing & Integrating Tools In Eclipse/PCTE, 1990
  14. 14. MetaEdit: abstract & concrete syntax MetaEdit Personal, MetaCase, 1991
  15. 15.  Quality of the language depends on its definition!  Definition of UML contains rules for elements that have been removed several versions ago - 5 years ago Fragmented definition • Concepts in metamodel • Rules in constraint language • Notation in symbol definitions • Transformations in code, … • Tool functions in code, .ico … Integrated definition • Change in one place updates it everywhere: • in rules and constraints, • in symbols, • in generators, • toolbars, icons, etc. 361 errors in UML 2.0: Bauerdick et al, in Procs of UML 2004, LNCS 3273, Springer, 2004 320 errors in UML 2.3: Wilke & Demuth, 2010, journal.ub.tu-berlin.de/eceasst/article/download/669/682‎ Quality of resulting language (& tool)
  16. 16. Incremental language development  Nobody gets the language right at the first try!  The best way to build languages is in incremental steps together with language users • Language defined disconnected from the users • Language defined as a spec on paper • Partial, like plain schema • Language changed without considering work done • Language users are directly involved • Each “unit” of the language tried out in the real world • Influence of language change checked against other parts of the language
  17. 17. Effort to define language (& tool)  Two insurance-specific languages: “Insurance experts specify (with a tool) insurance products while at the backend the models are exported to a runtime execution environment” Case from CodeGen’11 talk Case in www.dsmbook.com PropertySpec: / Renewal Date RoleSpec: Named Driver RuleSpec: Minimum Insured Age Calculation: Calculate Renewal Date Product: FleetPlan Product: FleetN-N Product: FleetN-N
  18. 18.  Big variety in the effort to define DSL: – Insurance DSL in CodeGen’11: 6 calendar months, 7 persons – Insurance DSL in dsmbook.com: 11 days, 1 person  Fully-loaded annual pay rate: 80.000 USD – Cost varies a lot based on organizations and countries Case from CodeGen’11 talk Calendar months: 6 Persons: 7 Investment in time: 3½ years Investment in $: 280.000 Case in www.dsmbook.com Calendar months: 0,5 Persons: 1 Investment in time: 11 days Investment in $: 3.520 Effort to define language (& tool)
  19. 19.  Empirical tool comparison*: – Same language, different tools * El Kouhen et al. Evaluation of Modeling Tools Adaptation, 2012, http://hal.archives- ouvertes.fr/docs/00/70/68/41/PDF/Evaluation_of_Modeling_Tools_Adaptation.pdf Effort to get tool support Days to implement BPMN language
  20. 20. From products to projects Product development  Apply many times – Several apps/features  Maintenance  Predictability  Initial investment shared over time/ products/variants Projects  Apply mainly for the current case  Next customer?  A single project does not usually have a budget for language and generator development
  21. 21. To apply languages and generators in project organizations…  Build them fast  Accept uncertainty on the language constructs  Be ready to change frequently  Be ready to throw away, and start another  Allow language users to participate  Language Workbenches must support project organizations too!
  22. 22. Time needed to create languages and generators must be short 63 language concepts XML generator 60 language concepts C, HTML, build script generators 36 language concepts Assembler generator 77 language concepts Python generator Java generator for simulation 143 language concepts J2EE generator Man days
  23. 23. MetaEdit Personal, MetaCase, 1991 Evolution (of language & models)  Maintenance is the biggest part in development!  Insurance DSL in CodeGen 2011: “took 5 months to update models when language evolved” Language update scenario 1 1. Change language 2. Change tooling 3. Share/package updates 4. Install updates for all... 5. Update existing models Language update scenario 2 1. Change language – shared automatically – automatic tool update – models update automatically
  24. 24. Business case in terms of money  5 months of work: – By one person: 33.000 USD (or whole team: 233.000 USD) – What the other language users are doing meanwhile?  Missed opportunity: 5 months later is often bigger cost than 5 months of work! Calendar months: 5 Investment in $: 33.000 - 233.000 Calendar months: 0 Investment in $: 0
  25. 25. Generator development process  Generator developer needs to master many things: metamodel (&models), generator language, target language/libraries Fragmented: • Metamodel in X(SD) • Model in X(ML) • Generator in X(SLT) • Output in .x files Integrated: • Access metamodel from generator definition • Get from generated code to source models • Access models while debugging generators
  26. 26. Generator speed  A company visiting CodeGen few years ago was using 4-core Pentium machine to run their generator for a nightly build... and nights became too short!  Big differences between tools and generators  Comparison with an example*: • Read model • Read metamodel • Use temporary model storage/M2M • + execution Cuadrado & Molina, Building Domain-Specific Languages for Model- Driven Development, IEEE Software, 2007, http://doi.ieeecomputersociety.org/10.1109/MS.2007.135 & Kelly, S., blog: http://www.metacase.com/blogs/stevek/blogView?entry=3385914921
  27. 27. Scalability, Collaboration  Development is about collaboration!  MDD is more than a few diagrams, it can be gigabytes of models Single-user tool • 1 (XML) file • 1 person edits or… • diff & merge done later • Opening a larger model may take minutes... Collaboration tool • Repository with projects • Collaborative editing • No need to diff & merge • Handle billions of elements, use lazy loading, etc.
  28. 28. MDD solution created correctly  Work at higher level of abstraction during language creation too!  Define only the needed parts, get rest automatically  Special attention to: – Improving quality of language definitions – Incremental development approach, user participation – Expect (continuous) change in the domain – Effort and costs of language development – Generator development process and generator speed – Scalability of the tools
  29. 29. Thank you! For references, contact jpt@metacase.com * Some of the examples shown are available to download at www.metacase.com 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

×