在 Visual Studio 中，可以使用模型来帮助你了解和更改系统、应用程序或组件。 模型可帮助你可视化系统工作的世界，阐明用户的需求，定义系统的体系结构，分析代码，并确保代码满足要求。
若要查看 Visual Studio 哪些版本支持每种类型的模型，请参阅 对体系结构和建模工具的版本支持。
模型可通过多种方式帮助你：
绘制建模图有助于阐明要求、体系结构和高级设计所涉及的概念。 有关详细信息，请参阅 模型用户要求。
使用模型有助于公开要求不一致的情况。
与模型通信有助于与自然语言相比不太明确地传达重要概念。 有关详细信息，请参阅 为应用的体系结构建模。
有时可以使用模型生成代码或其他项目，例如数据库架构或文档。 例如，Visual Studio 的建模组件是从模型生成的。 有关详细信息，请参阅 从模型生成和配置应用。
可以在各种流程中使用模型，从极端敏捷到高规范。
使用模型减少歧义性
建模语言比自然语言更明确，旨在表达软件开发过程中通常所需的想法。
如果你的项目有一个遵循敏捷做法的小团队，则可以使用模型来帮助你阐明用户情景。 在与客户讨论其需求时，创建模型可以比编写实验或原型代码更快地提出有用的问题，并且涵盖产品的更广泛方面。
如果你的项目很大，并且包括全球不同地区的团队，则可以使用模型来帮助传达要求和体系结构，比纯文本中的体系结构更有效。
在这两种情况下，创建模型几乎总是会导致明显减少不一致和歧义。 不同的利益干系人经常对系统工作的业务领域有不同的了解，不同的开发人员经常对系统的工作方式有不同的了解。 使用模型作为讨论的焦点通常会公开这些差异。 有关如何使用模型来减少不一致的详细信息，请参阅 模型用户要求。
将模型与其他工件配合使用
模型本身不是要求规范或体系结构。 它是一种更清楚地表达这些内容的某些方面的工具，但并不是软件设计期间所需的所有概念都可以表达。 因此，模型应与其他通信方式一起使用，例如 OneNote 页面或段落、Microsoft Office 文档、Team Foundation 中的工作项或项目会议室墙上的便笺。 除了最后一项，所有这些对象类型都可以链接到模型的元素部分。
通常与模型一起使用的规范的其他方面包括以下内容。 根据项目的规模和样式，可以使用以下几个方面，或者根本不使用任何方面：
用户故事。 用户情景是与用户和其他利益干系人讨论的简短说明，介绍将在项目迭代中交付的系统行为的一个方面。 典型的用户情景开始“客户将能够...”。用户情景可能会引入一组用例，也可以定义以前开发的用例的扩展。 定义或扩展用例有助于使用户故事更加清晰。
变更请求 更正式项目中的更改请求与敏捷项目中的用户情景非常相似。 敏捷方法将所有要求视为对以前迭代中开发的更改。
用例说明。 用例表示用户与系统交互以实现特定目标的一种方式。 完整说明包括目标、事件的主要序列和替代序列，以及异常结果。 用例图有助于汇总和提供用例的概述。
场景。 方案对一系列事件进行了相当详细的描述，其中显示了系统、用户和其他系统如何协同工作，为利益干系人提供价值。 它可能采用用户界面的幻灯片放映或用户界面原型的形式。 它可以描述一个用例或一系列用例。
词汇表。 项目的需求术语表记录了客户用来描述他们世界的词汇。 用户界面和要求模型还应使用这些术语。 类图有助于阐明其中大多数术语之间的关系。 创建关系图和术语表不仅减少了用户和开发人员之间的误解，而且几乎总是暴露不同业务利益干系人之间的误解。
业务规则。 许多业务规则可以表示为需求类模型中关联和属性的不变性约束，以及序列图中的约束。
高级设计。 介绍主要部分及其组合方式。 组件、序列和接口关系图是高级设计的主要部分。
设计模式。 描述在系统的不同部分共享的设计规则。
测试规范。 测试脚本和测试代码的设计可以充分利用活动和序列图来描述测试步骤序列。 系统测试应以要求模型表示，以便在要求更改时轻松更改它们。
项目计划。 项目计划或积压工作定义何时交付每个功能。 可以通过说明它实现或扩展的用例和业务规则来定义每个功能。 可以直接在计划中引用用例和业务规则，也可以在单独的文档中定义一组功能，并在计划中使用功能标题。
在迭代规划中使用模型
尽管所有项目的规模和组织都不同，但典型的项目计划为两到六周之间的一系列迭代。 必须规划足够的迭代，以允许早期迭代的反馈用于调整后续迭代的范围和计划。
你可能会发现以下建议有助于在迭代项目中实现建模的好处。
随着每次迭代的临近，将焦点锐化
随着每次迭代的临近，使用模型来帮助定义要在迭代结束时交付的内容。
不要在早期迭代中详细建模所有内容。 在第一次迭代中，为用户术语表中的主要项创建类图，绘制主要用例的关系图，并绘制主要组件的图表。 请勿详细描述其中任何一项，因为细节将在项目后面更改。 使用此模型中定义的术语创建功能列表或主要用户情景。 将功能分配给迭代，以便在整个项目中大致平衡估计的工作负荷。 这些工作分配稍后将在项目中更改。
尝试在早期迭代中实现所有最重要的用例的简化版本。 在以后的迭代中扩展这些用例。 此方法有助于降低在项目开发过程中，过晚发现需求或体系结构中的缺陷以至于无法采取任何补救措施的风险。
在每次迭代结束时，举行要求研讨会，详细定义将在下一次迭代中开发的要求或用户情景。 邀请可以决定优先级的用户和业务利益干系人，以及开发人员和系统测试人员。 允许用三个小时来确定为期两个星期的迭代周期的要求。
研讨会的目的是让每个人都同意在下一次迭代结束时将完成哪些任务。 使用模型作为工具之一来帮助阐明要求。 研讨会的输出是迭代积压工作：即 Team Foundation 中的开发任务列表和Microsoft测试管理器中的测试套件。
在需求研讨会中，仅在需要为开发任务估算时讨论设计。 否则，请继续讨论用户可以直接体验的系统行为。 使要求模型与体系结构模型分开。
非技术利益干系人通常能够理解 UML 图，只需你提供一些指导。
将模型链接到工作项
在要求研讨会之后，详细说明要求模型的详细信息，并将模型链接到开发任务。 可以通过将 Team Foundation 中的工作项链接到模型中的元素来执行此作。
可以将任何元素链接到工作项，但最有用的元素如下所示：
- 描述业务规则或服务质量要求的注释。 有关详细信息，请参阅 模型用户要求。
将模型链接到测试
使用要求模型指导验收测试的设计。 在开发工作中同时创建这些测试。
若要了解有关此方法的详细信息，请参阅 从模型开发测试。
估计剩余工时
需求模型可以帮助估算项目的总大小，并与每次迭代的大小进行比较。 评估用例和类的数量和复杂性有助于估算所需的开发工作。 完成前几次迭代后，对所涵盖要求和仍要涵盖的要求进行比较可以大致衡量项目的其余部分的成本和范围。
在每个迭代的末尾附近，查看对将来迭代的要求分配。 在用例图中，在每次迭代结束时将软件的状态表示为子系统非常有用。 在讨论中，可以将用例和用例扩展从其中一个子系统移到另一个子系统。
抽象级别
模型具有一系列与软件相关的抽象。 最具体的模型直接表示程序代码，而最抽象的模型表示可能或可能不会在代码中表示的业务概念。
可以通过多种关系图查看模型。 有关模型和关系图的信息，请参阅 为应用创建模型。
不同类型的关系图可用于描述不同抽象级别的设计。 许多关系图类型在多个级别都很有用。 下表显示了如何使用每种关系图。
| 设计级别 | 图表类型 |
|---|---|
| 业务流程 了解系统将使用的上下文有助于了解用户从中需要的内容。 |
- 概念类图描述了业务流程中使用的业务概念。 |
| 用户要求 定义用户从系统需要的内容。 |
- 业务规则和服务质量要求可以在单独的文档中描述。 |
| 高级设计 系统的整体结构：主要组件及其组合方式。 |
- 依赖项关系图描述如何将系统构建为相互依赖的部分。 可以针对依赖项关系图验证程序代码，以确保它符合体系结构。 |
| 代码分析 可以从代码生成关系图。 |
- 依赖项关系图显示类之间的依赖关系。 可以根据依赖项关系图验证更新的代码。 - 类图显示代码中的类。 |
外部资源
相关内容
注释
文本模板转换组件作为 Visual Studio 扩展开发工作负载的一部分自动安装。 还可以从 Visual Studio 安装程序的 “单个组件 ”选项卡，在 SDK、库和框架 类别下安装它。 从“单个组件”选项卡安装建模 SDK 组件。