微软加入 OMG:选择 DSL 还是 UML?

阅读数:411 2008 年 9 月 22 日

话题:.NET架构语言 & 开发

过去微软在模型架构方面下了很大的功夫,比如 BizTalk、软件工厂以及 VSX 工具等,而近日它又宣布加入 OMG,并且已经准备发布其下一代建模架构的社区技术预览版(CTP):Oslo

对于 Oslo 项目,服务器和工具部门的 SVP(软件高级副总裁)Bob Muglia 解释了微软的这一做法

将模型深植于系统内部,令系统本身的操作亦是模型驱动的。

对象管理组织(OMG,Object Management Group)目前控制着数个建模架构元素:UML,通用的模语言;MDA,OMG 的模型驱动架构方法;BPMN,业务流程建模标注;以及众多定义行业特定模型的行业垂直组织(领域任务组,Domain Task Forces)。

前不久,微软宣布了它正在 VSTS 的下一代版本Rosario中启动对 5 种 UML 2.1 图表的支持。这一举措旋即掀起人们对 UML 和 DSL 之间关系的争论。Cameron Skinner 解释说:

有些文章试图给读者这样一个印象,那就是微软正在放弃领域特定语言,转而支持 UML。完全错误!我想我要花些时间纠正以上误解,并且让大家从更广泛的层面展开讨论。

他强调说:

微软在 DSL 战略上矢志不移,从VS SDK中附带的DSL 工具集就能看得出来。实际上,我们的 UML 设计器就是基于这个工具集构建的。

我们两种建模方法都支持,让开发者和架构师选择“正确的工具处理正确的工作”。有些人希望分析和设计架构的时候使用与具体实现无关的标准标注,那么可以选择 UML 图表。UML 适合用来表述较高层次的概念,以及为沟通中必不可少的概念的定义基本的词汇表。另一些人已经决定好实现策略,不想在描述实现的时候承受由于 UML 的“通用”而带来的累赘,DSL 是不错的选择。

他总结说:

我们确实在试图将这两种方法清晰地划分开来,但同时,也希望认识到两者之间的互补关系。

所以,这不是一个“DSL vs. UML”的讨论,而是一个“DSL + UML”的讨论。另外更重要的是,我们要适应客户的情况,根据他们的目的来提供合适的工具。

对于这一论断,Johan den Haan 最近也发表了自己的见解

听起来是不是很耳熟?请和MDA 的概念相比较一下!基本上,Cameron 的观点是,UML 应该被用作定义平台独立模型(PIM,Platform Independent Model)的语言,而 DSL 应该被用作定义平台特定模型(PSM,Platform Specific Model)的语言。

他还提到:

Steven Kelly对这个方法并不感冒:现在 DSL 已经不再专心于它本应关注的问题域(Problem Domain),而是出界到了解决方案域(Solution Domain):它们有一套微软特有的框架或者类库的实现概念。他还坚定地指出:以这种方式将 UML 推在 DSL 的前面,无异于将马车放在马的前面——不仅让马坐进马车里,你还自己拉着它们跑。

但是 Johan 对 OMG MDA 有着不同的看法,他归纳了两个原因:

首先,他们将 UML 作为语言使用,然而 UML 又大又复杂,所以很难学习和使用;第二,他们只关注一个建模维度(抽象 - 具体的维度)。

Johan 解释说,现在存在着两种类型的 DSL,一种关注问题域,一种关注解决方案域。他分别称之为:主题域(Subject-Area)DSL 和基于框架(Framework-Based)的 DSL。然而他提醒说:

主题域 DSL 有一个更高层级的抽象,因此如果设计和实施都很划得来的话,你应该采用这种类型。但是不要忘记,这取决于很多个方面,包括用户社区的大小,培训资料的制作,语言支持,标准化和维护等,要知道稍有不慎这些因素都会变成严重而且消耗时间的障碍。

Johan 总结说:

我非常赞同 Steven(看上面引言部分)所说的,Cameron 提到的使用 UML 和 DSL 的方法不是一个非常好的主意。

然后他又说道:

我想采用通用标准定义 DSL 有助于实现可执行的 DSL,甚至能跨平台。其出路不在于各种模型转换,而在于使用一般化的元模型来定义通用概念供 DSL 使用(比如本体论)。

就这些问题,InfoQ 和微软平台架构团队的高级总监,也是即将出版的软件工厂方面书籍《软件工厂应用》的作者 Jacky Greenfield 做了沟通,他解释说:

领域特定语言(DSL)是一种针对专门的概念、任务或者平台的语言。相反,通用语言(General Purpose Language,GPL)则设计成表述广泛的概念、任务或者平台的语言。每种语言都有价值。

他还说:

当问题域还没有完全清楚的情况下,或者变动比较大的时候,在给定问题的早期使用 GPL 是非常有效的。GPL 的威力来自于它们描述多种不同问题域的能力。这本身就是它们的设计目的,然而,GPL 的表述通常存在多种解读,因此描述信息的准确度受到限制。

如果问题域已经非常清楚,变动也比较慢的话,在给定问题的后期使用 DSL 更加有效。因为它们的设计目标是尽可能充分地描述一个特定问题域,所以留给不同解读的空间较少,更能精确地传达信息。实际上,大多数 DSL 都具备精确的语义,可以非常可靠地产生出指定编程语言或描述语言的正确代码。但是,也正是因为这种特定性,一种 DSL 的能力是有限制的。

最后,Jacky 总结说:

实际上,GPL 和 DSL 的区分并不是非黑即白。换句话说,从通用语言到领域特定语言的过渡并不是一个阶跃函数。通常,通过使用扩展机制(比如 UML 中的 stereotypes),GPL 在某种程度上可被加以定制,以提高模型所表达的目标领域中信息的精确性。另外,GPL 工具通常也可以加以扩展以利用语言的扩展性(比如写一个定制的代码生成器)。但是从 GPL 到 DSL 的过渡中存在一个临界点,此时问题域的表达需求和 GPL 的表达能力的差距太大,用 GPL 很难实现所需要的精确程度。越过临界点之后,对用户来说语言扩展变得过于笨重,而工具扩展亦受限于 GPL 元模型和底层工具架构。这时最好还是去定义 DSL 吧。

UML 是不是正变得更像一种标注,而不再是一门语言?我们是不是正在更大规模接受模型驱动工程的概念?面对这一形势,你有什么打算?

查看英文原文:Microsoft Joins the OMG: UML or DSL?