外部技术 DSL 的示例
我们正在评估在描述、建模和生成多平台应用程序的过程中可以在多大程度上使用外部 DSL。我个人没有看到很多应用程序来描述企业域，因为就我而言，大多数应用程序都很简单。密集的测试驱动开发似乎更适合剩下的任务。
在技术方面还存在其他挑战，我想用可靠的策略来应对。由于可能存在多个系统，因此我想尽可能详细地描述接口。
我发现一些 ORM 框架具有来自某些元语言的代码/模式转换器（Doctrine 看起来不错），以及 Markus Voelter 的几篇论文（“架构作为一种语言”（特别是）。
您还知道其他有趣的、甚至可能相互矛盾的例子吗？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
因此，通过多平台，我假设您的意思是“必须在多个异构系统上运行”。
您将面临指定和实现的问题：
如果您遵循 Voelter 的论文，您将需要一些东西来描述“体系结构”，即
每个部分的元素如何组合以实现整体。
如果您的所有平台都没有由一套现成的技术提供服务
（例如，.J2EE 或类似的），并且它具有很长的生命周期，您可能需要单独的规范
这些工件来自其实现。
（如果你幸运的话，你可以选择一个普通的
Java、C# 或 C++ 等语言用于业务逻辑并作为其他 DSL 的编译目标。如果你这样做，当然会倾向于用一种语言来编写整个事情；如果这样做，您可能会在下一次技术更新时陷入困境，并且在该应用程序的生命周期中可能会遇到几次技术更新）。
为了将规范和实现分开，您需要一组 DSL 来描述这些规范，并为每个平台提供一组相应的 DSL 编译器，以便所有部分组成
。这意味着您可能无法获得来自不同来源的 DSL；没有理由相信他们生成的结果是正确的。因此，您可能会陷入定义这些和实现翻译的困境。这不是一件容易的事。
但是，构建长期存在的多平台应用程序也不是。
有许多工具可以用来实现此类 DSL。另一个答案提出了 EBNF，我认为需要它来描述 DSL，以及解析器生成器，我认为这是必要的但还不够。
更好的实现机制是通用程序转换工具：
所有这三个工具都可以让您为各种 DSL 定义自己的 EBNF 语法，并构建转换以将它们映射到您的各种多个平台。要使用这些，您通常会
需要构成多个平台的目标语言的 EBNF 描述，因为
这些系统的工作原理是使用抽象语法树转换方法将 DSL 中的构造转换为目标语言中的构造。其中每一个都有不同程度的现成目标语言描述可用。 （我们与 DMS 努力合作，以确保我们很好地涵盖了常用的目标语言）。
所有这些都不会让您脱离测试。如果没有其他情况，您至少需要在规范级别编写测试，以便测试的词汇/实现不依赖于特定平台。测试必须以某种方式编译下来才能运行；如果它们是用 DSL 术语编码的，并且您有 DSL 编译器，则可以将它们编译为（多个）实现并运行以验证在 DSL 中编码的应用程序。
编辑 10/31/2011：OP 暗示他想要别的东西；在阅读这个问题时，似乎有人关注架构规范的 DSL（Voelter 的论文）。我能来到这里的最接近的是关于模块互连语言（MIL）的论文调查；其中每一个都是 DSL，并且需要类似上面的开发。 MIL 还需要更多；您需要一种方法来执行其规则，否则您在其中编写的任何内容都将被程序员忽略。您也可以通过阅读 MIL 和组成软件的各种源代码，使用各种转换系统来实施强制。理想情况下，您应该阅读代码的 MIL 和规范（假设代码生成器生成符合规范的代码）。
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).
我不太清楚外部 DSL 的“矛盾示例”是什么意思。
以下是我最喜欢的一些示例：
，我希望这就是您正在寻找的内容。
I'm not exactly sure what you mean by 'contradicting examples' of external DSLs.
Here are some of my favorite examples:
I hope that's what you're looking for.