3-误解：MDD==UML？

　　有一个误解是MDD意味着你必须使用统一建模语言（UML）——现状如此，完全是因为来自对象管理组织（OMG）的UML规范进行了这样的描述。消除这一误解的方法有很多。

　　打消这种念头的第一种方法是用MDD的方法工作，这只需要你在执行任务时把模型作为关键的工件使用，并使用利用这些模型的自动化机制。在这种情况下，模型是用语言简化了的现实，而这些语言具有定义良好的语法和语义。因此，可以在MDD中使用的语言有很多，而不仅仅是UML。

　　在大多数情况下，我们确实要为手头上的任务选择合适的工具。如果我们的MDD需要标准化、为人熟知、被广泛支持的语言，那UML就是一个不错的选择。UML也是可扩展的。严格来说，它能通过配置（提供定制的元素、属性和约束）进行定制。这能让UML对所作的工作来说变得具体，也能让语言更加易学易用。增强建模语言可用性或针对性的另一种方式是创建你自己的领域特定语言（DSL）。

　　要记住的是，我们受益于使用的语言和创建的模型。为了指导投资，我们要权衡以下问题：

　　* 是否能有效地设计和理解解空间？

　　* 能否轻松地和其他人沟通？

　　* 是否能基于已经创建好的模型生成方案的其他部分？

　　* 能否有效利用开发生命期之外的结果？

　　* 是否能从实现追溯到设计？甚至需求？

　　4-误解：MDD放之四海而皆准

　　根据前面的误解可以看出，MDD显然不是放之四海而皆准的解决方法，任何非预设的生产线工具集都可以用来构建产品。MDD就是用模型为特定情况增加价值，它适用于特定领域，跟你所开发的软件类型也是配套的。因此，我们能在自己的场景中看到很多使用MDD、有意义的方式。

　　其中一个例子是，我们可以和传统的面向对象分析和设计（OOAD）一起使用MDD。在审视OOAD和MDD的时候，往往会发现使用了很多模型，比如用例、分析、设计和实现。有很多现成的例子和文档演示了如何使用这些模型来完成方案。但这并不意味着你必须用上所有的模型。关键是我们要有效地利用抽象。抽象的层次取决于所处的场景、使用的语言、相关的约束、规则和假设，以及可能实施的自动化。

　　除了在模型数量（和相关的抽象层次）上务实之外，也要切合实际地选择模型中用于交流的图表。比如说，如果使用UML作为建模语言，就没必要使用所有可用的图表类型（类图、交互图……）。语言中有一系列图表可供选择，一般用途的建模语言能为各种需求提供服务就可以了。在特定情形下，对于你试图完成的工作来说，只选择那些能为其增加价值、有助于沟通的图表才是有意义的。至于完整性，我们可以进行进一步的讨论，要注意的是，即使在一个图表中，你也不必使用所有可用的模型元素。

　　5-误解：图表就是模型

　　MDD中关键的一点是要认识到我们在创建模型——正如前面所讨论的，模型是用语言简化现实，该语言要具有良好定义的语法和语义。我们在模型中可以发现大量模型元素和一组图表。每种图表都提供了模型元素之上的一个视图。每个模型元素属于零或多个图表。我们要关注模型元素——它们是什么？有哪些关系？有什么属性？我们通常使用图表来帮助我们理清这些问题。此外，我们还将图表作为和其他人沟通的方式。但模型的关键信息存在于模型元素中——因为这能让我们生成所需的视图、创建所需的图表，从模型生成其他元素。如果MDD只是图表，那工具能画出漂亮的图片就能满足我们的需求了。这并不是说图表（和支持图表的工具）不重要。创建模型和图表的工具需要进行调整，以适合目标受众。

　　结合有选择性地使用图表，我们还能利用视角让模型更加可用、更加利于沟通。视角是组织模型的一种方式，以便模型的某些方面可以提供额外的图表，使模型面向各种各样的受众。透视图通常只包含图表，而没有额外的语义元素。严格来说，在你更新语义元素时，透视图会自动保持同步。使用透视图可以让你与其他角色和小组有效沟通，从而为MDD增加价值。每个小组都想理解方案中的一部分内容，也就是与他们的需求相关的那部分。在不打乱模型、不构建独立模型、或是不在维护同一元素的多个版本上浪费时间的情况下，透视图可以支持这些需求。请记住，我的意思并不是让你支持所有不同的小组，并创建庞大的一组透视图。再次强调一下，关键是要务实，要创建有意义、能带来价值的图表与视角。