在开发过程中使用模型
在 Visual Studio 旗舰版中，可以使用模型帮助您理解和更改系统、应用程序或组件。 模型可以帮助您可视化系统的工作环境、阐明用户的需求、定义系统的体系结构、分析代码以及确保代码符合需求。
请参见 视频的通道 9:通过建模提高体系结构。
如何使用模型
模型可以通过以下几种方式为您提供帮助：
绘制建模图可帮助您阐明与需求、体系结构和高级设计相关的概念。 有关更多信息，请参见用户需求建模。
使用模型可帮助您揭示需求中的不一致之处。
与使用自然语言相比，使用模型进行交流有助于在传达重要概念时产生更少的歧义。 有关更多信息，请参见建立软件系统体系结构模型。
有时，可以使用模型生成代码或其他项目，如数据库架构或文档。 例如，从模型生成 Visual Studio 旗舰版的建模组件。 有关更多信息，请参见基于模型生成和配置应用程序。
可以在各种过程（从极度敏捷的过程到高度程序化的过程）中使用模型。
.gif "Dd409423.collapse_all(zh-cn,VS.110).gif")
使用模型来减少多义性
与自然语言相比，建模语言产生的多义性更少，可用于表达软件开发过程中通常所需的想法。
如果项目中有一个小型团队遵循敏捷开发做法，则可以使用模型帮助您阐明用户情景。 在与客户谈论其需求时，与编写图文场或原型代码相比，创建模型可以更快地提出涉及更广泛的产品领域的有用问题。
如果项目很大而且涉及到世界各个地方的团队，则与使用纯文本相比，使用模型可帮助您更有效地传达需求和体系结构。
在这两种情况下，创建模型几乎始终可显著减少不一致和多义性。 不同的利益干系人对系统工作的业务环境的理解往往会不同，并且不同的开发人员对系统的工作方式的理解往往也会不同。 将模型作为讨论的焦点通常会揭示这些差异。 有关如何使用模型减少不一致的更多信息，请参见用户需求建模。
将模型与其他项目一起使用
模型自身不是需求规范或体系结构。 模型是一个工具，可用于更清楚地表达这些事项的某些方面，但并不能表达软件设计过程中所需的所有概念。 因此，应将模型与其他交流方式结合使用，例如 OneNote 页面或段落、Microsoft Office 文档、Team Foundation 中的工作项或贴在项目办公室墙上的不干胶便笺。 除最后一项外，上述所有对象类型都可以链接到模型的元素部分。
通常与模型一起使用的规范的其他方面包括以下内容。 您可能会使用这些方面中的某几项，也可能根本不使用任何一项，这取决于项目的范围和样式：
用户情景。 用户情景是对有关将在某个项目迭代中交付的系统行为的某一方面的简短说明，此说明需要经过与用户和其他利益干系人一起讨论得出。 典型的用户情景以“客户将能够…”作为开头。用户情景可以引入一组用例，也可以定义先前已开发的用例的扩展。 定义或扩展用例有助于使用户情景更清晰。
更改请求。 更正式的项目中的更改请求与敏捷项目中的用户情景十分相似。 敏捷方法会将所有需求视为对以前的迭代中已开发的内容的更改。
用例说明。 用例表示用户为实现特定目标而与系统进行交互时所采用的某种方式。 完整的说明包括目标、主要和备选事件序列以及异常结果。 用例图有助于对用例进行汇总和概述。
方案。 方案是对一系列事件进行的相当详细的说明，演示了系统、用户和其他系统将如何协作以便为利益干系人提供价值。 方案可能采用的形式为用户界面的幻灯片放映或用户界面的原型。 方案可以描述一个用例或一系列用例。
词汇表。 项目的需求词汇表描述客户讨论其领域时使用的词语。 用户界面和需求模型也应使用这些术语。 类图可以帮助阐明其中的大多数术语之间的关系。 通过创建关系图和词汇表，不仅可以减少用户和开发人员之间的误会，而且几乎总是会揭示不同业务利益干系人之间的误会。
业务规则。 可以将许多业务规则表达为需求类模型中的关联和特性的固定约束以及序列图的约束。
高级设计。 描述主要部分及其结合方式。 组件、序列和接口图都是高级设计的主要部分。
设计模式。 描述在系统的各个部分之间共享的设计规则。
测试规范。 测试脚本和测试代码的设计可以有效地使用活动和序列图来描述测试步骤序列。 应按照需求模型来表达系统测试，以便在需求发生更改时可以轻松地更改系统测试。
项目计划。 项目计划或积压工作将定义交付每项功能的时间。 可以通过指明每项功能实现或扩展的用例和业务规则来定义相应的功能。 可以在计划中直接引用用例和业务规则，也可以在单独的文档中定义功能集，并在计划中使用功能标题。
在迭代规划中使用模型
虽然所有项目的范围和组织结构各不相同，但可以将一个典型项目作为一系列迭代（时长为两周到六周）进行计划。 一定要计划足够多的迭代，以便能使用来自早期迭代的反馈来调整后续迭代的范围和计划。
您可能会发现，以下建议对于帮助您认清在迭代项目中建模的好处很有用。
随着每次执行迭代逐渐聚焦
随着每次执行迭代，使用模型帮助定义在迭代结束时要交付的内容。
不要在早期迭代中对所有内容进行详细建模。 在第一次迭代中，针对用户词汇表中的主要项创建一个类图，绘制主要用例的关系图以及绘制主要组件的关系图。 不要详细描述任何上述内容，这是因为详细信息以后会在项目中发生更改。 使用此模型中定义的术语来创建功能或主要用户情景的列表。 为迭代指派功能以使整个项目内的估计工作负荷基本达到平衡。 这些指派以后会在项目中发生更改。
尝试在早期迭代中实现所有最重要的用例的简化版本。 在后续迭代中扩展这些用例。 此方法有助于减少因过晚发现项目中的需求或体系结构所存在的缺陷而导致无法进行任何补救的风险。
在每次迭代快结束时，召开一个需求研讨会，详细定义在下一次迭代中将要开发的需求或用户情景。 应邀请可以决定优先级的用户和业务利益干系人，以及开发人员和系统测试人员参加此次会议。 可以花三个小时的时间来定义迭代（时长为 2 周）的需求。
此研讨会的目的是让每个人就下一次迭代结束时将完成的内容达成一致意见。 可使用模型作为工具之一来帮助阐明需求。 此研讨会的最终结果是一个迭代积压工作：即，一个包含 Team Foundation 中的开发任务和 Microsoft 测试管理器中的测试套件的列表。
在需求研讨会上，仅在为确定估计的开发任务而需要做的工作范围内讨论设计。 另外，应着重讨论用户可以直接体验到的系统行为。 将需求模型与体系结构模型分离。
在您的指导下，非技术利益干系人通常可以完全理解 UML 关系图。
将模型链接到工作项
在开完需求研讨会之后，详尽说明需求模型的详细信息，并将该模型链接到各项开发任务。 可以通过将 Team Foundation 中的工作项链接到该模型中的各个元素来执行此操作。 若要了解如何执行此操作，请参见链接模型元素和工作项。
可以将任何元素链接到工作项，但以下元素是最有用的元素：
用例。 可以将一个用例链接到将实现该用例的开发任务。
用例扩展。 如果迭代中只实现某个用例的一个方面，则可以将该用例分成一个基用例与一个或多个扩展。 扩展是一些通过 «extend» 关系链接到基用例的用例。 有关用例扩展的更多信息，请参见UML 用例图：参考。
用于描述业务规则或服务质量需求的注释。 有关更多信息，请参见用户需求建模。
将模型链接到测试
使用需求模型可指导验收测试的设计。 在开发工作进行的过程中创建这些测试。
若要了解有关此技术的更多信息，请参见基于模型开发测试。
估计剩余工作
需求模型可以帮助估计与每个迭代大小相关的项目总大小。 评估用例和类的数量和复杂程度可以帮助您估计所需的开发工作。 在您完成前几次迭代后，通过将已完成的需求和仍需完成的需求进行比较，可以估算出项目剩余部分的成本和范围。
在每次迭代快结束时，评审将来迭代的需求指派。 将每次迭代结束时软件的状态表示为用例图中的一个子系统会很有用。 在进行讨论时，可以将用例和用例扩展从其中的一个子系统移动到另一个子系统。
抽象级别
模型具有与软件相关的抽象范围。 最具体的模型直接表示程序代码，最抽象的模型表示业务概念（代码中可能表示也可能不表示这些概念）。
可以通过几种类型的关系图来查看模型。 有关模型和关系图的信息，请参见开发软件设计模型。
不同类型的关系图对于按照不同的抽象级别来描述设计会很有用。 许多关系图类型对于多个级别来说很有用。 此表显示可以如何使用每种类型的关系图。
设计级别 |
关系图类型 |
|---|---|
业务流程 了解系统的使用环境可帮助您了解用户对于系统的需求。 |
|
用户需求 有关用户针对系统的需求的定义。 |
|
高级设计 系统的总体结构：主要组件以及这些组件的组合方式。 |
|
设计模式 在设计的所有部分中使用的约定和用于解决设计问题的方法 |
|
代码分析 可以从代码生成多种类型的关系图。 |
|
外部资源
类别 |
链接 |
|---|---|
视频 |
|
论坛 |
|
博客 |
|
技术文章和日志 |
The Architecture Journal - Issue 23: Architecture Modeling and Processes（体系结构日志 - 问题 23：体系结构建模和流程） |
其他网站 |
MSDN Architecture Center（MSDN 体系结构中心） |
.gif "链接到视频")