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.
3. MDD done correctly
Work at a higher level of abstraction and automatically
produce code, library calls, configuration, simulation...
Specify less, generate more!
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. 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.
52. 1) Mark Blackburn, Peter Denno, Virtual Design and Verification of Cyber-physical Systems: Industrial
Process Plant Design, Procedia Computer Science, Volume 28, 2014
55. 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;
...
56. 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
57. 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
58.
59. 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
60. 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
62. 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)
63. 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
64. 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
65. 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)
66. 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
67. 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
68. 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!
69. 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
70. 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
71. 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
72. 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
73. 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
74. 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.
75. 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
76. 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