external - 外部技术 DSL 示例

Question

我们正在评估在描述、建模和生成多平台应用程序的过程中，我们可以在多大程度上使用外部 DSL。我个人没有看到很多描述企业域的应用程序，因为在我的例子中，大多数应用程序都很简单。密集的测试驱动开发似乎更适合剩余的任务。

在技​​术方面还有其他挑战，我想用一个可靠的策略来应对。由于有可能拥有大量系统，因此我想尽可能好地描述接口(interface)。

我发现了一些 ORM 框架，它们具有来自某些元语言的代码/shema 转换器(Doctrine 看起来不错)，以及 Markus Voelter 的一些论文(特别是 'Architecture as a Language')。

你知道任何其他有趣的，甚至可能相互矛盾的例子吗？

Answer 1

因此，通过 Multiplatform，我假设您的意思是“必须在多个异构系统上运行”。

您将面临指定和实现的问题:

业务逻辑

用户界面

数据模型

处理分发的应用程序间通信

如果你关注 Voelter 的论文，你会想要一些东西来描述“架构”，即
这些部分的元素如何组合以实现整体。

如果您的所有平台都不是由一套现成的技术提供服务
(例如，J2EE 或类似的)，并且它的生命周期很长，您可能希望将规范分开
这些工件的实现。

(运气好的话可以选择一个普通的
诸如 Java、C# 或 C++ 之类的语言用于业务逻辑，并作为其他 DSL 的编译目标。如果你这样做，当然会很想用那一种语言编写整个事情。如果你这样做了，你可能会在下一次技术更新时卡住，并且在这个应用程序的生命周期中可能会有几次)。

为了将规范和实现分开，您需要一组 DSL 来描述这些规范，并为每个平台提供一组相应的 DSL 编译器，以便所有部分组成
.这意味着您可能无法使用来自不同来源的 DSL；没有理由相信他们生成的结果组成。因此，您可能无法定义这些和实现翻译。这不是一件容易的事。
但是，两者都不是构建一个长期存在的多平台应用程序。

有许多工具可以用来实现这样的 DSL。另一个答案提出了 EBNF，我认为需要它来描述 DSL，以及解析器生成器，我认为这是必要的，但还不够。

更好的执行机制是通用的 Program Transformation tools :

TXL

Stratego

我们的DMS Software Reengineering Toolkit .

所有这三个都可以让您为各种 DSL 定义自己的 EBNF 语法，并构建转换以将它们映射到各种不同的平台。要使用这些，您通常会
需要构成多个平台的目标语言的 EBNF 描述，因为
这些系统通过使用抽象语法树转换方法将 DSL 中的构造转换为目标语言中的构造来工作。其中每一个都有不同程度的现成目标语言描述可用。 (我们努力与 DMS 合作，以确保我们已经很好地涵盖了常用的目标语言)。

这些都不会让你脱离测试。您至少需要在规范级别编写测试，如果没有别的，那么测试的词汇/实现不会绑定(bind)到特定平台。必须以某种方式编译测试才能运行；如果它们以 DSL 术语编码并且您拥有 DSL 编译器，则它们可以被编译为(多个)实现并运行以验证在 DSL 中编码的应用程序。

编辑 10/31/2011:OP 暗示他想要别的东西；在阅读这个问题时，似乎有一些关注于架构规范的 DSL(Voelter 的论文)。我最接近这里的是 Module Interconnection Languages (MIL) 上的论文调查。 ;其中每一个都是 DSL，需要类似上述开发的东西。 MIL 需要更多；您需要一种方法来执行其规则，否则您在其中编写的任何内容都会被程序员忽略。通过阅读 MIL 和组成软件的各种源代码，您也可以使用各种转换系统来实现强制执行。理想情况下，您会阅读 MIL 和代码规范(假设代码生成器生成符合规范的代码)。