建立软件系统体系结构模型

建立软件系统体系结构模型

为了帮助确保您的软件系统或应用程序满足用户需求，您可以在 Visual Studio 旗舰版中创建模型来作为软件系统或应用程序的总体结构和行为的说明的一部分。还可以使用模型来描述在整个设计过程中使用的模式。这些模型可帮助您了解现有的体系结构、讨论更改以及明确传达您的意图。

模型可用于减少自然语言说明中出现的多义性，并帮助您和您的同事直观地显示设计和讨论备选设计。

应将模型与其他文档或讨论一起使用。模型本身并不表示体系结构的完整规范。

说明

可以将系统的体系结构分为两个区域：

∙高级设计。高级设计描述主要组件，并说明这些组件之间如何进行交互以满足每项需求。如果系统是大型系统，则每个组件可能具有自己的高级设计，以便显示这些组件是如何由多个更小的组件构成的。∙在整个设计过程使用的设计模式和约定。模式描述实现编程目标的特定方法。通过在整个设计过程中使用相同的模式，您的团队可以降低进行更改和开发新软件的成本。

高级设计

高级设计描述系统的主要组件，并说明这些组件之间如何进行交互以实现设计目标。以下列表中的活动与开发高级设计有关，但这些活动不一定按照特定的顺序排列。

如果您要更新现有代码，则可以先从描述主要组件开始。请先确保您了解对用户需求的任何更改，然后再添加或修改组件之间的交互。如果您要开发新系统，则可以从了解用户需求的主要功能开始。然后，您可以探究主要用例的交互序列，再将这些序列合并为一个组件设计。

对于上述每种情况，并行开发不同的活动并在早期阶段开发代码和测试会很有用。避免尝试在开始这些方面中的某个方面前完成另一个方面。通常，在您编写和测试代码时，相关需求和您对系统的最佳设计方法的理解会发生更改。因此，您应先了解需求和设计的主要功能并对其进行编码。在稍后的项目迭代中填充详细信息。

∙了解需求。任何设计的第一步都是要清楚地了解用户需求。

∙体系结构模式。您对系统的核心技术和体系结构元素做出的相关选择。

∙组件及其接口。您可以绘制组件图来显示系统的主要部件以及它们进行交互所使用的接口。每个组件的接口均包含您在序列图中标识的所有消息。

∙组件之间的交互。您可以为每个用例、事件或传入消息绘制序列图来显示系统的主要组件之间如何交互以实现所需响应。

∙组件和接口的数据模型。您可以绘制类图来描述在组件之间传递并存储在组件内部的信息。

了解需求

开发完整应用程序的高级设计的最有效方式是，将此高级设计与需求模型或用户需求的其他说明一起开发。

如果您正在开发的系统是大型系统中的一个组件，则可以将您的部分或所有需求体现在编程接口中。

需求模型提供以下基本信息：

∙提供的接口。提供的接口会列出系统或组件必须向其用户提供的服务或操作，无论其用户是实际用户还是其他软件组件。

∙必需的接口。必需的接口会列出系统或组件可以使用的服务或操作。在某些情况下，您可以将所有这些服务设计为您自己的系统的一部分。在其他情况下，尤其是在您设计可以在多个配置中与其他组件组合的组件时，将基于外部考虑因素来设置必需的接口。

∙服务质量需求。系统必须实现的性能、安全性、可靠性以及其他目标和约束。

需求模型是从系统用户的角度进行编写的，无论系统用户是实际用户还是其他软件组件。系统用户不了解系统的内部工作原理。相比之下，体系结构模型旨在说明内部工作原理，并演示其如何满足用户需求。

将需求模型和体系结构模型保持分离很有用，因为这样做更易于与用户讨论需求。此外，还可以帮助您在保持需求不变的同时，重构设计并考虑备选体系结构。

可通过以下两种可选方法来分离需求模型和体系结构模型：

∙将这两类模型置于相同解决方案的不同项目中。二者将在 UML 模型资源管理器中显示为单独的模型。

不同的团队成员可以并行处理这些模型。可以在模型之间创建有限类型的跟踪。

∙将这两类模型置于相同 UML 模型的不同包中。这样一来，便能够更轻松地跟踪模型之间的依赖项，但会阻止多个用户同时处理该模型。此外，将非常大的模型加载到 Visual Studio 中需花费较长的时间。因此，这种方法不太适用于大型项目。

应放入需求模型或体系结构模型中的详细信息量取决于项目的规模以及团队的大小和分布。参与短期项目的小型团队可能只需绘制业务概念和某些设计模式的类图草图即可；而分布在多个国家/地区的大型项目将需要更多的详细信息。

体系结构模式

在开发过程的早期，您必须选择设计所依赖的主要技术和元素。必须做出以下几个方面的选择：

∙基础技术选择，例如，数据库和文件系统之间的选择、联网应用程序和 Web 客户端之间的选择等。∙框架选择，例如 Windows Workflow Foundation 和 Entity Framework 之间的选择。

∙集成方法选择，例如企业服务总线和点对点通道之间的选择。

这些选择经常由服务质量需求（如范围和灵活性）确定，可以在获知详细需求之前做出这些选择。在大型系统中，硬件和软件的配置是密切相关的。

您所做的选择会影响您使用和解释体系结构模型的方式。例如，在使用某个数据库的系统中，类图中的关联可能表示该数据库中的关系或外键；而在基于 XML 文件的系统中，关联可能指示使用 XPath 的交叉引用。在分布式系统中，序列图中的消息可以表示传输中的消息；在独立的应用程序中，这些消息可以表示函数调用。

组件及其接口

本节中的主要建议如下所示：

∙创建组件图以显示系统的主要部件。

∙绘制组件或其接口之间的依赖项以显示系统的结构。

∙使用组件上的接口来显示每个组件提供或需要的服务。

∙在大型设计中，可以绘制独立的关系图以将每个组件分解成多个更小的部件。

本节的其余部分将详细阐述以上几点。

组件

体系结构模型的中心视图是一些组件图，它们显示系统的主要部件及其相互依赖关系。

大型系统的典型组件图可能包含类似于以下组件的组件：

∙演示。可提供对用户的访问的组件，该组件通常在 Web 浏览器上运行。

∙Web 服务组件。提供客户端和服务器之间的连接。

∙用例控制器。引导用户完成每个方案的各个步骤。

∙业务核心。包含基于需求模型中的类的类、实现主要操作以及施加业务约束。

∙数据库。存储业务对象。

∙日志记录和错误处理组件。

组件之间的依赖项

除组件本身以外，您还可以显示组件之间的依赖项。两个组件之间的依赖项箭头显示一个组件的设计发生更改会影响另一个组件的设计。由于一个组件使用的服务或函数是由另一个组件直接或间接提供的，因此该情况会经常出现。

结构良好的体系结构会对依赖项进行清楚地排列，其中满足以下条件：