适用于：
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 中其他的新功能，作为软件工厂计划的首选产品。
有关详细信息，请参阅 Software Factories Workbench。
返回页首
其他常见问题
常规问题
在 Visual Studio 中，提供了对模型驱动开发的什么支持？
Visual Studio 包含了一个功能强大的新模型框架，它赋予 Visual Studio 2005 类设计器和 Visual Studio Team System 中分布式系统设计器强大的功能。我们将逐步为最终用户揭示基础建模平台，使他们能够创建丰富的模型驱动开发工具。Microsoft 的 DSL 工具是迈向目标的第一步。
Visual Studio 2005 类设计器是为开发人员生产提供的一个增强工具，它使您能够可视化类结构及其之间的关系，利用可视化的设计环境创建新类并可轻松地重构这些类。类设计器将特定于 .NET 的构造（如部分类和泛型）视为最重要的内容，这使您能够建模具有高精确度的 .NET 应用程序。通过保持与代码的持续同步，类设计器在任何时候都为开发人员提供其代码的一个可视化表示。有关详细信息，请参阅 Visual Studio 2005 Class Designer。
Visual Studio 2005 Team Edition for Software Architects 包括分布式系统设计器，它针对面向服务应用程序（特别是那些依赖于基于 ASMX 的 Web 服务的应用程序）的设计。
分布式系统设计器由四个设计器构成：
| • | 应用程序设计器 - 使开发人员和架构师能够定义要配置到部署系统中的应用程序。 |
| • | 逻辑数据中心设计器 - 用于创建互连主机的关系图，它表示数据中心的逻辑结构，目的是为了实现在开发人员间进行有关目标部署环境重要信息的沟通。 |
| • | 系统设计器 - 用于在系统中构成应用程序。 |
| • | 部署设计器 - 用于将系统中的应用程序绑定到在"逻辑数据中心设计器"中建模的逻辑服务器（应用程序主机）。 |
应用程序架构师能够可视化其面向服务的应用程序，开发人员能够使用生成的代码，同时保持代码的更改与可视化设计同步。基础结构架构师能够创建其数据中心的逻辑抽象，并根据应用程序/数据中心（在实际部署前由应用程序架构师设计）的约束对它进行验证。.通过该验证生成的报告有助于记录部署映射。
对于那些需要传统的面向对象分析和设计（Object-Oriented Analysis and Design，OOA&D）工具的用户，我们继续提供对 Visio for Enterprise Architects（是 Visual Studio Team System. Visio for Enterprise Architects 的一部分）的支持，为那些需要传统 UML 建模工具的用户提供完整的绘图、图表化、代码生成和反向工程解决方案。大量的第三方提供商也将提供集成到 Visual Studio 之中的 UML 工具。
Visio 为企业架构师提供了什么功能？
利用 Microsoft Visio for Enterprise Architects，用户能够创建应用程序体系结构、业务需求、数据库设计和业务过程并与它们进行通讯。利用 Microsoft Visual C++ .NET、Microsoft Visual Basic .NET 或 Microsoft Visual C# .NET，架构师能够使用统一建模语言（Unified Modeling Language，UML）1.3 模型来指定应用程序体系结构和功能，通过直接生成类、函数和方法来缩短开发时间，并通过反向工程项目来文档化现有的应用程序代码。Visio for Enterprise Architects 使开发人员能够创建与其团队中其他成员可以共享的体系结构的设计和模型。
Visio for Enterprise Architects 提供对数据库建模（包括概念、逻辑和物理视图）的端到端支持。业务分析师能够利用"Fact Editor"轻松输入业务规则，在"Fact Editor"中随即生成一个可由数据库分析师提炼的基础数据库模型。往返工程保证任意视图中产生的变化将随时得到反应，从而改善整个开发团队间的交流。
Visual Studio Team System 支持 UML 的哪些版本？
Visio for Enterprise Architects 支持 UML 1.3 语言规范。
Microsoft 会继续坚信 UML 建模工具的价值吗？如果是，为什么 Microsoft 现在不支持 UML 2.0？
是，绝对坚信。我们相信 UML 会继续保持其在软件开发生命周期早期阶段的位置，并且我们会继续为大量提供 UML 2.0 tools for Visual Studio 的合作伙伴提供支持。我们自己特定于域的设计器还将支持有意义的 UML 符号化规则。
通过 Microsoft，您将看到大量新的设计器，这些设计器将模型认为是最重要的部分，并且可将它们真正用于驱动开发，而不仅仅是创建文档。Visual Studio 2005 Team Edition for Software Architects 中的 Distributed System Designers 是此类工具的第一个示例。
是否 Microsoft 正在尝试跳过 UML 标准并将客户锁定到其自己的建模语言？
否。UML 标准较弱，出于这种原因，大部分 UML 工具不能无缝地进行交互。虽然我们意识到 UML 对于文档和软件设计理解的价值，但特定于域的语言将使您能够在抽象的较高层次进行工作，并将注意力精确地集中于与特定域相关的问题上。
将来，Microsoft 会提供附加的特定于域的建模工具，并且我们将继续与合作伙伴合作以为 Visual Studio 2005 提供构建于建模框架顶层的 UML 工具。
我能将自己现有的 UML 图表导入到 Visual Studio Team System 中吗？
大多数广为使用的基于 UML 的类设计工具使用不同种类的 XMI 来导出和导入反应其 UML 标准实施的信息。我们不负责为这些工具生成自定义的 XMI 导入/导出工具。通过从图表生成代码并通过"Class Designer"查看代码，在逻辑上"导入"现有的 UML 类图表是有可能的。
Visual Studio Team System 支持行为建模和用例图表吗？
是，通过 Visio for Enterprise Architects（包括于 Visual Studio Team System、Visual Studio Team Edition for Software Architects 中）支持具有代码生成的行为建模和的用例图表以及反向工程。但是，不主动支持这些图表的类型。通过最近发布的 Microsoft Tools for Domain Specific Languages，自定义的图表类型还可以在功能强大的 Visual Studio 2005 建模框架顶层进行创建。
Microsoft Tools for Domain Specific Languages
什么是特定于域的语言？
相对于常规用途的语言而言，特定于域的语言 (DSL) 是用于特定问题领域中的特定任务。DSL 在软件工程领域中得以普及，并提高了软件产品的生产率，增强了其可维护性和可重用性，使概念的表达和验证能够在问题域的抽象层进行。
利用特定于域的语言，可以构建自定义的建模工具，实际上是定义一个新的建模语言并很简单地执行它。例如，一种特定语言可用于描述用户界面、业务过程、数据库和信息流，然后利用该语言生成这些描述的代码。
为了分布式系统的设计和对具有逻辑数据中心系统的验证，Visual Studio 2005 Team Edition for Software Architects包括一些高质量的可视化设计器（基于特定于域的语言）。
Microsoft 为特定于域的语言提供了什么工具？
Microsoft 为特定于域的语言提供的工具使您能够描述与特定问题域相关的概念，并作为在 Visual Studio 中创建自定义的可视化设计器的基础。这些工具使您能够在相同的基础结构（驱动 Visual Studio Team System 分布式系统设计器 - Visual Studio 2005 Team System: Designing Distributed Systems for Deployment 和类设计器 - Visual Studio 2005 Class Designer）之上构建自己的自定义设计器，同时还是最终实现软件工厂可视化的核心。在 Visual Studio Team System workshop 中的 DSL Tools workbench 可找到这些工具以及相应的演练。
哪些 Visual Studio 产品将支持 Microsoft 的 DSL 工具？
在 Visual Studio Professional Edition 及更高版本中将提供对 DSL 创作的支持。在 Visual Studio Professional Edition 及更高版本中将提供对 DSL 使用的支持。
什么类型的设计器可通过最近发布的 DSL 工具进行构建？
DSL 工具可用于建立自定义的可视化设计器，该设计器根据问题域进行裁剪。例如，利用 DSL 工具创建业务过程建模工具以描述特定于组织模型业务过程方法的概念。如果您构建一个状态图工具，您可以描述状态的内容、状态具有的属性、状态存在的种类、在定义的状态间进行转换的方式，等等。当然，描述一家保险公司内合同状态的状态图概念，与描述一个网页中用户界面的状态图概念在概念上是相似的，但是在实现方面可能会有相当大的差异。通过创建自定义设计器，您能够精确地定义工具中需要的状态图概念。
除了特定于域的语言和软件工厂之外，Microsoft 有对行业的支持吗？
除了在学术团体中的广泛支持之外，对于很多客户和合作伙伴，Microsoft 提供了对下列公司的支持：
| • | Borland，UML 2.0 的设计器。 |
| • | Unisys，各种行业的软件工厂。 |
| • | Siemens，医学影像设备软件的软件工厂。 |
| • | Kinzan，Web 开发的特定于域的工具。 |
| • | Nationwide，金融行业的特定于域的工具。 |
类设计器和 Visio
什么是 Visual Studio 类设计器？
Visual Studio 类设计器使您能够可视化类的结构以及它们之间的关系，利用可视化的设计环境创建新类并可轻松地重构这些类。有关详细信息，请参阅：
| • | |
| • | |
| • |
Visual Studio 的哪个版本将包含新的类设计器？
Visual Studio 标准版以及更高版本将包含类设计器。
类设计器支持什么语言？
类设计器支持 C#、VB.NET 和 J#。Visual Studio 2005 的类设计器支持不支持 C++，但是对于下一版本的 Visual Studio 具有最高优先级。
类设计器与 Visio 有何不同？
Visual Studio 类设计器使您能可视化类的结构以及它们之间的关系，利用可视化的设计环境创建新类，并轻松地重构这些类。对类关系图的更改立即反映到代码，并且对代码的更改也立即反映到设计器外观。设计器与代码之间的同步关系，可轻松实现可视化地创建和配置复杂的 CLR 类型。类设计器对于理解已有的代码、类设计、重构代码和创建文档是有用的。类设计器与 Visual Studio 2005（Visual Studio Standard Edition 以及更高版本）无缝集合，并经裁剪以适应 .NET Framework 和 CLR。
我可以将现有的 Visio、Rational Rose 或 Rational XDE 关系图导入到新的类设计器中吗？
可以，您可以在逻辑上"导入"现有的 UML 类关系图表，方法是首先从关系图表生成代码，然后通过类设计器查看代码。
类设计器支持 XMI 输入/输出吗？
不支持，类设计器不支持 XMI 输入/输出。用户可以从其已有的模型生成代码，然后使用类设计器使代码可视化。由于普遍使用的基于 UML 的类设计工具使用特殊的 XMI 变量来支持它的实现，因此我们不允许为每一个第三方产品的类设计器输入/输出工具来生成自定义的 XMI。
Visio 支持 XMI 输入/输出吗？
目前通过独立、单独的下载，Visio 支持 XMI 输出。有关详细信息，请参阅 Visio 2003 UML To XMI Export。
Visio 的未来趋势如何？Visio 和类设计器如何适应"软件工厂"的宏图？
作为 Visual Studio 一部分而提供的 Visio for Enterprise Architects，为用户现有的 Visio 投入提供了向后兼容性，并且将继续提供对 Visio 功能的支持。然而，新的类设计器获得了与 Visual Studio 的无缝集成，并进行了特殊的设计以适应 .NET Framework 和 CLR。Visual Studio 类设计器使您能够可视化类的结构及其关系，利用可视化设计环境创建新的类并可轻松地重构类。对类关系图的更改立即反映到代码，并且对代码的更改也立即反映到设计器外观。设计器与代码之间的同步关系，可轻松实现可视化地创建和配置复杂的 CLR 类型。类设计器对于理解已有的代码、类设计、重构代码和创建文档是有用的。新的特定于域的语言的工具是 Visual Studio 2005 SDK 的一部分，它允许用户和合作伙伴构建经裁剪的自定义设计器以适应他们的问题域。例如，Borland 已经宣布了一个计划 - 在该架构的顶层构建一套完整的 UML 2.0 设计器。该框架与构建类设计器和分布式系统设计器的框架相同。
软件工厂
软件工厂是什么？
"软件工厂"由专用的工具、过程和其他有用资源（例如，模式、体系结构、框架、模板、需求、测试用例和部署拓扑）构成；它封装了特定问题域的业务和技术知识。例如，保健行业的软件工厂可能由以下内容构成：为设计保健解决方案而裁剪的建模工具；贯穿于整个保健行业的各个方面，为开发人员提供说明和指导的过程指南；以及提供保健解决方案公共基类的体系结构框架。这样的一个软件工厂将自动化开发人员必须执行的角色和工作任务，以便构建保健行业解决方案，给予开发人员充分的空间以应用他们的创意和经验，从而完成项目。
软件工厂将使软件开发行业化并消除对熟练程序员的需求吗？
与 19 世纪对"工厂"一词的理解不同，"软件工厂"并不是一种规模、外形或使开发人员趋于体力劳动者的形式。通过自动化角色和工作任务，帮助开发人员以一种高层次抽象进行工作，"软件工厂"将使开发人员更有效地进行工作。当我们提出"工厂"一词的新解释时，对于头脑中该词的含义，我们已经有了更新的解释，特别是使用能自动化手工工作的机器人之后。"软件工厂"提供的编程工具将使开发人员花费更多的时间来考虑如何解决问题，并用较少的时间完成所有创建、构成和部署其解决方案需要做的内部工作。
在 OOPSLA 2004 中公布了什么内容？
在 OOPSLA 2004 中，公布了：
| • | 一个可扩展性模型，用于为特定问题域构建 Visual Studio Team System 的自定义可视化设计工具。 |
| • | 可以随时使用 Community Technology Preview 的工具，构建 Visual Studio Team System 中自定义的可视化设计工具。 |
| • | 通过特定于域的建模环境（如上所述），扩展了对于 Visual Studio Team System 中扩展的可视化设计工具的合作伙伴和行业支持。 |