© 2004 MetaCase 1 Collected Experiences of Defining Domain-Specific Modeling Languages 10/24/2004 Steven Kelly MetaCase

© 2004 MetaCase 2 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 3 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.Domain expert’s or developer’s concepts 2.Generation output 3.Look and feel of the system built 4.Variability space

© 2004 MetaCase 4 Problem domainSolution domain/ generation targetApproach Telecom servicesConfiguration scripts1 Insurance productsJ2EE1 Business processesRule engine language1 Industrial automation3 GL1, (2) Platform installationXML1, (2) Medical device configurationXML1, (2) Machine control3 GL1, 2 Call processingCPL2, (1) Geographic Information System3 GL, propriety rule language, data structures2 SIM card profilesConfiguration scripts and parameters2 Phone switch servicesCPL, Voice XML, 3 GL2, (3) eCommerce marketplacesJ2EE, XML2, (3) SIM card applications3 GL3 Applications in microcontroller8-bit assembler3 Household appliance features3 GL3 Smartphone UI applicationsScripting language3 ERP configuration3 GL3, 4 ERP configuration3 GL3, 4 Handheld device applications3 GL3, 4 Phone UI applicationsC4, (3) Phone UI applicationsC++4, (3) Phone UI applicationsC4, (3) Phone UI applicationsC++4, (3)

© 2004 MetaCase 5 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 6 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 –As opposed to generic 3GL Internet telephony/CPL

© 2004 MetaCase 7 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 Smartphone apps/Python

© 2004 MetaCase 8 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 9 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 10 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 11 Question and comments? MetaCase Ylistönmäentie 31 FIN Jyväskylä, Finland Phone , Fax Thank you!