1 / 11

Collected Experiences of Defining Domain-Specific Modeling Languages

Collected Experiences of Defining Domain-Specific Modeling Languages. 10/24/2004 Steven Kelly MetaCase. 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

kristen-haynes
Download Presentation

Collected Experiences of Defining Domain-Specific Modeling Languages

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Collected Experiences of Defining Domain-Specific Modeling Languages 10/24/2004 Steven Kelly 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

  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: • Domain expert’s or developer’s concepts • Generation output • Look and feel of the system built • Variability space

  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

  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 • As opposed to generic 3GL Internet telephony/CPL

  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 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

  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

  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

  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

More Related