When and How to Develop Domain-Specific Languages Presenter: Vítor De Araújo

When and How to Develop
Domain-Specific Languages
CMP586 – Trends in Software Engineering
Presenter: Vítor De Araújo
About the article
Authors
●
Marjan Mernik
–
●
Jan Heering
–
●
CWI, Netherlands
Anthony M. Sloane
–
●
University of Maribor, Slovenia
Macquarie University, Australia
Published in 2005
24/06/14
vbuaraujo@inf.ufrgs.br
2/26
About the article
Organization
●
Section 1: Introduction
–
●
Section 2: DSL patterns
–
●
Common patterns in the creation of DSLs
Section 3: DSL development support
–
●
Characterizes DSLs and what they are good for
Tools for helping in design and implementation of DSLs
Section 4: Conclusion and open problems
24/06/14
vbuaraujo@inf.ufrgs.br
3/26
Section 1. Introduction
General
●
●
DSLs trade generality for expressiveness in a limited domain
–
Expressiveness, maintenance costs
–
Opens up development to larger group of developers (domain
experts)
Hard to quantify the productivity gains of using DSLs
–
Has been done for specific DSLs before
–
In this article we will keep to qualitative analysis
●
Application domain: vague concept
●
Contrast to application libraries
–
notations, better abstractions, analysis/optimization
–
however, libraries are often more cost-effective
24/06/14
vbuaraujo@inf.ufrgs.br
4/26
Section 1. Introduction
Executability of DSLs
●
DSLs are executable to varying extents
–
●
Excel, HTML > app. generator > BNF > Non-executable
Some references don't consider non-executable languages as
DSLs
24/06/14
vbuaraujo@inf.ufrgs.br
5/26
Section 1. Introduction
DSLs as enablers of reuse
●
Many reusable artifacts
–
Language grammars
–
Source code
–
Domain abstractions
–
Software designs
–
Notations used by domain experts
24/06/14
vbuaraujo@inf.ufrgs.br
6/26
Section 1. Introduction
Scope of this article
●
●
DSL development does not come for free
–
Requires both domain and language development expertise
–
More variation than found in GPLs
–
Training material, standardization, support, maintenance
Need of a DSL may become clear only after large portion of
software was written
–
24/06/14
Software reengineering / evolution
vbuaraujo@inf.ufrgs.br
7/26
Section 2. DSL patterns
Pattern classification
●
Phases of DSL development
–
Decision (perhaps we need a DSL)
–
Analysis (identify domain, collect domain knowledge)
–
Design (how will the concepts be expressed in language)
–
Implementation (exactly what it sounds like)
–
Deployment (out of the scope of this article)
●
Not necessarily a sequential process
●
Common patterns in each of these phases
24/06/14
vbuaraujo@inf.ufrgs.br
8/26
Section 2. DSL patterns
Decision
●
Does it pay to develop a DSL?
●
Short-term considerations, lack of expertise → postponement
●
Using existing DSL may be easier
●
–
But hard to find available suitable DSLs
–
Adapting unknown DSL may be considered too risky
General concerns which lead to decision for DSL
–
improved software economics
–
Enabling development by users with less programming
expertise
24/06/14
vbuaraujo@inf.ufrgs.br
9/26
Section 2. DSL patterns
Decision: common motivational patterns
●
●
●
Notation (new or existing)
–
Transform visual to textual notation
–
User-friendly notation to existing API
AVOPT (Analysis, Verification, Optimization, Parallelism,
Transformation)
–
Often overlaps with other patterns
–
Task automation
–
Product line (share common architecture)
–
Data structure definition and traversal
Interaction
–
24/06/14
When menus are not flexible enough
vbuaraujo@inf.ufrgs.br
10/26
Section 2. DSL patterns
Analysis
●
Domain is identified and domain knowledge gathered
●
Input from various sources
●
–
Domain experts
–
Technical documents
–
Existing general-purpose-language code
Output
–
●
Terminology and semantics in abstract form
Link with knowledge engineering
24/06/14
vbuaraujo@inf.ufrgs.br
11/26
Section 2. DSL patterns
Analysis
●
Most often informal
●
Sometimes domain analysis methodologies are used
–
●
DARE, DSSA, FAST, FODA, etc.
Formal analysis produces a domain model
–
Domain definition (scope)
–
Domain terminology (vocabulary, ontology)
–
Descriptions of domain concepts
–
Feature models (commonalities, variabilities, dependencies)
24/06/14
vbuaraujo@inf.ufrgs.br
12/26
Section 2. DSL patterns
Analysis
●
●
Analysis → DSL: no clear guidelines, but we have some:
–
Variabilities: information to specify an instance of the system
–
Commonalities: execution model and primitives
–
Terminology and concepts: DSL constructions
On the basis of a single domain analysis, many DSLs may be
developed
–
●
But all share important characteristics found in the feature
model
An introduction to FODA and FAST follows (which we'll skip)
24/06/14
vbuaraujo@inf.ufrgs.br
13/26
Section 2. DSL patterns
Design
●
Approaches can be characterized along two dimensions
–
Relationship between DSL an existing languages
–
Language exploitation
● Language invention
Formality of the design description
●
Informal
● Formal
(and everything in between)
●
●
24/06/14
vbuaraujo@inf.ufrgs.br
14/26
Section 2. DSL patterns
Design: with respect to existing languages
●
●
Easiest to base the DSL on an existing language
–
Easier to implement
–
Easier to learn (assuming users know the existing language)
Three patterns
–
Piggyback
–
Specialization
–
Extension
24/06/14
vbuaraujo@inf.ufrgs.br
15/26
Section 2. DSL patterns
Design: with respect to existing languages
●
Alternatively, we can do it from scratch
–
●
Can be extremely difficult and hard to characterize
One must keep in mind the special character of DSLs
–
Not your run-of-the-mill general-purpose language
–
Users are not necessarily programmers
–
Adopt notations/concepts from domain, rather than trying to
"improve" them (e.g., over-generalize)
–
Design only what is necessary
24/06/14
vbuaraujo@inf.ufrgs.br
16/26
Section 2. DSL patterns
Design: with respect to formality
●
Informal design
–
●
Natural language, examples of illustrative DSL programs
Formal design
–
Syntax:
–
regular expressions
● grammars
Semantics:
●
●
●
●
24/06/14
attribute grammars
rewrite systems
abstract state machines
vbuaraujo@inf.ufrgs.br
17/26
Section 2. DSL patterns
Design: with respect to formality
●
Informal design is probably easier for most people
●
But some formality can go a long way
–
Highlight problems before implementation
–
Implementation may be partially automated
●
●
e.g., parser generators
Often:
–
Language invention ~ formal design
–
Language exploitation ~ informal design
24/06/14
vbuaraujo@inf.ufrgs.br
18/26
Section 2. DSL patterns
Implementation
●
●
Some DSL-specific techniques have no useful counterpart in
GPLs
Patterns
–
Interpreter
–
Compiler / application generator
–
Preprocessor (macros, source-to-source)
–
Embedding
–
Extensible compiler/interpreter
–
Commercial Off-The-Shelf (COTS)
–
Hybrid
24/06/14
vbuaraujo@inf.ufrgs.br
19/26
Section 2. DSL patterns
Implementation: trade-offs
●
●
Interpreter/compiler
–
Full syntactic flexibility (closer to domain notations)
–
Good error reporting is possible
–
AVOPT is possible
On the other hand...
–
Requires more effort
–
Design from scratch: greater risk of incoherent design
24/06/14
vbuaraujo@inf.ufrgs.br
20/26
Section 2. DSL patterns
Implementation: trade-offs
●
●
Embedding
–
Requires less effort
–
Language is often more powerful because host language
constructs are available
–
Easier to learn for users familiar with the host language
On the other hand...
–
Syntax is not optimal (constrained by host language)
–
Overloading may lead to confusion
–
Bad error reporting (host-language rather than DSL-specific)
24/06/14
vbuaraujo@inf.ufrgs.br
21/26
Section 3. DSL development support
Design and implementation support
●
Language development systems/toolkit
–
●
●
Generated tools may vary
–
Consistency checker and interpreter
–
Full-blown IDE with syntax-directed editor, analysis, etc.
Even non-executable languages may benefit from tools
–
●
Generate tools from language descriptions
e.g., syntax-directed editor, pretty-printing, checking
Some tools are methodology-agnostic, some require specific
methodology
24/06/14
vbuaraujo@inf.ufrgs.br
22/26
Section 3. DSL development support
Analysis support
●
Separate frameworks and tools for domain analysis
–
Collaborative development of semantic models
–
Capture of domain information from experts
–
Structured editors and hypertext/media engine
–
Ontology editors
–
etc.
24/06/14
vbuaraujo@inf.ufrgs.br
23/26
Section 4. Conclusions and open problems
Conclusions
●
DSLs will never be a solution to all sw. engineering problems
–
●
However, currently application unduly limited by lack of
knowledge available to potential DSL developers
We distinguish 5 phases of DSL development
–
decision, analysis, design, implementation, [deployment]
–
We identify patterns to help guide this process
●
We have seen toolkits to help in DSL development
●
However, there are gaps which could use further work
24/06/14
vbuaraujo@inf.ufrgs.br
24/26
Section 4. Conclusions and open problems
Open problems
●
●
●
Decision: Can be aided by computers?
Analysis: Integration between domain analysis tools and DSL
design/implementation tools
Design and implementation: Can be made easier for people not
versed in language development? E.g.:
–
building blocks for DSL construction
–
combining existing GPLs and DSLs
–
pattern-aware development support
–
description by example
●
Embedding: More support from GPLs
●
Estimation: Can we quantify costs and benefits of DSLs?
24/06/14
vbuaraujo@inf.ufrgs.br
25/26
Thanks.
Questions?
Vítor De Araújo
vbuaraujo@inf.ufrgs.br