编写软件架构文档说明，第 2 部分: 开发系统上下文

出处：http://www.ibm.com/developerworks/cn/architecture/ar-archdoc2/

引言

本系列的 第 1 部分 说明了采用编写软件架构文档说明的规范方法的重要性。其中还介绍了用于捕获典型软件开发流程的体系结构构件的常用机制。本文将继续此内容，重点讨论第一个重要体系结构构件：系统上下文。通过关系图和信息流记录系统上下文信息。

从较高的抽象级别而言，您应该考虑系统的两个视图：

• 在最常见的视图中，软件或应用程序表示为一组体系结构构建块（也称为概述体系结构）。
• 第二个视图是更多面向外部的视图。将系统视为要作为黑盒设计的元素。围绕系统的是访问系统的用户和角色及其访问上下文。关系图还应该描述系统要与之进行交互来执行特定功能的每个外部系统。

  系统上下文的黑盒表示形式表明软件依赖于外部系统，并说明了如何将依赖关系考虑到总体解决方案的体系结构中。

系统上下文在软件架构中的角色

系统上下文是系统的软件架构中的基础构件。开发系统上下文视图非常重要，因为此视图将作为回溯到业务上下文、展开功能和操作体系结构的机制使用。我们将提供业务上下文的简单概述，以了解为何可跟踪性对其如此重要。

业务上下文

提供系统需要如何与其他企业交互的组织视图，描述软件所在的业务生态系统。此视图在非常依赖外部组织的系统中特别重要。这个高级视图并不区分各个用户和角色。相反，它将其描述为与业务交互的用户社区。

例如，如果您在为某所大学构建软件，业务上下文可能将这所大学描述为中央实体，并描述对以下实体的依赖关系：

• 政府，向其申请资金和获得及执行法律法规遵从性检查。
• IT 行业，申请研究项目和教育服务。
• 用户社区，大学将为其提供硬件和软件支持。
• 联盟中的其他大学，获得学生历史记录。

系统上下文

使用业务上下文标识外部系统。标识了外部组织后，系统上下文将标识具体的 IT 系统和应用程序，系统将需要与其进行交互来接收和发送信息。要对每个外部组织进行相同的处理，所获得的全部信息一起构成了系统级别的视图，可表明需要将哪些外部系统纳入整体解决方案的范畴内。

系统上下文提供了业务上下文的分解，并提供了对业务上下文信息的可跟踪性。

系统上下文帮助标识构建完整的解决方案所需的一些主要体系结构构件。待构建系统与每个外部系统之间的信息流为信息模型提供了关键输入。外部系统的特征决定了对可促进技术集成的适配器的需求。信息流还表示从体系结构而言非常重要的活动，这些活动可以回溯到业务流程模型，而后者是表示系统需求的一个主要部分。

不能低估系统上下文的重要性。它在开发应用程序系统的软件架构中扮演着重要的角色。我强烈建议对系统上下文加以记录。

记录系统上下文

记录系统上下文的第一步是创建系统上下文关系图。如 图 1 中所示，系统上下文关系图具有以下特点：

• 将待构建系统表示为黑盒
• 描述其与外部实体（系统和最终用户）的交互
• 标识系统和外部实体间的信息和控制流

外部实体并不一定是企业范围外的系统。现有企业应用程序或数据库也可以在系统上下文中表示为外部实体。我建议专门划出一个部分来描述系统上下文关系图，并使用意义明确的名称，如“系统上下文关系图”等。

系统上下文关系图

图 1 显示了银行应用程序的系统上下文关系图。

图 1. 系统上下文关系图

使用每个构件详细的示例补充关系图的想法很不错。

图 1 中部框中的系统使用的是通用名称。当然，您可以使用表示要构建的应用程序的名称来对其进行替代。

构件归为以下几类：

用户和角色

这些构件表明与系统交互的用户和角色。尽管并没有硬性的规定，但 IT 行业通常的做法是将用户和角色显示在系统的左侧。我建议您在主要部分下创建一个小节来记录用户和角色。用户通常按角色进行归类。

例如，在图 1 中有两种类型的角色：关系经理和风险经理。每个角色的文档应该包含以下内容：

• 角色及其用于访问系统的上下文的描述。
• 角色用于访问系统的信息的描述。
• 给定角色中的典型用户在给定单位时间内执行的事务量。

通道

用户将使用不同的通道来访问系统。我建议创建独立的小节来记录此通道信息。每个通道的文档应该至少捕获以下内容：

• 通道及通常使用此通道与系统交互的角色和用户的类型。例如，交互式语音响应（Interactive Voice Response，IVR）、浏览器、智能电话等等。
• 通道支持的网络和带宽，如 T1 线、8.02 11g、部分 T3 等。
• 用于在系统之间发送和接收数据的访问协议，如 HTTP、套接字、IVR 等等。

外部系统

您必须记录系统在执行所需的功能时与之交互的外部系统。在标识需要考虑解决方案范围的外部系统时，需要进行大量的分析工作。业务分析人员和领域专家通常要参与此分析工作。您还应该充分地记录此分析工作的结果。

建议专门使用一个小节记录外部系统。其中至少应该捕获：

• 外部系统的描述性概述，包括关于系统相对于要构建的系统的位置的背景信息。

  例如，外部系统可能放置在企业内部网内，放置在业务定义的外部网中或者放置在 Internet。

• 与外部系统交互所需的访问协议，如安全 HTTP、套接字、专用访问机制等等。
• 外部系统支持或期望的数据格式（为了促进集成）。
• 与外部系统交互所需的任何特定遵从性需求。
• 系统的非功能规范，如安全性、可用性、信息吞吐量等等。

并没有必要记录外部系统的所有非功能需求。仅仅记录可能会影响需要构建的系统的体系结构和设计的需求。

记录信息足够的情况下，前面的信息应该能提供系统上下文关系图很好的描述。不过，目前捕获的信息仅仅提供了系统上下文的静态视图，通过用户、角色、通道和外部系统进行表示。通过标识和捕获在系统和每个外部系统间交换的信息，可以提供系统上下文的动态视图。下一部分将讨论此信息流。

信息流

在该系统和外部系统、用户和通道间流动的信息是系统最基本的部分。信息可以传统批量或实时方式传送。将信息及其特征作为系统上下文的一部分加以记录在定义总体软件架构时极为重要。

信息流通常使用名词或动词短语表示。选择名词还是动词取决于个人偏好，但建议仅仅使用一种形式，而不是同时使用二者。我在示例中使用的是动词形式。对于所流动的每个信息，我建议至少应该记录以下构件集：

• 在系统和用户、通道及外部系统间流动的信息的描述。
• 将信息分类为批处理、实时或半实时类别。
• 每个单位时间必须支持的事务信息。
• 组成典型事务的数据类型。
• 每个事务通常涉及的数据量。
• 事务执行的频率。

正如前面所述，这些构件并不处理系统和外部系统间的交换序列。当两个系统中有信息流动时，系统间可能存在完成事务的信息交换序列。在这种情况下，还应该记录信息交换序列。

记录信息流具有多方面的重要性：

• 信息流标识将影响待构建软件的最终信息模型的重要信息。
• 它通过分析信息组成部分来帮助您了解外部系统所支持的数据格式。

  对于企业范围外的系统，数据格式通常与规定系统要支持的格式不同，这意味着两个交互系统还需要数据转换。

• 外部系统所支持的访问协议（网络和数据）可能与待构建系统将支持的协议不同。此协议差别带来了应用程序和系统集成的技术需求。这些需求通常通过选择技术适配器来加以处理。

  技术适配器可实现外部系统和待构建系统间的数据格式和访问协议差异的规范化。技术适配器的选择是支持要推出的系统的集成体系结构的一个重要方面。

• 业务流程建模是一种自底向上方法，用于进行需求收集和分析与了解业务或 IT 转换活动范围内的业务流程。

  流程分解工作标识组成较大的业务流程的一组子流程、活动或任务。有些活动或任务需要与外部系统进行交互或集成（如系统之间存在数据依赖关系的情况）。此类活动可以追溯到信息流投资组合中的一个或多个信息流定义。这可提供需求及其对外部系统的实现依赖关系间的关键可跟踪性。可跟踪性是高效且组织良好的软件开发生命周期的一项基本原则。

• 数据、协议和网络适配器是系统或应用程序的体系结构概述定义中的重要部分。从效果而言，外部系统的异构影响着体系结构的多个层（将在本系列下一篇文章中讨论）。

通过系统上下文关系图和信息流，您可以定义严格的系统上下文文档，这些文档在形成系统的软件架构方面非常重要。

结束语

在本文中，您了解了软件架构的系统上下文视图。系统上下文应该是作为系统体系结构一部分开发的第一个构件。您了解了开发全面的系统上下文文档的有效方式。本文还强调了记录系统上下文的重要性，因为它与典型的软件开发生命周期中开发的构件的可跟踪性相关。

请关注本系列的后续文章，其中将详细讨论一组用于记录其他体系结构构件的指导原则。