Ruby Dsl (Domain Specific Language) Repositories, Examples

Is there any DSL (Domain Specific Language) in order to hold contracts?

If you are interested in code generation you should definitely look into the Eclipse Modelling Framework (EMF), if you haven't already.

In general, creating abstract descriptions (aka models), in the context of software engineering, can be referred to as model-driven engineering (MDE). A quick google search can give you enough material to get you started.

I think there are a ton of useful tools out there that people have created over the years that are not well known in industrial circles. By my estimation, that is mainly due to them being more 'academic' in nature and also their sometimes strong coupling with eclipse, which has fallen out of favour in recent years. That being said, they might be of interest to you so it is worth exploring.

Good luck!

DSLs(Domain Specific Programming Languages) implemented using different GPLs(General Purpose Programming Languages)

take a look at boost.spirit2 to find a very complex DSL in a mainstream language. Otherwise you could look at any dialect of lisp which makes it very easy to write DSLs and so you will find lots of them.

Domain Specific Language resources

The architects of the DSL Tools team wrote a book, Domain-Specific Development with Visual Studio DSL Tools. The book's website has some other links and resources.

Examples for external technical DSL

So by Multiplatform I assume you mean "has to run on multiple heterogenous systems".

You'll face the problem of specifying and implementing:

• Business logic
• User Interface
• Data Models
• Interapplication communication to handle distribution

If you follow Voelter's paper, you'll want something to describe the "architecture", namely
how the elements of each these parts are composed to achieve the whole.

If all of your platforms are not served by a single set of off-the-shelf technologies
(e.g,. J2EE or some such), and it has a long lifetime, you may want to separate the specification
of these artifacts from their implementation.

(If you are lucky, you can choose a common
language such as Java, C# or C++ for the business logic and as a compilation target for the other DSLs. If you do this, of course the temptation will be to code the whole thing in that one language; if you do, you'll likely get stuck at the next technology refresh, and there are likely to be several over the course of the lifetime of this application).

To keep specification and implementation separate, you'll want a a set of DSLs to describe those specifications, and a corresponding set of DSL compilers for each of the platforms, such that all the parts compose
. That means you likely can't the DSLs from disparate sources; there's no reason to believe their generated results compose. So you're likely stuck defining these and the implementation translations. That's not an easy task.
But then, neither is building a long-lived multiplatform application.

There are a number of tools that one can use to implement such DSLs. Another answers proposes EBNF, which I think is needed to describe the DSLs, and parser generators, which I think are necessary but hardly sufficient.

Better implementation machinery are general purpose Program Transformation tools:

• TXL
• Stratego
• Our DMS Software Reengineering Toolkit.

All three of these will let you define your own EBNF syntax for the various DSLs, and build transformations to map them to you various multiple platforms. To use these, you'll typically
need EBNF descriptions of the target langauges that make up your multiple platforms, because
these systems work by transforming constructs in your DSL to constructs in the target langauge(s) by use abstract-syntax-tree transformation methods. Each of these has varying degress of off-the-shelf target language descriptions available. (We work hard with DMS to make sure we've covered the commonly used target languages well).

None of this will get you out of testing. You'll need to at least write tests at the specification level, if nothing else so the the vocabulary/implementation of the tests are not tied to a specific platform. The tests have to somehow be compiled down to run; if they are coded in DSL terms and you have DSL compilers, they can be compiled to (multiple) implementations and run to validate the application coded in the DSLs.

EDIT 10/31/2011: OP hints he wants something else; on reading the question, there seems to be some focus on DSLs for architecture specification (Voelter's paper). The closest I can come here is a survey of papers on Module Interconnection Languages (MIL); each of these is a DSL and requires something like the above development. More is required with a MIL; you need a way to enforce its rules or whatever you write in it will be ignored by the programmers. You can use the various transformation systems to implement enforcement, too, by reading the MIL and the various source codes making up the software. Ideally, you'd read the MIL and the specifications of the code (assuming the code generators produce code that honor the specs).

---

Related Topics