Domain-Specific Modeling (DSM) enables raising the level of abstraction close to the problem domain yet generating production code from the models. These slides describe industrial experiences on DSM in four different domains: home automation, military radio, touch screen device and sports computer applications.

1. Industrial Experiences on
Domain-Specific Modeling

2. Contents
 Domain-Specific Modeling Languages: Introduction
 Review of industry cases
– Touch screen
– Home automation control
– Sports computer
– Military radio
 Summary and discussion

3. 1
4,5 5
6 6
40
0
5
10
15
20
25
30
35
40
Number of new product
features implemented in a
given time (productivity
proportional to Assembler)
A rise in productivity is overdue
 "The entire history of software
engineering is that of the rise in
levels of abstraction"
 New general-purpose
programming languages have
not increased productivity
 Abstraction of development can
be raised above current level...
 ... without losing control or
accepting substandard results
*Software Productivity Research & Capers Jones, 2002

4. What data is available behind the
statements* like:
"5-fold productivity increase when compared
to standard development methods"
"The quality of the generated code is clearly
better, simply because the modeling language
rules out errors"
"The DSM solution makes development
significantly faster and easier than the old
manual coding practices"
* source: www.metacase.com/cases/

5. Four cases in more detail
 Touch screen device (Panasonic)
 Home automation (Ouman)
 Sports computer (Polar Electro)
 Military radio (Elektrobit)

6. Case 1: Panasonic’s touch screen
devices (Safa, 2007)
 Home automation solution installed by construction firms
 Features for controlled
– Lights
– Heating
– Air-conditioning
– Electricity
– Alarms
• Burglar
• Gas
• Smoke
– Reporting (energy saving)

8. Evaluation method
 Compare DSM to current manual coding practice
 Two evaluation methods
1. Implemented an existing product with DSM
2. Implemented the existing features to a different target
platform
• The same models, a new generator

9.  Tool-chains covering:
– Generate
– Compile
– Upload
– Boot
– Run
 Generators for:
– PC simulation
– Touch screen
– Microcontroller

10. Measuring development time
 Build the same application with both approaches
– Measure the time used
 Results:
– DSM is 425% faster
 Implemented the same product
to a new platform
– 3 days for generator development
– 0 days for modeling

11. Return on investment: Panasonic
 DSM solution developed in 15 days
 Product development with:
– the current approach: 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

12. Case 2: Home automation
(Puolitaival, 2011)

13. Home automation,
remote control via mobile phone
 Ouman manufactures home automation systems
 Products are focused mainly on temperature control with
many different heating systems
 SMS interface for remote control

14. A language for specifying remote
control applications

15. One model for Ouman EH-60 product
remote controller

16. 0 5 10 15 20
DSM
"past"
Days
Creating DSM solution
Product 1
Product 2
Product 3
Product 4
Product 5
Return on investment
 DSM solution developed: 2 weeks
 Product development: 1-2 days
– Comparison to earlier development effort not possible since
outsourced
• Cost was 6 figure number
 DSM allows a non-programmer to develop applications

17. Case 3: Polar’s Sport computers
 Heart rate measuring, analysis and visualization
 Calorie calculation, like current, cumulative, expenditure rate, active time
 Speed: current, average, maximum
 Distance, based on interval, trip, recovery
 Altimeter, vertical speed, altitude alarms, slope counter, graphical trend
 Cycling information like pedaling rate and cycling power
 Barometer, pressure drop alarm, graphical trend
 Exercise diaries
 Sensor connectivity (heart rate, speed, cadence, power, GPS)
 Compass, Temperature, Odometer, Logbooks, etc.

18. About the product development
(Kärnä et al. 2009)
 Polar focused on UI application development
– Single largest piece of software
• Takes 40-50% of the development time
– Typically always vary among products
 Software development is constrained by limited
resources:
– Memory, processor speed and battery life
 Polar created the needed languages and generators
internally

19. Sample of UI application design

20. Evaluation methods
 Compare the use of DSM and the current practice
 Two research methods
– Laboratory study
• 6 current developers, 6 implementations
• Implement a small, typical feature
– Pilot project
• Implement large portion of a whole product
• 1 person

21. Results of the studies
 Laboratory study
– Measuring time: at least 750% faster
– Asking opinions: results (scale 1-5, 5 best):
 Pilot
– Measuring time:
>900% faster

22. Return on investment: Polar
 DSM solution developed in 60 hours
 Product development with:
– the current approach: 23 days
– DSM: 2,3 days

23. Case 4: Military radio
(Puolitaival et al., 2011)

24. EB Tough VoIP Features
 Tough VoIP is a wired phone
that is using UDP/IP network for
connection
 Manufacturer: Elektrobit
 Main features:
– Easy configuration
– Point-to-Point call
– All call
– War-proof device

25. Testing problem
ETC...

26. EB Test Tool Platform +
OpenTTCN tester
Two language solution
Model Model
MBT
TTCN-3TTCN-3
Modeling
one test case
Modeling a
test logic
Model-Based
Testing
generates
multiple test
cases
Generating
one test case
Executing the
test case
Executing
test cases

27. Model example 1: test case

28. Model example 2: test logic

29. 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
Return on investment: Elektrobit
 About 10 times faster with modeling
 Set-up time estimation:
– 2 weeks for the first version, +1 week to make it better
 Other benefits:
– Test coverage dramatically increase
– Easy test configuration

30. Economics of DSM
 Repetition:
– # of product variants
– # of similar features
– # of developers
– ”outsourcing” to
domain experts
 Investment:
– Effort needed
to implement
DSLs
0
10
20
30
40
50
60
70
80
90
100
0 1 2 3 4 5 6
Repetition
Cost
Current DSM

31. DSM Solution Development Time
Man days

32. Concepts Symbols
GeneratorsRules
1 2 3 4
Steps for implementing DSM

33. Summary
 Domain-Specific Modeling languages provide:
– Better productivity
– Quality improvements
– Easier use and introduction of new developers
 MetaEdit+ makes moving to DSLs feasible
– Expert can focus on language design, not on creating tooling
– Models update and work when languages changes
 Creation of languages does not take much time!

34. More details on the cases
 Kelly, S., Tolvanen, J.-P., Domain-Specific Modeling: Enabling
Full Code Generation, Wiley, 2008. http://dsmbook.com
 Kärnä, J., et al. Evaluating the Use of Domain-Specific Modeling
in Practice, Proceedings of the 9th Workshop on Domain-
Specific Modeling, HSE Print, B-108, 2009.
 Puolitaival, O.-P., Home Automation DSL case, Code Generation
Conference, 2011
 Puolitaival, O.-P., Kanstren, T., Rytky, V.-P., Saarela, A.,
Utilizing Domain-Specific Modeling for Software Testing,
Proceedings of VALID, October 2011
 Safa, L., The Making Of User-Interface Designer, A Proprietary
DSM Tool, Proceedings of the 7th Workshop on Domain-Specific
Modeling, Technical Reports, TR-38, University of Jyväskylä,
2007

35. For more cases, customer stories, testimonials
visit www.metacase.com
Thank You!