visual studio 建模
- 作者: 我是老王的老婆i
- 来源: 51数据库
- 2020-10-03
Visual Studio Team System 建模策略与 FAQ
适用于：
Microsoft Visual Studio Team System
摘要：客户和合作伙伴迫切希望了解 Microsoft 对于模型驱动开发的策略，及其对 Visual Studio Team System 的支持。当向他们解释我们的策略时，他们经常表现出对某些相同主题的兴趣，并引出一些相同的关注点。本文，我们讲述模型驱动开发的策略，以及开发人员通常会涉及到的一系列问题与解答。首先的五个问题涉及到我们策略的主要结构，我们将对其进行详细的回答与解释。其他的常见问题均集中于最后一部分的常规 FAQ 部分中。
本页内容
为什么建模？
如何在模型驱动的开发中使用 DSL？
UML 如何？
MDA 如何？
软件工厂是什么？
其他常见问题
为什么建模？
客户曾经告诉我们，他们在 80 年代和 90 年代初所购买的多数 CASE 工具不能为开发过程增加足够的价值。由购买的工具带来的利益并未实现，甚至好的产品也会被过度夸耀的技术承诺所掩盖。
如果工具支持的模型不能反应代码以及其他的实现产品，那么这些工具很快就会被摒弃。如果工具支持的模型用于生成代码，那么当开发人员根据生成的代码增添其他代码时，工具通常不能与之同步。尽管这些工具为生成的代码提供了很好的"往返行程"，但最终开发人员还是身陷于解决此类问题的错综复杂的情况中。因为 CASE 工具试图以超高级别的抽象（与底层实现平台相对）进行操作，所以这些问题经常变得更糟。这会导致生成大量代码，由于混合了手写代码和生成的代码，因此要解决这些问题更加困难。
尽管存在这些问题，但是与某些软件开发过程有关的一个观点是 - 应用建模可以让开发更轻松。我们的目标是改变开发人员看待建模价值的方式。要将他们的观点（建模是一个在真正开始开发之前不太重要的有用活动）改变为承认建模是一个重要的、主要的开发任务，并且不是主要集中于文档的活动。当将模型视为首要的开发产品时，由于可以使用更强大的应用程序抽象，因此开发人员会编写更少的常规代码。模型驱动的开发也因此顺理成章地更加高效和灵活。此外，其他涉及到的开发人员（从业务分析师、架构师、设计师到网络的用户以及系统管理专业人员）会发现建模对其所负责的任务会产生增值。当模型以这种方式横跨开发和运行时活动时，人员之间的交流可以得到优化，且可跟踪性使得能够跨越生命周期的任何阶段。我们坚信，以这种方式确立建模的主要位置，最终可以改变软件开发的经济性，并且保证软件系统能够满足业务的需要。该模型驱动开发的方法由 Microsoft 首创，是名为软件工厂 的产品的一部分。
注 软件工厂的深入说明，请参阅“Software Factories: Assembling Applications with Patterns, Models, Frameworks and Tools”，作者为 Jack Greenfield 和 Keith Short，以及 Steve Cook 和 Stuart Kent。
返回页首
如何在模型驱动的开发中使用 DSL？
Microsoft 已经从过去的行业经验中有所收获，并且避免了 CASE 的缺陷，这是通过采纳基于下列想法的模型驱动开发实现的：
模型应该是项目中首要的产品 - 不仅仅是一些快过时的文档。模型有精确的语法，通常利用图形化工具易于进行编辑和浏览，并且包含确定模型中特定于域的概念如何映射到其他实现产品的语义，这些实现产品包括代码、项目结构和配置文件等。按照这种方法，模型非常类似于源代码文件，而且它与其他实现产品同步的机制非常类似于编译器。
模型表示一组抽象，它以定义完善的开发内容为开发人员提供支持。例如，考虑这样一个任务：生成一个通过 Web 服务与组件进行连接的、面向服务的应用程序。要构建这样一个应用程序，假设给定开发人员必须关注的所有其他任务，在这种情况下，根据服务合同和开发人员之间交流的信息，该开发人员可以只关注定义整个应用程序连接性。为软件架构师的应用程序设计器提供的 Visual Studio Team Edition 完全支持开发的个各个方面，并管理应用程序连接性模型和所有其他产品（WSDL 文件、项目文件、代码文件、配置文件等）之间的关系。必须开发这些产品以实现由模型定义的互联。按照这种方式设计作为源产品的模型，具有额外的好处 - 提供对其他分散细节的整体视角，并且能够让不同团队（包括设计、构建和部署复杂、现代化应用程序）之间的沟通更加顺畅。
由于模型能够提炼并聚合大量产品中的信息，因此它们能够更轻松地支持一致性检查和其他形式的分析。例如，一个应用程序连接模型可以支持协定协议验证、安全性分析或性能分析。
通过一个与编辑类似的过程可以实现模型，在该过程中，由编译器生成的代码、配置文件和其他实现产品均不能进行手工编辑。然而，较普遍的情况是，模型可以由生成产品和手工编辑产品的组合实现。在这种情况下，非常重要的一点是，仔细管理使生成和手工编辑产品相互适应的方法。如上所述，不能有效做到这一点是 CASE 产品的一个主要不足之处。我们已经使用了一些技术来确保生成的产品和手工编辑产品保持独立，并且当生成工具需要套用代码时，决不会与由开发人员添加的代码发生冲突。这些技术包括，使用类委托和继承，特别是使用"部分类" - 它是 Visual Studio 中 .NET 语言的一个新特性，利用成形的任务已经进行了特别定义。
我们将以这些方式定义的建模语言称为 Domain Specific Languages 或 DSL。可以将 DSL 想象为一种用来解决一些清晰确认问题的小规模、高集中化的语言。这里所说的问题是分析师、架构师、开发人员、测试人员或系统管理员必须要处理的问题。开发人员已经熟知的 DSL 示例是：用于数据操作的 SQL 和用于 XML 文档结构定义的 XSD，等等。另一个来自 Visual Studio Team Edition for Software Architects 的示例是，用于对数据中心硬件和宿主软件配置的逻辑结构进行建模的 DSL。该 DSL 及其相关的图形设计器可以用于设计时（配置应用程序以与其部署目标相匹配）的验证，在问题可以更容易地解决时向开发人员发出警告。
找到备选 DSL 的好办法是明确开发人员使用的模式，然后将其封装到建模语言中，或将软件框架中的概念作为建模语言中的抽象表层化，然后能够生成可扩展整个框架的少量代码。这些技术允许我们控制生成代码的数量和复杂度，从而为开发人员提供真正意义的价值，而无需争论对 CASE 产品的刻画。
最近，Microsoft 发布了 DSL 工具 - 使客户和合作伙伴能够通过 Visual Studio 中的相同的技术构建 DSL，这些技术用于构建与 Visual Studio Team Edition for Software Architects 一起发行的建模工具。可以将该技术认为是"构建工具的工具"，简化了定义 DSL 的任务，并降低了为工具构建图形化编辑器和编译器的代价和技能
返回页首
UML 如何？
多数理解我们就模型驱动开发这一观点的人员，把我们假想为将重点放在 DSL 上，这一假设将我们置于一个与 UML 对立的位置。我们希望对这一不正确的想法予以澄清。在 UML 之前，各种各样的建模方法缺乏生产效益，这些方法最终形成 UML 1.0，这是在软件开发中使用模型方面向前迈进的重要一步。
但是不管是出于什么原因，UML 和基于 UML 工具的存在没有显著改变开发人员构建应用程序的方式。或者说，没有为开发人员生产效率提供明显的帮助。自从 Microsoft 提供了一个最可用的 UML 工具（基于 Visio 的工具）- 最先与 Visual Studio Enterprise Architect 一起提供，我们对该工具的使用进行了开发人员的（不仅限于我们的客户）匿名调查。我们发现，只有很少数人声明其任务支持 UML 工具，大部分使用者仅使用类图表。当我们训练这部分声明使用类图表的人员时，实际使用它们生成代码的数量很少。
除了在 Visual Studio Team Edition for Software Architects 中的模型驱动的开发工具之外，这是驱动因素之一。我们真正想要进行的是开发人员和架构师很难发现的任务，并找出建模工具可能为其增值并提供帮助的办法。我们强烈支持 UML 符号和图表。在 Microsoft 中任意的开发人员办公地点走走，就会发现白板上密布着 UML 类图表以及序列图表。我们不仅在规范文档中、在很多其他为演示准备的图表中使用 UML 符号，甚至还会将 UML 符号记录在自助餐厅的餐巾纸上。要支持客户的这些需要以生成文档和概念化草图，我们将继续在 Visual Studio 中提供 UML 工具集。事实上，通常在 Microsoft 内，我们使用 UML 的目的很多（例如用于文档或概念共享），但几乎从未 有任何一个是出于以下目的，这些文档是软件开发的实际产物。
办公室和走廊里相同的白板也布满了随意写下的代码。但在这里再次声明这都是草稿。这些代码很少能正确指示程序源代码编译。这对开发人员而言是重大的区别。任意一种有助于实际软件开发的产品必须能够进行数字化操作。源代码有定义完善的语法，易于理解的语义（通常由编译器的转换以较低级的代码或中间语言定义），并且能够由编译器、调试器和重构程序进行一致性操作。要有益于开发人员，模型必须 有与源代码相同的状态。模型还必须有精确的语法、易于理解的语义，以及定义完善的到源代码或其他定义完善模型的映射。它必须不仅 限于文档。
例如，采用 Visual Studio Team Edition for Software Architects' Application Designer。它不仅仅是文档，虽然它以该目的进行使用。它更希望使开发人员（或架构师）能够将注意力集中于系统的某一部分；而不是面向服务的体系结构中服务间的连接。她可以在构建项目、WSDL 文件、代码和架构之前设计系统的该部分，或要求工具文档化服务间的连接（如果这些产品已经存在）。由于连接信息分散于众多开发产品之中，因此整体视图（如图表）提供了基本的使用，尽管所有传递的信息可能因对实施产品的仔细检查而减少。应用程序设计器有定义完善的语法（它的 DSL 元模型）和可预知的、始终同步的到各种实施产品的映射。基础设计器框架承担应用程序设计器图表编译器的作用，非常类似于与源代码文件相关的传统编译器的作用。
但是，为什么我们不能只将这种新的服务连接"语言"构建为对 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 或代码产品的精确指明映射的概念性绘图。
我们不推荐将上述几点用于详细编程逻辑的可视化编程（或至少在近几年之内）。
返回页首
MDA 如何？
MDA 是 OMG 的一个授权品牌，它基于利用模型驱动开发的 UML。它重点强调与平台无关的模型以及衍生出的技术。根据 OMG FAQ，
"MDA 是编写规范和开发应用程序的一种新方式，它基于平台无关的模型 (PIM)。完整的 MDA 规范包括，一个基于 UML 模型的确定无关平台、一个或更多特定于平台的模型 (PSM) 以及接口定义集，它们分别描述基本模型如何在不同的中间件平台上实现。完整的 MDA 应用程序包括，一个确定的 PIM、一个或更多的 PSM 以及完整的实施，应用程序开发人员决定支持的每个平台均对应一个 PSM。"
MDA 由 OMG 定义，仅解决实际问题的一个小子集，这些问题必须用于驱动有效的模型驱动的开发。一个有效的模型驱动开发方法必须能够解决编程问题，例如：
可以开发哪些类型的系统？由于不同系统之间存在着明显的差异，因此模型驱动开发方法必须能够辨别这些差异。要有效实现，首先描述要解决的问题，然后标识可以解决问题的特定技术，显示适合解决方案的每一种技术，各种技术如何协调工作以完成解决方案。
给定类型系统的体系结构是什么？这个问题的答案不仅仅是考虑可以使用的技术，而且还涉及识别这些技术的特性（对设计系统的每个部分都很重要），以及配置每种技术的用法。这是软件体系结构的主题，已被公认为软件生命周期中最重要的定律之一。软件体系结构定义了为系统提供其结构以及定义其质量属性的高级设计决策。由于模型最初用于描述系统重要部件的体系结构，因此模型应该更紧密地与软件体系结构开发相集成。
需要为给定类型的系统继续哪方面的建模？由于不同系统的体系结构有非常大的差异 ，因此没有单独的模型集能够有效描述所有可能的系统。因此，这个问题的答案将因系统类型而异。我们的观点是：每个目标平台上单个的 PIM 和单个的 PSM，所有的开发均利用一个由 MDA 指定的常规目的建模语言，足以支持由模型驱动开发承诺的非常高级别的自动化。软件生命周期中丰富的自动化需要大量其他类型的模型，例如以下这些模型：
捕获、分析和管理需求；标识需求之间的跟踪关系，体系结构设计和实现结构，能够进行需求已实施的验证，以及在需求变更时支持对产生影响的分析。
以下列方式定义软件体系结构：支持安全性、性能和可靠性分析以及其他格式的评估；能够从组件启用预知的系统程序集，以及有效、可逆地逐步从需求和部署进行转换。
定义可执行的系统组件如何打包，标识部署环境中每个组件都需要的资源类型，以及将组件绑定到这些资源类型的特定实例。
定义测试用例、测试数据集、测试工具和其他产品，更易于评估利用模型开发的软件的质量，以管理和显示测试结果。
标识模型和其他产品间的跟踪关系，更易于在系统宕机时支持对业务影响的分析，将系统配置为满足需求，并加强系统配置期间的约束。
定义用于构建可执行文件的源产品的配置，更易于版本化这些配置，以与缺陷报告和具有特定版本的特性变更需求相关联。
模型驱动的技术如何与代码为主的开发技术集成？模型用于辅助开发人员实现任务，例如查询和导航代码基、调试、分析、覆盖分析、模式化应用程序和重构，并且可以紧密集成到面向文件的开发环境。
此外，除了上述说明的原因，强调利用发布的 UML 元模型是我们的问题所在。最后，尽管强调平台无关是某些客户所关注的，但是我们了解到更多的是他们有关对生产率、可预见性、安全性、管理以及部署和管理应用程序的有效方式的需求。然而，我们绝对赞同有关构建应用程序而使用的模型是 MDA 的中心，且重要的是模型间定义完善的映射，我们识别以下值，模型可为其提供构建跨具有互操作组件的平台的应用程序。
某些进行模型驱动开发的组织接受对术语 MDA 更广泛的解释，而不是由 OMG 描述的解释；的确，如我们所述，他们必须这样做才能获得成功。使用任意的 OMG 规范以实现模型驱动的开发，是 MDA 典型的应用，无论是否包含 PIM 和 PSM。例如，某些组织发现 OMG 的 MOF 规范是 MDA 的关键。该观点取决于用 MOF 定义的新的建模语言，而不是在 UML 中预定义的建模语言，且该观点与我们的方法极其相似。我们将支持与其他平台上普遍采用的 UML 和 MOF 工具进行交互，通过 XMI 或是通过本机格式，帮助客户成功利用它们进行模型驱动的开发。
返回页首
软件工厂是什么？
正如前面提到的，我们对于模型驱动开发的方法是 Microsoft 称之为软件工厂 的一部分。取代了一般的、一种规模满足所有需要的方法，软件工厂使用自定义的 DSL 集合，从而提供自定义的抽象集以满足系统（例如，电子商务、金融交易或国内银行应用程序）特定领域的需要。有了软件工厂，模型不仅可以用于分析和设计，而且还支持跨越整个软件生命周期（甚至是运行时）的各种类型的计算。这是软件工厂的基本原则，并且还是 Microsoft 的 Dynamic Systems Initiative (DSI) 的基本原则。DSI 实现并完成软件工厂计划。
您可以将软件工厂认为是包含并扩展 MDA，这里对 MDA 的定义比基于 PIM 和 PSM 的正式定义范围更广泛。软件工厂超越了一般的平***立性，并且特定的模型可解决前面部分中说明的其他问题。
利用图形化观点，软件工厂为特定的系统定义专门的方法。每个观点都为系统范围内的成员定义生命周期的某部分，例如需求获取、数据库设计或服务协定定义。工厂与每个观点的可再次使用部分相关联，并在对系统家族范围内团队开发成员观点的上下文中传递它们，这样就不需要搜索应用程序部分，能够启动验证并支持手工和自动指导设置。
观点图被称为软件工厂架构，与在一层抽象（系统的一部分）上完成的工作相关，或在生命周期的一个阶段内，在其他层（或其他部分和阶段）上完成的工作相关。观点图可用于从其他产品（特别是从模型）完全或部分生成产品（包括模型、源代码、配置文件等）；在开发阶段保持产品同步；验证手工开发的产品；评估需求失败或变更后的影响；组织并应用模式及其他最佳实践；捕获系统开发期间的元数据以支持系统操作和维护；提供其他形式的指导和管理。
软件工厂自动化可再次使用部分的打包和交付，可再次使用部分包括，模型和模型驱动的工具、其他类型工具（例如，向导、模板和实用程序）、开发过程、实施组件（例如，类库、框架和服务）以及内容部分（例如，模式、样式表、帮助文件、配置文件和文档）。由于软件工厂架构是一个模型，因此可以通过工具来操作软件工厂。创建规模较大的软件工厂，可通过合并较小的工厂以及通过自定义一般的工厂实现工厂的特殊化。
构建软件工厂与构建架构很类似。包括要使工厂更易于开发人员应用的获取和实现模式以及其他最佳实践。与通过手工从头开始构建系统相比，使用工厂更有效，这是因为使用工厂不扫描希望找到可重用组件的目录和存储库，在系统体系结构和开发过程的上下文中立即可用的开发下，使用工厂的开发人员具有可重用的组件适用于系统的各个部分。
当然，软件工厂计划不仅仅局限于 Microsoft 和我们提供的产品。相反，我们将软件工厂作为客户和合作伙伴这一广泛群体的基础，在我们提供的基础之上构建自定义的工厂，并且将工厂组件提供给这一群体中的其他成员。
客户和合作伙伴对软件工厂计划的响应是很积极的。我们建议，将软件工厂作为现代化组织的最佳发展方向，希望改善其与业务期望一致的开发方法，并且我们提供了 Visual Studio Team Edition for Software Architects、DSL 工具和 VSTS 中其他的新功能，作为软件工厂计划的首选产品。
适用于：
Microsoft Visual Studio Team System
摘要：客户和合作伙伴迫切希望了解 Microsoft 对于模型驱动开发的策略，及其对 Visual Studio Team System 的支持。当向他们解释我们的策略时，他们经常表现出对某些相同主题的兴趣，并引出一些相同的关注点。本文，我们讲述模型驱动开发的策略，以及开发人员通常会涉及到的一系列问题与解答。首先的五个问题涉及到我们策略的主要结构，我们将对其进行详细的回答与解释。其他的常见问题均集中于最后一部分的常规 FAQ 部分中。
本页内容
为什么建模？
如何在模型驱动的开发中使用 DSL？
UML 如何？
MDA 如何？
软件工厂是什么？
其他常见问题
为什么建模？
客户曾经告诉我们，他们在 80 年代和 90 年代初所购买的多数 CASE 工具不能为开发过程增加足够的价值。由购买的工具带来的利益并未实现，甚至好的产品也会被过度夸耀的技术承诺所掩盖。
如果工具支持的模型不能反应代码以及其他的实现产品，那么这些工具很快就会被摒弃。如果工具支持的模型用于生成代码，那么当开发人员根据生成的代码增添其他代码时，工具通常不能与之同步。尽管这些工具为生成的代码提供了很好的"往返行程"，但最终开发人员还是身陷于解决此类问题的错综复杂的情况中。因为 CASE 工具试图以超高级别的抽象（与底层实现平台相对）进行操作，所以这些问题经常变得更糟。这会导致生成大量代码，由于混合了手写代码和生成的代码，因此要解决这些问题更加困难。
尽管存在这些问题，但是与某些软件开发过程有关的一个观点是 - 应用建模可以让开发更轻松。我们的目标是改变开发人员看待建模价值的方式。要将他们的观点（建模是一个在真正开始开发之前不太重要的有用活动）改变为承认建模是一个重要的、主要的开发任务，并且不是主要集中于文档的活动。当将模型视为首要的开发产品时，由于可以使用更强大的应用程序抽象，因此开发人员会编写更少的常规代码。模型驱动的开发也因此顺理成章地更加高效和灵活。此外，其他涉及到的开发人员（从业务分析师、架构师、设计师到网络的用户以及系统管理专业人员）会发现建模对其所负责的任务会产生增值。当模型以这种方式横跨开发和运行时活动时，人员之间的交流可以得到优化，且可跟踪性使得能够跨越生命周期的任何阶段。我们坚信，以这种方式确立建模的主要位置，最终可以改变软件开发的经济性，并且保证软件系统能够满足业务的需要。该模型驱动开发的方法由 Microsoft 首创，是名为软件工厂 的产品的一部分。
注 软件工厂的深入说明，请参阅“Software Factories: Assembling Applications with Patterns, Models, Frameworks and Tools”，作者为 Jack Greenfield 和 Keith Short，以及 Steve Cook 和 Stuart Kent。
返回页首
如何在模型驱动的开发中使用 DSL？
Microsoft 已经从过去的行业经验中有所收获，并且避免了 CASE 的缺陷，这是通过采纳基于下列想法的模型驱动开发实现的：
模型应该是项目中首要的产品 - 不仅仅是一些快过时的文档。模型有精确的语法，通常利用图形化工具易于进行编辑和浏览，并且包含确定模型中特定于域的概念如何映射到其他实现产品的语义，这些实现产品包括代码、项目结构和配置文件等。按照这种方法，模型非常类似于源代码文件，而且它与其他实现产品同步的机制非常类似于编译器。
模型表示一组抽象，它以定义完善的开发内容为开发人员提供支持。例如，考虑这样一个任务：生成一个通过 Web 服务与组件进行连接的、面向服务的应用程序。要构建这样一个应用程序，假设给定开发人员必须关注的所有其他任务，在这种情况下，根据服务合同和开发人员之间交流的信息，该开发人员可以只关注定义整个应用程序连接性。为软件架构师的应用程序设计器提供的 Visual Studio Team Edition 完全支持开发的个各个方面，并管理应用程序连接性模型和所有其他产品（WSDL 文件、项目文件、代码文件、配置文件等）之间的关系。必须开发这些产品以实现由模型定义的互联。按照这种方式设计作为源产品的模型，具有额外的好处 - 提供对其他分散细节的整体视角，并且能够让不同团队（包括设计、构建和部署复杂、现代化应用程序）之间的沟通更加顺畅。
由于模型能够提炼并聚合大量产品中的信息，因此它们能够更轻松地支持一致性检查和其他形式的分析。例如，一个应用程序连接模型可以支持协定协议验证、安全性分析或性能分析。
通过一个与编辑类似的过程可以实现模型，在该过程中，由编译器生成的代码、配置文件和其他实现产品均不能进行手工编辑。然而，较普遍的情况是，模型可以由生成产品和手工编辑产品的组合实现。在这种情况下，非常重要的一点是，仔细管理使生成和手工编辑产品相互适应的方法。如上所述，不能有效做到这一点是 CASE 产品的一个主要不足之处。我们已经使用了一些技术来确保生成的产品和手工编辑产品保持独立，并且当生成工具需要套用代码时，决不会与由开发人员添加的代码发生冲突。这些技术包括，使用类委托和继承，特别是使用"部分类" - 它是 Visual Studio 中 .NET 语言的一个新特性，利用成形的任务已经进行了特别定义。
我们将以这些方式定义的建模语言称为 Domain Specific Languages 或 DSL。可以将 DSL 想象为一种用来解决一些清晰确认问题的小规模、高集中化的语言。这里所说的问题是分析师、架构师、开发人员、测试人员或系统管理员必须要处理的问题。开发人员已经熟知的 DSL 示例是：用于数据操作的 SQL 和用于 XML 文档结构定义的 XSD，等等。另一个来自 Visual Studio Team Edition for Software Architects 的示例是，用于对数据中心硬件和宿主软件配置的逻辑结构进行建模的 DSL。该 DSL 及其相关的图形设计器可以用于设计时（配置应用程序以与其部署目标相匹配）的验证，在问题可以更容易地解决时向开发人员发出警告。
找到备选 DSL 的好办法是明确开发人员使用的模式，然后将其封装到建模语言中，或将软件框架中的概念作为建模语言中的抽象表层化，然后能够生成可扩展整个框架的少量代码。这些技术允许我们控制生成代码的数量和复杂度，从而为开发人员提供真正意义的价值，而无需争论对 CASE 产品的刻画。
最近，Microsoft 发布了 DSL 工具 - 使客户和合作伙伴能够通过 Visual Studio 中的相同的技术构建 DSL，这些技术用于构建与 Visual Studio Team Edition for Software Architects 一起发行的建模工具。可以将该技术认为是"构建工具的工具"，简化了定义 DSL 的任务，并降低了为工具构建图形化编辑器和编译器的代价和技能
返回页首
UML 如何？
多数理解我们就模型驱动开发这一观点的人员，把我们假想为将重点放在 DSL 上，这一假设将我们置于一个与 UML 对立的位置。我们希望对这一不正确的想法予以澄清。在 UML 之前，各种各样的建模方法缺乏生产效益，这些方法最终形成 UML 1.0，这是在软件开发中使用模型方面向前迈进的重要一步。
但是不管是出于什么原因，UML 和基于 UML 工具的存在没有显著改变开发人员构建应用程序的方式。或者说，没有为开发人员生产效率提供明显的帮助。自从 Microsoft 提供了一个最可用的 UML 工具（基于 Visio 的工具）- 最先与 Visual Studio Enterprise Architect 一起提供，我们对该工具的使用进行了开发人员的（不仅限于我们的客户）匿名调查。我们发现，只有很少数人声明其任务支持 UML 工具，大部分使用者仅使用类图表。当我们训练这部分声明使用类图表的人员时，实际使用它们生成代码的数量很少。
除了在 Visual Studio Team Edition for Software Architects 中的模型驱动的开发工具之外，这是驱动因素之一。我们真正想要进行的是开发人员和架构师很难发现的任务，并找出建模工具可能为其增值并提供帮助的办法。我们强烈支持 UML 符号和图表。在 Microsoft 中任意的开发人员办公地点走走，就会发现白板上密布着 UML 类图表以及序列图表。我们不仅在规范文档中、在很多其他为演示准备的图表中使用 UML 符号，甚至还会将 UML 符号记录在自助餐厅的餐巾纸上。要支持客户的这些需要以生成文档和概念化草图，我们将继续在 Visual Studio 中提供 UML 工具集。事实上，通常在 Microsoft 内，我们使用 UML 的目的很多（例如用于文档或概念共享），但几乎从未 有任何一个是出于以下目的，这些文档是软件开发的实际产物。
办公室和走廊里相同的白板也布满了随意写下的代码。但在这里再次声明这都是草稿。这些代码很少能正确指示程序源代码编译。这对开发人员而言是重大的区别。任意一种有助于实际软件开发的产品必须能够进行数字化操作。源代码有定义完善的语法，易于理解的语义（通常由编译器的转换以较低级的代码或中间语言定义），并且能够由编译器、调试器和重构程序进行一致性操作。要有益于开发人员，模型必须 有与源代码相同的状态。模型还必须有精确的语法、易于理解的语义，以及定义完善的到源代码或其他定义完善模型的映射。它必须不仅 限于文档。
例如，采用 Visual Studio Team Edition for Software Architects' Application Designer。它不仅仅是文档，虽然它以该目的进行使用。它更希望使开发人员（或架构师）能够将注意力集中于系统的某一部分；而不是面向服务的体系结构中服务间的连接。她可以在构建项目、WSDL 文件、代码和架构之前设计系统的该部分，或要求工具文档化服务间的连接（如果这些产品已经存在）。由于连接信息分散于众多开发产品之中，因此整体视图（如图表）提供了基本的使用，尽管所有传递的信息可能因对实施产品的仔细检查而减少。应用程序设计器有定义完善的语法（它的 DSL 元模型）和可预知的、始终同步的到各种实施产品的映射。基础设计器框架承担应用程序设计器图表编译器的作用，非常类似于与源代码文件相关的传统编译器的作用。
但是，为什么我们不能只将这种新的服务连接"语言"构建为对 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 或代码产品的精确指明映射的概念性绘图。
我们不推荐将上述几点用于详细编程逻辑的可视化编程（或至少在近几年之内）。
返回页首
MDA 如何？
MDA 是 OMG 的一个授权品牌，它基于利用模型驱动开发的 UML。它重点强调与平台无关的模型以及衍生出的技术。根据 OMG FAQ，
"MDA 是编写规范和开发应用程序的一种新方式，它基于平台无关的模型 (PIM)。完整的 MDA 规范包括，一个基于 UML 模型的确定无关平台、一个或更多特定于平台的模型 (PSM) 以及接口定义集，它们分别描述基本模型如何在不同的中间件平台上实现。完整的 MDA 应用程序包括，一个确定的 PIM、一个或更多的 PSM 以及完整的实施，应用程序开发人员决定支持的每个平台均对应一个 PSM。"
MDA 由 OMG 定义，仅解决实际问题的一个小子集，这些问题必须用于驱动有效的模型驱动的开发。一个有效的模型驱动开发方法必须能够解决编程问题，例如：
可以开发哪些类型的系统？由于不同系统之间存在着明显的差异，因此模型驱动开发方法必须能够辨别这些差异。要有效实现，首先描述要解决的问题，然后标识可以解决问题的特定技术，显示适合解决方案的每一种技术，各种技术如何协调工作以完成解决方案。
给定类型系统的体系结构是什么？这个问题的答案不仅仅是考虑可以使用的技术，而且还涉及识别这些技术的特性（对设计系统的每个部分都很重要），以及配置每种技术的用法。这是软件体系结构的主题，已被公认为软件生命周期中最重要的定律之一。软件体系结构定义了为系统提供其结构以及定义其质量属性的高级设计决策。由于模型最初用于描述系统重要部件的体系结构，因此模型应该更紧密地与软件体系结构开发相集成。
需要为给定类型的系统继续哪方面的建模？由于不同系统的体系结构有非常大的差异 ，因此没有单独的模型集能够有效描述所有可能的系统。因此，这个问题的答案将因系统类型而异。我们的观点是：每个目标平台上单个的 PIM 和单个的 PSM，所有的开发均利用一个由 MDA 指定的常规目的建模语言，足以支持由模型驱动开发承诺的非常高级别的自动化。软件生命周期中丰富的自动化需要大量其他类型的模型，例如以下这些模型：
捕获、分析和管理需求；标识需求之间的跟踪关系，体系结构设计和实现结构，能够进行需求已实施的验证，以及在需求变更时支持对产生影响的分析。
以下列方式定义软件体系结构：支持安全性、性能和可靠性分析以及其他格式的评估；能够从组件启用预知的系统程序集，以及有效、可逆地逐步从需求和部署进行转换。
定义可执行的系统组件如何打包，标识部署环境中每个组件都需要的资源类型，以及将组件绑定到这些资源类型的特定实例。
定义测试用例、测试数据集、测试工具和其他产品，更易于评估利用模型开发的软件的质量，以管理和显示测试结果。
标识模型和其他产品间的跟踪关系，更易于在系统宕机时支持对业务影响的分析，将系统配置为满足需求，并加强系统配置期间的约束。
定义用于构建可执行文件的源产品的配置，更易于版本化这些配置，以与缺陷报告和具有特定版本的特性变更需求相关联。
模型驱动的技术如何与代码为主的开发技术集成？模型用于辅助开发人员实现任务，例如查询和导航代码基、调试、分析、覆盖分析、模式化应用程序和重构，并且可以紧密集成到面向文件的开发环境。
此外，除了上述说明的原因，强调利用发布的 UML 元模型是我们的问题所在。最后，尽管强调平台无关是某些客户所关注的，但是我们了解到更多的是他们有关对生产率、可预见性、安全性、管理以及部署和管理应用程序的有效方式的需求。然而，我们绝对赞同有关构建应用程序而使用的模型是 MDA 的中心，且重要的是模型间定义完善的映射，我们识别以下值，模型可为其提供构建跨具有互操作组件的平台的应用程序。
某些进行模型驱动开发的组织接受对术语 MDA 更广泛的解释，而不是由 OMG 描述的解释；的确，如我们所述，他们必须这样做才能获得成功。使用任意的 OMG 规范以实现模型驱动的开发，是 MDA 典型的应用，无论是否包含 PIM 和 PSM。例如，某些组织发现 OMG 的 MOF 规范是 MDA 的关键。该观点取决于用 MOF 定义的新的建模语言，而不是在 UML 中预定义的建模语言，且该观点与我们的方法极其相似。我们将支持与其他平台上普遍采用的 UML 和 MOF 工具进行交互，通过 XMI 或是通过本机格式，帮助客户成功利用它们进行模型驱动的开发。
返回页首
软件工厂是什么？
正如前面提到的，我们对于模型驱动开发的方法是 Microsoft 称之为软件工厂 的一部分。取代了一般的、一种规模满足所有需要的方法，软件工厂使用自定义的 DSL 集合，从而提供自定义的抽象集以满足系统（例如，电子商务、金融交易或国内银行应用程序）特定领域的需要。有了软件工厂，模型不仅可以用于分析和设计，而且还支持跨越整个软件生命周期（甚至是运行时）的各种类型的计算。这是软件工厂的基本原则，并且还是 Microsoft 的 Dynamic Systems Initiative (DSI) 的基本原则。DSI 实现并完成软件工厂计划。
您可以将软件工厂认为是包含并扩展 MDA，这里对 MDA 的定义比基于 PIM 和 PSM 的正式定义范围更广泛。软件工厂超越了一般的平***立性，并且特定的模型可解决前面部分中说明的其他问题。
利用图形化观点，软件工厂为特定的系统定义专门的方法。每个观点都为系统范围内的成员定义生命周期的某部分，例如需求获取、数据库设计或服务协定定义。工厂与每个观点的可再次使用部分相关联，并在对系统家族范围内团队开发成员观点的上下文中传递它们，这样就不需要搜索应用程序部分，能够启动验证并支持手工和自动指导设置。
观点图被称为软件工厂架构，与在一层抽象（系统的一部分）上完成的工作相关，或在生命周期的一个阶段内，在其他层（或其他部分和阶段）上完成的工作相关。观点图可用于从其他产品（特别是从模型）完全或部分生成产品（包括模型、源代码、配置文件等）；在开发阶段保持产品同步；验证手工开发的产品；评估需求失败或变更后的影响；组织并应用模式及其他最佳实践；捕获系统开发期间的元数据以支持系统操作和维护；提供其他形式的指导和管理。
软件工厂自动化可再次使用部分的打包和交付，可再次使用部分包括，模型和模型驱动的工具、其他类型工具（例如，向导、模板和实用程序）、开发过程、实施组件（例如，类库、框架和服务）以及内容部分（例如，模式、样式表、帮助文件、配置文件和文档）。由于软件工厂架构是一个模型，因此可以通过工具来操作软件工厂。创建规模较大的软件工厂，可通过合并较小的工厂以及通过自定义一般的工厂实现工厂的特殊化。
构建软件工厂与构建架构很类似。包括要使工厂更易于开发人员应用的获取和实现模式以及其他最佳实践。与通过手工从头开始构建系统相比，使用工厂更有效，这是因为使用工厂不扫描希望找到可重用组件的目录和存储库，在系统体系结构和开发过程的上下文中立即可用的开发下，使用工厂的开发人员具有可重用的组件适用于系统的各个部分。
当然，软件工厂计划不仅仅局限于 Microsoft 和我们提供的产品。相反，我们将软件工厂作为客户和合作伙伴这一广泛群体的基础，在我们提供的基础之上构建自定义的工厂，并且将工厂组件提供给这一群体中的其他成员。
客户和合作伙伴对软件工厂计划的响应是很积极的。我们建议，将软件工厂作为现代化组织的最佳发展方向，希望改善其与业务期望一致的开发方法，并且我们提供了 Visual Studio Team Edition for Software Architects、DSL 工具和 VSTS 中其他的新功能，作为软件工厂计划的首选产品。
推荐阅读
