Transcript Workshop - DSM Forum

The 5th OOPSLA Workshop on
Domain-Specific Modeling
Group reports
17 October 2005
San Diego, CA
1
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
The 5th OOPSLA workshop on Domain-Specific Modeling (DSM’05)
2
Group 1
DSM Foundations Group
Group 1:
Peter van Emde Boas, Ben Denckla,
Jonathan Sprinkle
3
Thoughts:
 Formal specifications are great, but
eventually, the tool/language must be reexpressed 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
The 5th OOPSLA workshop on Domain-Specific Modeling (DSM’05)
4
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?
The 5th OOPSLA workshop on Domain-Specific Modeling (DSM’05)
5
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
The 5th OOPSLA workshop on Domain-Specific Modeling (DSM’05)
6
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??
The 5th OOPSLA workshop on Domain-Specific Modeling (DSM’05)
7
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!
The 5th OOPSLA workshop on Domain-Specific Modeling (DSM’05)
8
Conclusions
 IEEE Software
 CACM
The 5th OOPSLA workshop on Domain-Specific Modeling (DSM’05)
0
3
9
Group 2.1
DSM experiences and cases
10
(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
The 5th OOPSLA workshop on Domain-Specific Modeling (DSM’05)
11
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
The 5th OOPSLA workshop on Domain-Specific Modeling (DSM’05)
12
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
The 5th OOPSLA workshop on Domain-Specific Modeling (DSM’05)
13
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!
The 5th OOPSLA workshop on Domain-Specific Modeling (DSM’05)
14
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
15
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
The 5th OOPSLA workshop on Domain-Specific Modeling (DSM’05)
16
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?
The 5th OOPSLA workshop on Domain-Specific Modeling (DSM’05)
17