StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>So by Multiplatform I assume you mean "has to run on multiple heterogenous systems".</p> <p>You'll face the problem of specifying and implementing:</p> <ul> <li>Business logic</li> <li>User Interface</li> <li>Data Models</li> <li>Interapplication communication to handle distribution</li> </ul> <p>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.</p> <p>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. </p> <p>(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).</p> <p>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.</p> <p>There are a number of tools that one can use to <em>implement</em> 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.</p> <p>Better implementation machinery are general purpose <a href="http://en.wikipedia.org/wiki/Program_transformation" rel="nofollow">Program Transformation tools</a>:</p> <ul> <li><a href="http://www.txl.ca" rel="nofollow">TXL</a></li> <li><a href="http://www.strategoxt.org" rel="nofollow">Stratego</a></li> <li>Our <a href="http://www.semanticdesigns.com/Products/DMS/DMSToolkit.html" rel="nofollow">DMS Software Reengineering Toolkit</a>.</li> </ul> <p>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 <em>target</em> 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).</p> <p>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.</p> <p>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 <a href="http://www.ics.uci.edu/~andre/ics223w2006/prietodiazneighbors.pdf" rel="nofollow">Module Interconnection Languages (MIL)</a>; each of these is a DSL and requires something like the above development. More is required with a MIL; you need a way to <em>enforce</em> 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 <em>specifications</em> of the code (assuming the code generators produce code that honor the specs).</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload