1. 1 17 October 2005 San Diego, CA The 5th OOPSLA Workshop on Domain-Specific Modeling Group reports

2. The 5th OOPSLA workshop on Domain-Specific Modeling (DSM’05) 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. 3 Group 1 DSM Foundations Group Group 1: Peter van Emde Boas, Ben Denckla, Jonathan Sprinkle

4. The 5th OOPSLA workshop on Domain-Specific Modeling (DSM’05) 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. The 5th OOPSLA workshop on Domain-Specific Modeling (DSM’05) 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. The 5th OOPSLA workshop on Domain-Specific Modeling (DSM’05) 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. The 5th OOPSLA workshop on Domain-Specific Modeling (DSM’05) 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. The 5th OOPSLA workshop on Domain-Specific Modeling (DSM’05) 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. The 5th OOPSLA workshop on Domain-Specific Modeling (DSM’05) 9 Conclusions IEEE Software0 CACM3

10. 10 Group 2.1 DSM experiences and cases

11. The 5th OOPSLA workshop on Domain-Specific Modeling (DSM’05) 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. The 5th OOPSLA workshop on Domain-Specific Modeling (DSM’05) 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. The 5th OOPSLA workshop on Domain-Specific Modeling (DSM’05) 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. The 5th OOPSLA workshop on Domain-Specific Modeling (DSM’05) 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. 15 Group 2.2 DSM 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. The 5th OOPSLA workshop on Domain-Specific Modeling (DSM’05) 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. The 5th OOPSLA workshop on Domain-Specific Modeling (DSM’05) 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?