Domain Specific Languages and Agile Development
Workshop Results
There were 22 participants, all helping to make this an
interesting workshop and great fun - many thanks to all of you! If you have any
photos, do send them along to us and we'll add them here:
- Steve & Alan
Intro talk: DSLs and Agile (ACW)
- Domain
Specific Languages are languages that specialize in a particular area of
interest – examples:
- GUI
designers – UI design used to be 40% of a typical project’s effort
- SQL
– similar for database storage
- Your
language of your particular problem domain
- DSLs
are a pattern for scaling up agile development methods. Once the DSL and its
execution framework are created,
-
Prototypes
of (aspects of) your system can be generated very rapidly, and customer feedback
obtained
-
Each
language only covers one aspect, and isn’t mature – so developing complete
systems usually takes longer
-
The
DSL is comprehensible by the customer, and focuses on domain issues rather than
implementation
-
The
implementation concerns are packaged in the execution framework
-
DSLs
make it easier to discuss the spec – not just with the user: having the
vocabulary helps you think about the problem
-
DSLs:
-
can
be textual or graphical or both
-
focus
on a particular aspect and aim to raise abstraction level there
-
You
need to develop:
-
Language
that talks in the terms of the domain
-
Translators
and/or framework that captures the best practices and patterns of implementation
-
Because
it’s within a restricted domain, the language can focus on requirements and
code can be generated for that aspect – can’t be done for general cases (=
failure of most old case tools)
-
DSLs
are a branch of Product Line Development: use them when you are
-
Developing
a range of products with much similarity between some parts
-
Developing
a one-off where requirements are unstable in a particular area
-
Generally
a language will only cover a small aspect of your system; so you need to think
about
-
how
models written in that language compose with others in intersecting domains
-
minimizing
such intersections where you can
Demo of MetaEdit+ (Steven Kelly, MetaCase)
-
MetaEdit+
is a toolset that helps you create and use graphical languages and create processing tools
for them
-
SK
demonstrated a language, created with MetaEdit+, that generated wristwatch
software
-
He
also showed templates from which software was generated
Sample MetaCase successes include:
-
Language
for describing insurance policies, and software that generates them
-
Phone
voice menu system – language defines menu, from which config file for the
voice generator is created
-
Applications
in mobile phones
-
Call
processing
-
Etc
Three DSM tools vendors were represented in the
workshop, all have evaluation versions:
- MetaCase
–
MetaEdit+ for graphical DSL authoring and use (download
evaluation of MetaEdit+ 4.0)
-
Microsoft
–
Visual Studio DSL Tools for graphical DSL authoring
and use (beta available on DVD pack
included with conference material)
-
Xactium
– XMF/Mosaic for graphical or textual DSL authoring and use (evaluation version of pre-release available on web site)
Topics of interest
We identified a variety of topics of interest, some of
which we looked at in more detail.
- What are DSLs for?
- Talking
to domain experts?
- Defining
tests?
- Generating
code?
- Validating
code?
- Applicability
- What
is the range of applicability of a DSL?
- What
is the business case?
- DSLs
for Test Cases – DSLs make acceptance tests more accessible to users
- Designing DSLs
- How
to collect requirements for a Domain Specific Language? Who are the
stakeholders?
- Process
for designing a DSL
- Composing
languages from fragments; reusing language specifications
- Scoping
a DSL
- Separating
concerns
- Ensuring
semantic consistency
- Creating
the platform or evolving it from existing code
- Handling
complexity
- Textual and graphical DSLs
- Relative
merits
- Integrating
different styles
- Using DSLs
- Generating
code and other artifacts
- Composing
and synchronizing models in different DSLs
- Escapes/hooks
to other languages including base PL
- Debugging
in the DSL
- Debugging
generators
- Understanding
generated code
- Performance
- Managing DSLs
- Migrating
models between language versions
- Developer
roles
- Version
management for object models
- Tools
- For
developing a DSL
- For
developing a framework
Notes from discussions
How to develop a DSL
Three inputs:
-
Variability
in the developed software
-
Which
bits vary between delivered instances or across the life of the system? –
These are the aspects that need to be at least separated out from the more
constant stuff; and are good candidates for generating or generalizing and
driving from a DSL.
-
Ontology/vocabulary
of the domain (as seen in user stories)
-
Make
a model of the whole domain. Separate out the variable bits as derived from the
software variability: this gives you the concepts you want to express in your
language.
-
Existing
user notations
-
Look
for drawings on whiteboards. These notations are the concrete syntax in which
you clothe the DSL.
See also “Feature Modeling”.
DSLs for Acceptance Testing
-
FIT is a DSL template
-
FIT must be specialised for a given application
-
DSL is a good way to define acceptance tests
-
A graphical DSL would allow the definition of more complex tests
-
Is
that necessary?
-
Could
testers use it?
-
A textual DSL requires development support to simplify (refactor)
the test
Applicability of DSLs
We looked at the contingency factors that help decide
whether or not DSM is appropriate in a given situation:
Positive points:
-
Have developed 2-3 similar chunks
-
Need to talk to domain experts
-
Support tools available
-
Availability of suitable people
Negative points:
-
One-off chunk
-
No prospect of change
-
Just trendy
Managing Complexity in language design
Dimensions of complexity:
-
Number of literals/ constructs in the abstract syntax
-
Number of recurring patterns
-
Size of statespace of language
-
Overlapping constructs
-
Diversity of languages
-
Knowledge base (is in the framework or the language)
Solutions:
-
Separate
concerns – different languages for different purposes – eg GUI editor for
wizard pages, flow language for wizard sequence
-
Minimize
inevitable couplings
-
Coupling
by runtime events; or by weaving at generation time
-
Consider
2-way synchronization at overlaps
-
Some
unorthogonality inevitable if there are existing languages
-
Need
escapes and hooks to base PL
-
Accept
that DSL does only X% <<100% -- less if the domain is more volatile
-
Need
a method for removing old stuff as language evolves
-
Restrain
human tendency to elaborate language
-
Managing
old instances of language:
-
Preserve
old types but remove “new” on them
-
Provide
auto-translation to new types
-
Decoupled
small reusable language components with common infrastructure --- templates
-
Factor
out patterns first
-
Constraints
and exception handling, coupling of constraints used almost always together
-
Need
to converge at abstract syntax or semantic level
-
Smart
and adaptive tools