我们正在评估在过程中我们可以使用外部DSL来描述,建模和生成多平台应用程序的程度.我个人没有看到很多应用程序来描述Enterprise-Domain,因为在我的情况下,大多数应用程序都很简单.密集的测试驱动开发似乎更适合剩余的任务.
在技术方面还有其他挑战,我想用坚实的策略来对抗.由于存在大量系统的潜力,我想尽可能好地描述接口.
我找到了一些ORM-Frameworks,它们有一些代码/ shema转换器来自一些元素(Doctrine看起来不错),还有一些来自Markus Voelter的文章(特别是"架构作为语言").
你知道其他任何有趣的,甚至是矛盾的例子吗？
因此,通过Multiplatform,我认为你的意思是"必须在多个异构系统上运行".
您将面临指定和实施的问题:
如果您按照Voelter的论文,您将需要一些东西来描述"架构",即如何组合每个这些部分的元素来实现整体.
如果您的所有平台都不是由一组现成技术(例如,J2EE或其他类似技术)提供服务,并且它具有很长的生命周期,那么您可能希望将这些工件的规范与其实现分开.
(如果幸运的话,你可以为业务逻辑选择一种通用语言,如Java,C#或C++,以及作为其他DSL的编译目标.如果你这样做,当然诱惑就是编写整个事物的代码.那种语言;如果你这样做,你可能会陷入下一次技术更新,并且在这个应用程序的整个生命周期中可能会有几个).
为了使规范和实现保持独立,您需要一组DSL来描述这些规范,并为每个平台创建一组相应的DSL编译器,以便所有部分组成.这意味着您可能无法从不同来源获取DSL; 没有理由相信他们产生的结果.因此,您很可能无法定义这些和实现转换.这不是一件容易的事.但是,它们也没有构建一个长期存在的多平台应用程序.
有许多工具可用于实现此类DSL.另一个答案提出EBNF,我认为需要它来描述DSL和解析器生成器,我认为这是必要的,但几乎不够.
更好的实施机制是通用的程序转换工具:
所有这三个都可以让您为各种DSL定义自己的EBNF语法,并构建转换以将它们映射到各种多个平台.要使用这些,您通常需要构成多个平台的目标语言的EBNF描述,因为这些系统通过使用abstract-syntax-tree转换方法将DSL中的构造转换为目标语言中的构造来工作. .这些中的每一个都具有可用的现成目标语言描述的不同程度.(我们努力与DMS合作,以确保我们已经很好地涵盖了常用的目标语言).
这些都不会让你退出测试.您至少需要在规范级别编写测试,如果没有别的话,那么测试的词汇表/实现不依赖于特定平台.测试必须以某种方式编译下来运行; 如果它们以DSL术语编码并且您有DSL编译器,则可以将它们编译为(多个)实现并运行以验证在DSL中编码的应用程序.
编辑10/31/2011:OP暗示他想要别的东西; 在阅读这个问题时,似乎有一些关注用于架构规范的DSL(Voelter的论文).我最接近的是对模块互连语言(MIL)的论文的调查; 每个都是DSL,需要像上面的开发.MIL需要更多; 您需要一种方法来强制执行其规则或者您在其中编写的任何内容将被程序员忽略.通过阅读MIL和构成软件的各种源代码,您还可以使用各种转换系统来实施强制执行.理想情况下,你会读MIL和规范的代码(假定代码生成器产生兑现的规格代码).