1 / 17

The 5th OOPSLA Workshop on Domain - Specific Modeling Group reports

The 5th OOPSLA Workshop on Domain-Specific Modeling (DSM) brought together experts to discuss critical issues and experiences in the field, focusing on foundational concepts, tool development, and effective language design. Participants explored the dichotomy between generalization and specificity in model creation and emphasized education and communication within the community. Actionable outcomes included the need for a rigorous DSM textbook, improved vocabulary, and successful case studies. Challenges identified included ensuring model synchronization, addressing complexity, and enhancing user tools in varying industry domains.

vilhelm
Télécharger la présentation

The 5th OOPSLA Workshop on Domain - Specific Modeling Group reports

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. The 5th OOPSLA Workshop on Domain-Specific ModelingGroup reports 17 October 2005 San Diego, CA

  2. Working groups • Focus on a specific topic • Parallel groups (experiences and cases group split into two smaller groups) 1. DSM foundation 2.1 Experiences and cases 2.2 Experiences and cases • The goal of those groups is to • Discuss current application concerns/questions? • Report topics where different opinions exist • Identify research topics • Groups present their results for discussion

  3. Group 1DSM Foundations Group Group 1: Peter van Emde Boas, Ben Denckla, Jonathan Sprinkle

  4. Thoughts: • Formal specifications are great, but eventually, the tool/language must be re-expressed in natural language for general consumption • Both necessary, but publish the right kind to right audience • DSM has this advantage: presenting a “correct” language at first look, but still requires user’s manual as well as provability manual

  5. Thoughts: • On provability • Tool users and industry (e.g., airlines) have confidence in compilers and do verification on source code. • When developing code generators, do we/they verify the outputted source code, or the code generator? Why/why not? • How can we bring the same rigor and confidence to DSM “compilers” which is enjoyed by, say, C++ compilers?

  6. Thoughts: • On design choices • That classic choice of being general or being specific. Do we ignore complex domain concepts to make our language easier, or have general-purpose concepts which can create complex objects? • E.g., feedback loops being/not being allowed in block diagram editors

  7. On interests and resources • More, more, more semantics! Less, less, less syntax! • Create and dispense education plans and disperse them! • Teach DSM from perspective of language history, leveraging denotational/operational, compiler theory, and all sort of existing body of work—try to reduce ad hoc design nature • New domains to explore/refine • Communicating processes • Gaming (computer vs. human) from interface and intelligence aspects • More experience/work on heterogeneous systems • Gluing multiple DSMs together, with confidence in how they will work • Are there control flows we are missing somewhere??

  8. What would we like to see in: • 1 year from now • A DSM textbook for graduate study (rigorous disciplinary book) • Experience papers on code generation projects that have failed, and why that happened (lessens for the rest of us mortals) • A better common vocabulary exposed to the rest of the world somehow • 5 years from now • Killer application that proves/shows off DSM as viable in the large • Lots of industrial Kool-Aid drinking • NOT want to see, or be seen • Syntax battles • Wheel™ 2.0 Just as round, and shiny as ever!

  9. Conclusions • IEEE Software 0 • CACM 3

  10. Group 2.1DSM experiences and cases

  11. (Meta-)Modeling Tools • Semantics vs. abstract syntax vs. concrete syntax vs. rules • Declarative is best! • But requires most experience and hard work by meta-tool developer • Didn’t discuss other necessary features: multi-user, nice editors, no bugs, support… • “State of the art” (present today) • GME • Declarative for abstract syntax • Code for concrete syntax • OCL pseudo-code for rules • MetaEdit+ • Declarative for abstract syntax & rules • Symbol editor for concrete syntax • Procedural non-programming language for checks • What are current research questions? • Model(er) vs. metamodel(er) • Best support if we accept the needs for each are somewhat different • Version control for models • Graphical diff • Do we need fork and merge, or is that an artifact of text langs & CVS

  12. Generators • “State of the art” (present today) • CodeWorker • Declarative specification of parsers • Can insert imperative actions after • Template-based programming DSL (parameterized functions, variables) • GME: non-domain-specific API to access models • Hardcode generators by hand in C++ or Java • Maybe make C++ program to allow CodeWorker to read models? • MetaEdit+ • Non-programming stack-based DSL for turning models into code • Often made to be template-based, modularised by domain concepts • Areas of interest • Keep code generator in synch with metamodel changes • Similar to keeping models in synch • Currently not much, best is to cope with name changes • Higher level of abstraction for generator in GME • Debug generators, step through, know where output came from

  13. Business Impacts • Some industry domains already made the leap • Microprocessors & VHDL/Verilog • ER (e.g. in ERWin) & SQL • LabView • What do we need for others? • Pain • Complexity: bugs, long training • Slowness: missed deadlines / revenue • Used to graphical representations, not against them? • Product lines • Are the tools sufficient for now? • Certainly could learn more from each other • But need someone to fund development

  14. Conclusions • Let’s do something together before next year! • Tool makers: • Talk to each other! • Academics: • Read & understand about existing research! (even old stuff) • Try out existing tools and approaches, and only then… • Invent something new and daring! • Companies: • Try out a tool to make a prototype / pilot project!

  15. Group 2.2DSM experiences and cases Group members: David Foti, Jürgen Jung, Arturo Sanchez, Abhijit Sancdev, Steve Dunham, Michael Cohen, Vikram Bhanot, Angel Roman, Barry Kim, Juha-Pekka Tolvanen

  16. Impact and business case • 9 out of 10 plans to create DSMs in coming 1-2 years • Why? • Don’t want to do it again and again and… • Want to hide implementation details from others • Want to guide the use of frameworks and other abstractions(for early error detection, standardize code etc.) • Have enough repetition • Need for handbook for DSM creation • We want to see more cases • Management must understand and give resources • DSM needs to be refined and maintained

  17. Generators and tooling • Generator development guidelines • Make code similar domain experts write it • Generate test cases • Trace code to requirements • Provide code coverage • Tool issues • Tools should minimize the cost of creating DSMs • Debugging the generated code (tracing from code to models) • Managing changes in the metamodel • Topic, but not an issue? • What tools for creating and using DSMs are available?

More Related