Collected Experiences of Defining
Domain-Specific Modeling Languages
10/24/2004
Steven Kelly
MetaCase
© 2004 MetaCase
1
Research Method and Data
 Post hoc case analysis of cases of DSM creation
– Interviews and discussions
– Resulting DSM
 23 industrial cases of DSM
– First hand experience of authors
 Different problem domains
– Embedded UIs, web apps, GIS, telecom services
 Different solution domains
– Assembler, C, XML, J2EE
 Different levels of maturity
– From established stable domains to bleeding edge
 All aiming at full generation from models
© 2004 MetaCase
2
Approaches to identify concepts
 “How do I start to do DSM?”
– Hard problem for DSM customers
– Analyse cases to find good toolbox of approaches
 Initial analysis suggested four approaches:
1.
2.
3.
4.
Domain expert’s or developer’s concepts
Generation output
Look and feel of the system built
Variability space
© 2004 MetaCase
3
Problem domain
Solution domain/ generation target
Approach
Telecom services
Configuration scripts
1
Insurance products
J2EE
1
Business processes
Rule engine language
1
Industrial automation
3 GL
1, (2)
Platform installation
XML
1, (2)
Medical device configuration
XML
1, (2)
Machine control
3 GL
1, 2
Call processing
CPL
2, (1)
Geographic Information System
3 GL, propriety rule language, data structures
2
SIM card profiles
Configuration scripts and parameters
2
Phone switch services
CPL, Voice XML, 3 GL
2, (3)
eCommerce marketplaces
J2EE, XML
2, (3)
SIM card applications
3 GL
3
Applications in microcontroller
8-bit assembler
3
Household appliance features
3 GL
3
Smartphone UI applications
Scripting language
3
ERP configuration
3 GL
3, 4
ERP configuration
3 GL
3, 4
Handheld device applications
3 GL
3, 4
Phone UI applications
C
4, (3)
Phone UI applications
C++
4, (3)
Phone UI applications
C
4, (3)
Phone UI applications
C++
4, (3)
© 2004 MetaCase
4
1. Domain expert’s concepts






Concepts from domain
Mostly made without help
Simple MoC
Simple code generation
OK in established domain
Usable by non-coders
Insurance products/J2EE
© 2004 MetaCase
5
2. Generation output
 Modeling constructs come from
code artefacts
 Static parts are easy
– Data structures
– Core XML elements
 Dynamic behaviour hard
– Full programming language?
– Need domain framework
 Danger: low level of abstraction
– Little productivity gain
 But works well with DSL or XML
Internet telephony/CPL
– As opposed to generic 3GL
© 2004 MetaCase
6
3. Look and feel of the system
 Best for physical end product
– UI on PC, embedded, speech
 Often state machine MoC
– Also data & control flow
– Power of relationships
 Visible domain concepts
– Easy to identify
– High level of abstraction
 Domain framework hides code
– Don’t write code in models…
– …unless you really have to!
 Generators considered easy
© 2004 MetaCase
Smartphone apps/Python
7
4. Variability space
 Language concepts capture variability space
 Modeler makes variant choices
– Composition, relationships, values
 Infinite variability space (Czarnecki)
– Not just feature tree: unbounded product family
 Used to create hardest DSM languages
– Handled most complex domains, kept modeling simple
 Static variance easy, dynamic harder
 Consultant should be good coder
 Customer expert in his domain and code
– Consultant should also be able to program
 Predict future variability  high level of abstraction
© 2004 MetaCase
8
Evaluation of the Categorization
 Only certain pairs of approaches occurred
 Hierarchy of approaches
– From less to more experienced DSM practitioners
 1. Domain expert’s concepts - can be dropped
 2. Generation output
– Generic/ad hoc language not so good
– Established DSL good
 3. Look and feel: common, easy, true DSM
 4. Variability space: adds power to handle complexity
– Found in very different domains
 Best results combined 3 and 4
– 3 gives concepts, 4 gives relationships and properties
© 2004 MetaCase
9
Conclusions and Further Work
 DSM matured: can analyse over 20 real cases
– Confirmation of DSM productivity improvements
 Several approaches, mostly need more than one
– 2. Generation output only for DSL
– 3. Look and feel whenever possible
– 4. Variability space where necessary
 Language creation actually not so difficult
– Because only have to satisfy limited group of users
 Need more cases
– Different consultants, different tools
– Different problem and solution domains
© 2004 MetaCase
10
Thank you!
Question and comments?
MetaCase
Ylistönmäentie 31
FIN - 40500 Jyväskylä, Finland
Phone +358 14 4451 400, Fax +358 14 4451 405
www.metacase.com
© 2004 MetaCase
11
Descargar

Analysis of Competing Tools for Domain