但是，为什么我们不能只将这种新的服务连接“语言”构建为对 UML 的扩展呢？特别是对 UML 2.0 的改进呢？

  当然，当我们看出采取 UML 2.0 规范的趋势时，我们意识到，它依旧不能成为文档之外其他事物的基础是有原因的。由于更加复杂的子语言，UML 2.0 规范已经增加了标准的复杂性，但是它依旧不能以一种自然的方式解决现代应用程序开发的关键问题，例如，数据库设计、测试、部署、面向服务、基于组件的开发以及用户界面结构。由于没有自然的 UML 子语言满足服务连接的需求，因此我们必须利用现有 UML 子语言中的构造型和标记来重新描述我们的应用程序设计 DSL。这会导致在已由业界众多膨胀、复杂的规范描述的设计中极其复杂的模型。利用标准的 UML 符号（其中，对应于任何已经扩展的子语言中现有的形状都可以重用），对于图表的可读性和清晰度而言是一种折中方案。最后，我们会纠缠于规范中关键内容缺乏精确度以及 UML 中固有的类型系统不匹配（较之于 .Net 和 XML 语言）之中。

  由于这些原因，我们选择利用一个为特定目的构建的元模型来定义应用程序设计 DSL，该模型本身作为相关元模型家族中的一员进行定义。这为服务连接提供了自然且精确的基础，以及到基础实施产品（当然包括一些代码）的高保真映射。对于其他关注的开发任务，我们已经得到了相同的结论，并因此产生了与其他白皮书中所述相似的类设计器和逻辑数据中心设计器的 DSL。对可扩展 DSL 的支持，构建为一系列具有定义完善的 DSL 与其他开发产品间的映射，最终成为 Microsoft 模型驱动开发策略的基础。

  综上所述，我们推荐在以下情况下使用 UML 和基于 UML 的工具：

  ·草图。 
  ·白板。 
  ·餐巾纸。 
  ·文档。 
  ·不直接与代码相关的概念性绘图。 

  我们推荐在以下情况中使用恰当定义的 DSL 和基于 DSL 的工具：

  ·从中生成代码的精确抽象。 
  ·映射到框架和组件中变化点的精确抽象。 
  ·DSL 之间的精确映射。
  ·具有到其他 DSL 或代码产品的精确指明映射的概念性绘图。 

  我们不推荐将上述几点用于详细编程逻辑的可视化编程（或至少在近几年之内）。