We are in the process of evaluating how far we can use external DSL’s in the process to describe, model and generate a multi Platform Application. I personally don’t see many applications to describe the Enterprise-Domain, since most of it, in my case, is simple. And intensive Test-Driven development seems to be a better fit for the remaining tasks.
On the technical side there are other challenges, wich I would like to counter with a solid strategy. Since there is the potential to have a multitude of systems , I would like to describe the interfaces as good as possible.
I found a few ORM-Frameworks that have code / shema converters from some meta lnaguages (Doctrine looks good), and a few papers from Markus Voelter (‘Architecture as a Language’ in particular).
Do You know any other interesting, maybe even contradicting examples?
So by Multiplatform I assume you mean “has to run on multiple heterogenous systems”.
You’ll face the problem of specifying and implementing:
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:
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).