简介

本文主要关注 IT 系统非功能性方面的图形和形式表示，我们以非功能性需求（NFR）开始，因为这些表示是由架构师执行的。

在展示一些可用符号以及如何在 The Open Group Architecture Framework（TOGAF）中使用或重用所表达的概念之前，我们这里将引用来自 Alfred North Whitehead 的 An Introduction to Mathematics 中的一段摘录，因为它解释了我们为什么需要在本文中特别关注这些符号：

通过消除所有不必要的工作，一个好的符号可以使您将精力集中到更加高级的问题上，并有效地提高人的心智。另一个问题是模型：我们使用符号表示模型的形式。

模型对架构师的工作非常重要。架构师主要负责系统设计的完整性。模型使他们能够表示并定义系统，系统的治理及实现方式。

支持多种视图（比如功能、性能、可用性、管理）的模型对于设计复杂系统有重大的作用。这些视图需要以一种一致且易于管理的方式彼此关联起来，并与系统模型建立联系。集成的模型需要尽可能地保持域独立性（但是本文主要关注软件密集型系统）。

最后，需要使用诸如 UML 的形式语言（或 IBM 的 ADL 或 OMG 的 SysML）描述模型。总而言之，建模是由以下因素驱动（参见 参考资料 中的 Maier and Rechtin，第 8 章，获得有关此内容的详细讨论）：

与客户、设计团队，以及实施团队共享和沟通的需要

跨各种视图、层和需求等维护设计的整体完整性的需要

在本文的其余部分中，我们将介绍两种主要的建模语言和符号，一种主要用于 IBM 内部，另一种主要用于系统工程社区。我们将了解它们如何支持架构师来表示非功能性需求，以及如何将其整合到整体系统设计中。它们提供了输入并帮助设计支持 NFR 所需的 TOGAF ArchiMate 扩展指南。

IBM 的系统描述标准

IBM 系统描述标准（SDS），以前称为架构描述标准（ADS），是一组面向符号、术语和语义的约定，用于描述 IBM 架构师使用的 IT 系统的架构（参阅参考资料中的 A Standard for Architecture Description，获得更详细的演示）。

系统描述标准概述

无论什么情况下，SDS 都遵循 OMG UML 概念和符号，并利用 IBM 在大型 IT 项目的经验。在实践中，此类项目包括关注以下两种设计和开发的工作组：

应用程序设计和开发，主要关注以下用途：

• 分解 IT 系统的复杂性，从而使开发人员以相对独立的形式分析和设计组件

基础设施设计和开发，主要关注以下用途：

• 分析功能以识别所需的技术组件
• 协助分析服务级别的需求，从而设计出服务交付方式
• 为物理计算机系统规范提供基础，在其中 IT 系统会在这类系统上运行并将组件映射到这些计算机系统

通过识别架构的两个主要概念，SDS 和相关的概念可以反映这种关注点分离：

• 功能性观点
• 操作性观点

功能性观点关注的是描述 IT 系统的功能，主要与下列因素有关：

• 软件组件（应用程序和技术）的结构和模块化
• 组件（包括协议）之间的交互
• 组件提供的接口及其使用
• 动态行为，通过组件之间的协作表示

操作观点关注的是描述如何跨不同地理位置系统结构部署 IT 系统的功能。它主要与以下因素相关：

• 表示系统的拓扑结构（硬件平台、位置、外部系统等等）
• 描述运行的内容和位置，软件和数据被放在拓扑结构中的哪些位置
• 为 IT 系统的服务管理方面的定义（容量规划、软件描述、备份和恢复）提供基础。

下列图片展示了使用 SDS 表示的系统的视图。

图 1. SDS 表示示例

SDS 中的非功能性需求

在 SDS 中，非功能性需求被定义为 IT 系统必须满足的质量需求或约束。它们会在将部署设备 组（合并到单个包中的功能性组件集）放置到节点（软件执行的平台）时和将节点收集到区域 时（需要满足同构非功能性需求的区域）产生主要的影响。

在 SDS 中，NFR 可以粗略划分为两个类别：

1. 服务级需求（性能、可用性和安全性）
2. 系统品质（维护能力）

NFR 可以被连接到任何组件或节点。在 SDS 中，未针对 NFR 定义任何图形标准（符号）。NFR 将以无格式文本的形式描述。

OMG 的 SysML 规范

SysML 支持大量复杂系统的规范、分析、设计、检验和验证。这些系统可以包括硬件、软件、信息、流程、人员和设施。SysML 计划的起源可以追溯到，International Council on Systems Engineer（INCOSE）的 Model-Driven Systems Design 工作组在 2001 年 1 月所作出的一项战略决策，该决策是用于针对系统设计应用程序定制 Unified Modeling Language（UML）。

与 SDS 类似，SysML 重用了 UML 2.1 的子集并提供了额外的扩展，从而满足系统设计应用程序的更多需求。

图 2. SysML 图结构

由于 SysML 采用 UML 2.1 作为其基础，使用 SysML 建模的系统工程师和使用 UML 2.1 建模的软件工程师将能够合作创建软件密集型系统的模型。这改进了所有参与系统开发流程的各个利益方的沟通，并促进了各种建模工具之间的互操作性。SysML 预计将针对建模域特定应用程序进行定制，如汽车、航空、通信和信息系统。

建模多个 NFR

SysML 提供了工具来捕捉所谓的基于文本的需求，然后将它们集成到系统模型中。基于文本的需求可以充当一种通用的工具，使架构师可以对几乎任何需求进行建模。实际上，在 SysML 中通过用例对功能性需求建模，和 UML 一样，非功能性需求是通过基于本文的符号进行建模。

将基于文本的需求集成到模型中，可以使架构师精确地跟踪它们对系统组件的影响。在 SysML 中，类似的需求通常被收集到一个规范 中。规范在软件包 中通常显示为树型。每个需求或规范都可以链接到其他需求和规范，或者模型元素，进而可以是组件、测试用例等。我们在 ArchiMate 的建议扩展中采用了相同的方法。

非功能性需求表示的一个示例

在 SysML 中，我们通过两种不同的方式表示基于文本的需求：

• 需求图
• 需求表（用于表示需求）和指标（用于表示需求和其他项目之间的关系）。

因为我们关注的是图形表示，因此我们此后将只关注图形。然而，表和指标也非常有用，特别是在处理大量需求的情况下。这两者实现起来也更简单，可作为关系数据库中存储的数据的接口。

我们不会在 Requirement 图中进行详细展示，而是给出一个简单的示例，希望能够传达 SysML 中的需求管理的特点。该例子来自 OMG 的非规范性示例（参阅参考资料），该示例描述了混合 SUV 的设计（支持多用途车辆）。我们对主要的内容点进行了总结，严格遵循引用的 OMG 文档中的描述（稍作修改）。

车辆系统规范包含若干个 NFR，以基于本文的需求的方式进行管理。它们是称为 HSUV Requirement 包的组件。图 3 展示了需求的分解内容。其中一些需求被突出显示，
包括要求车辆满足排放标准的需求，为了便于说明而进行了扩展。包含（十字准线）关系是指将一项复杂的需求分解为几个更简单的需求的过程。

图 3. HSUV 规范树示例

图 4 展示了需求的派生（derivation）和基本原理（rationale）。从最底层需求派生出的一组新需求，并显示在图中。可能需要借助其他模型元素来开发一个派生需求，这些模型元素可以通过一个 ?refinedBy? 关系关联。例如，注意 PowerSourceManagement 如何通过 HSUVOperationalStates 模型优化。还要注意基本原理是否可以连接到 ?deriveReqt? 关系。

图 4. SysML 需求派生

最后，我们看到 SysML 如何使我们能够将需求与其他模型元素建立联系。下一个图建模了 Acceleration 需求。上图给出的 refine 关系展示了 Acceleration 需求如何通过一个具有类似命名的用例进行精调。Power 需求通过 PowerSubsystem（系统架构的一个组件）满足，而 Max Acceleration 测试用例则对 Acceleration 需求进行检验。

图 5. SysML 需求满意度和检验

现在，让我们看看这些概念如何引入到 EA 框架中，如 ArchiMate 中提供的框架。

在后文中，我们不会关注系统的功能性内容（系统执行的职能），而是关注系统如何进行组织以执行此项工作。事实上，对于模型中的并行架构，我们认为它完全与功能性组件架构分离，并且几乎完全受影响系统 NFR 的驱动。

针对非功能性需求（NFR）采用的 TOGAF ArchiMate 方法

ArchiMate 是由 Open Group 所发起的建模语言，与著名的 TOGAF 企业架构框架配合使用。ArchiMate 元素被划分为结构性和行为性（动态）类别，并分为三个层：业务、应用程序和技术。每个层使用由下面的一层公开的服务。可以在层内部或层之间定义特定于 EA 利益相关方之一的需求的观点。

ArchiMate 限制

ArchiMate 1.0 规范根本没有提到非功能性 一词。

在 ArchiMate 2.0 规范中，惟一提及非功能性方面是在下面的语句中：

“对于外部用户，只有（服务的）这项已公开的功能和价值以及非功能性方面，如服务的质量、成本等，是相关的。这些内容可以在合同或服务水平协议（SLA）中指定。”

该方法还建议，通过使用 “配置文件”（由模型元素的属性组成）可以向模型添加额外的观点（如性能）。

这将生成这样一个数据结构，实际上是 “……与 ArchiMate 语言分离，但是可以动态地结合概念或关系”（ArchiMate v2）

然而，就非功能性内容对于企业 IT 架构的重要性而言，我们觉得这种方法严重不足。特别是，它缺少最基本的图形建模功能和标准化。

反之，我们建议使用 ArchiMate 2.0 的 Model Extension 机制来将 Nonfunctional Aspects Metamodel 添加到基本的 ArchiMate 规范中。

建议的 TOGAF 模型扩展

Nonfunctional Aspects Metamodel（此后将使用更实用的术语：操作性）包含以下几个模型元素（图中的白色部分）：

• 非功能性需求
• 应力情况（Stress case）
• 区域
• 系统
• 架构模式
• 技术组件
• 技术交互

大多数这些概念及其定义借鉴自 SDS R3。此外，需求、区域、系统、组件 和交互性是对 ArchiMate 基本模型中已使用元素的扩展，而应力情况 和架构模式 大多是新的概念。

图 6. 操作方面模型

在我们的模型中，NFR 来自于某个业务角色的需求。所有 NFR 都来自于业务需求，它们背后是一个可识别的业务理由（参阅参考资料引用的 The operational context diagram）。例如，支持银行柜员的系统不得停运超过 3 分钟；否则，排队等候的客户将越来越多，使客户对 “银行体验” 感到不满，即使实际办理业务所用的时间很短。

再举一个例子，同样来自于公司律师要求执行的某项法律或法规，或来自于 CFO 希望避免财务损失，或来自于安全人员对公司关键信息的保护需求会带来某项安全需求（如对关键数据进行加密）。

业务 NFR 可能来自于应用程序特定或技术特定的 NFR。例如，某个维护性需求，或者使应用程序变得易于维护的需求，可能来自于需要降低应用程序维护预算的愿望，或者来自任务分配时能够做到独立于供应商的愿望。

NFR 可以实现通过一组同类需求识别区域。这种区域概念被实现为 ArchiMate 分组关系的扩展。

例如，前面提到的不中断需求（“系统停运不应超过 3 分钟”）将定义一个区域，其中所有的模型元素都将保持持续可用性。注意，区域概念适用于 ArchiMate 模型的所有三个层：共享相同需求集（属于相同区域）的业务功能、应用程序概念和基础设施服务。

比较熟知的例子就是安全性区域：互联网区域、DMZ、受保护 LAN 和内部 LAN。然而，在一个复杂系统中，可能同时存在许多类型的区域：关键业务连续区域（RTO 接近零），关键数据区域（RPO 接近零），敏感数据区域（所有不能由操作人员访问的加密数据，到未加密的图像）等等。

如早期文章所述，生产中的 IT 环境受到来自许多相互影响的应激因子组合的压力。在真实的生产运营中，同一时间出现的 NFR 可能共同形成几种应力情况（应力条件）。

应力情况是 IT 环境（或部分 IT 环境）的真实负载的表示，尽管静态负载（家具重量、人员和积雪）和动态负载（如风）是要求钢和混凝土建筑的负载（参阅参考资料中引用的 IBM Views and Viewpoints Framework for IT Systems 简介）。

虽然这一概念更适用于应用程序和技术的组合，但是它也适用于应用程序层，因为可能需要在应用程序架构中引入修改（如，在不同位置复制组件以将流程靠近数据），从而处理特定的条件（操作上下文图形）。

下面是应力情况的一个例子：对于最常见的操作，柜员接口的系统响应时间必须低于两秒，同时可有 20.000 名柜员处于活跃状态。

注意，在开发期间，这种应力情况必须通过结合两个不同的测试用例（一个可扩展性测试和一个性能测试）来进行测试。另一方面，每个应力情况都可与一个特定的测试环境关联，这意味着一个独特的系统配置集和数据。

应力情况被实现为 ArchiMate Business Contract 元素的扩展。

为了简化区域和应力情况到 IT 环境的高级映射，我们将使用一个常见的概念，即系统。

我们将系统建模为 ArchiMate Application Collaboration 元素的扩展（因为技术层中缺乏类似的元素），但是它具有技术和应用程序的双重意义。系统可以公开应用程序接口和基础设施接口。

系统的应力条件最终会影响系统的所有或部分元素。例如，在预计的并发用户高峰期，柜员支持系统必须实现 2 秒的响应时间。

对于系统，与区域的映射可能是局部的，就这一点来说，只有多用途系统的特定部分（子系统）才会受某些需求的影响，并需要进行区域划分。例如，柜员系统可以包含两个子系统：柜员工作台和中央服务器。可能的情况是，为了确保流程的连续性，只需要将服务器放到高可用性区域，因为柜员的初始工作台停止工作后，她只需要移动到下一个柜台即可继续执行流程处理。

从技术上讲，系统被构建为架构模式，可以组织并控制技术组件。该架构模式通常是描述系统或子系统时首先提到的属性：“它是一个 Web 应用程序”，或者 “它是一个 RAC 集群”，或者 “它是一个门户”……

架构模式是 ArchiMate 对应用程序和技术层的 Application Collaboration 元素的扩展。它可以是应用程序服务（一种应用程序架构模式）的实现或技术服务（一种技术架构模式）的实现。

在执行特定的行为（可以通过 ArchiMate 交互描述）时，架构模式将对技术组件进行协调。

架构模式的例子包括服务器端、无状态服务、数据库集群、水平扩展服务器、基于队列的系统、REST 系统等等。

技术交互是对应用程序和技术层的 ArchiMate 的 Application Interaction 元素的扩展。它表示某个架构模式的动态行为。

技术组件被建模为针对应用程序和技术层的 ArchiMate 组件 元素扩展。

应用程序技术组件可能会或可能不会通过功能性 应用程序组件实现，因为保持操作视图并行运行，并与功能视图分离可能是有意义的。

另一方面，一种技术的技术 组件可能由多个基础设施元素组成。例如，技术组件 “DB 集群的节点” 是由系统软件（关系数据库管理系统，即 RDBMS）、基础设施节点（服务器）、设备（存储设备）、网络（与同一集群中的其他节点进行通信）和公开的接口组成的复杂组合。

在一个系统中，技术组件可以由一个或多个架构模式使用。

当然，最终的操作面取决于模型技术元素的特点：CPU 速度、内存大小、可用存储、传输速度等等。

实际上，这些都代表了我们的模型中的技术组件的能力。就这一点而言，每个技术组件都可以与其非功能性特点的 ArchiMate 2.0 配置文件 相关联。

映射到业务域元素

如果您曾与某个商人谈过 “业务”，您肯定提到过诸如市场条件、竞争、营销策略、现金流和债务等内容。

所有这些内容都不会体现在企业架构的业务层中。EA 的重点是业务运营的方式，即它的处理流程。因此，一个 EA 模型实际上是一个业务运营模型。就这点而言，它主要是业务的非功能性需求的结果。

功能性和非功能性需求是对一个或多个行为者在执行特定角色时的业务需求的表达。例如，银行职员在作为柜员处理排队客户业务，与处理后勤工作如查看某人信用卡以处理贷款申请，这两种情形下的需求非常不同。

因此，业务功能及其实现流程可能归属于特定的 NFR 区域。例如，在银行柜台执行的所有操作都要满足 “服务连续性” 这一关键需求，这是银行柜员需要满足的要求。

映射到应用程序域元素

在应用程序域中设想应用程序系统的最佳方式是考虑它的 System Context 图。系统是一个能够向一些明确识别的业务人员交付特定应用程序功能集的对象。

应用程序功能属于与其对应业务功能相同的 NFR 区域。因此，一个系统可能会跨越多个 NFR 区域。

系统的操作元素、架构模式和技术组件属于低层（技术）服务的特权客户，也就是说，应用程序操作视图是识别并跟踪与底层硬件关系的最佳方式。

映射到技术域元素

区域 和系统 的概念在基础设施领域比较常见，因为它们通常与物理实体和物理布局有关。在技术领域，新的模型元素，即架构模式 和技术组件 用于强调基础设施的概念视图，以作为特定业务需求的支持元素。

例如，考虑一个数据库（DB）集群。我们可能拥有纯粹的主动-被动 DB 集群，基于共享存储，这将确保没有数据丢失（恢复点目标，或 RPO = 0），但是需要花几分钟的时间才能恢复到正常运行（恢复时间目标，或 RTO = 非零值）。另一方面，对于一个主-备集群，其中备用 DB 始终通过同步机制保持更新，将使 RTO 的值接近零，但是在 “晋升的” 备用操作间，某些更新可能暂时无法使用（因此 RPO 非零）。

要在这两种（或更多）DB 技术或配置之间进行选择，取决于 DB 所支持业务的关键因素。引入 DB 集群架构模式突出了这种依赖性，因此选择原因变得一目了然，而技术组件的引入作为集群节点则突出显示了，每个节点就是若干个硬件和软件元素与其交互模式的复杂组合。

由于架构模式和技术组件主要为技术域的概念性元素，因此很自然，它们能够向上一层（应用程序层）提供（基础设施）服务。出于同样的理由，架构模式必须遵循区域的边界（另一个概念元素），因此所有的模式元素必须位于相同的区域内。

符号使用示例

为了解释符号的使用，我们将通过一个简单的例子说明在零售银行企业架构中操作性内容的角色。

业务层

在业务级别，我们将考虑客户和柜员之间在进行现金支付时展开的协同工作，触发条件是客户带着所需的现金来到银行柜台。

柜员和客户之间的所有柜台互动都取决于队列的动态变化，因为通常情况下等候服务的客户总是要比当时可提供服务的柜员要多。

即使很小的服务中断也会导致等候队列变长，客户对服务不满意，因此要求服务中断时间不能超过 3 分钟。这项需求对在柜台执行的所有功能都有影响，包括开具发票及底层的实现流程（付款管理）。

我们将绘制一个 Critical Continuity of Operations 区域并将这些功能和流程映射到该区域，从而展示需求的共性。

和往常一样，对于 ArchiMate 模型，业务功能将通过一些应用程序服务执行。我们将侧重于支付服务，探讨应用程序层的操作方面。

图 7. 将操作性内容映射到业务元素

应用程序层

支付服务应用程序是通过 Invoice Payments 功能实现的。这是由 Teller Platform 系统提供的一项功能，该系统通常由银行柜员使用。

由于系统被构造为客户端/服务器子系统形式，Payments 和 Teller Platform 都属于 Critical Operation Continuity 区域。客户端子系统负责应用程序显示和导航，从技术上来讲就是一个 Eclipse 状态性桌面。在本示例中，服务器子系统被构建为无状态 Web 服务集群。

第二个架构模式通过使用以下两种技术（应用程序）组件实现：

一个会话 Enterprise JavaBean（EJB），能够将请求传递到相应的功能组件

一个 Web 服务提供商，将 EJB 接口映射到 Web 服务的 WSDL。

这两种技术可以配合使用，确保传入请求中的负载平衡。此外，每个操作通过一个特定的 Accounting 组件在 Accounts 数据库中生成一个条目。

现在，虽然 Invoice Payments 功能只与其对应的业务层共享 “3 分钟最大中断时间” 这一业务需求，Teller Platform 服务器（由银行网点的所有 50,000 名柜员同时使用）必须确保所有服务的连续性。也就是说，服务器必须能够承受 50,000 次并发服务恢复操作的压力（以 3 分钟为间隔）。

从此处描述的模型可以看出，IT 架构师需要回答以下主要问题：

Eclipse 客户端能否在 3 分钟内重启？

该服务器设计能否保证在 50,000 名并发用户的情况下在 3 分钟内实现服务重启？

虽然纯功能模型将这些问题隐藏到复杂的功能性细节关系中，但是操作模型可以明确地指出真正的问题所在。

要在技术层继续构建模型，Accounts 数据库使用数据库集群服务，而 Web 服务聚集了 IBM? WebSphere? Application Server 的一个单元（cell）的服务。

图 8. 将操作性内容映射到应用程序元素

技术层

尽管 WebSphere 单元和数据库集群服务在概念上是非常独立的，但是它们可以通过相同的逻辑基础设施系统支持，在本例中指 Teller Platform，它只属于 Critical Continuity of Operations 区域。

当然，每个服务都是由不同的子系统提供，每个子系统具有自己的架构模式。DB 集群作为主/备数据库提供，在备用的 “热” 数据库中实现了接近同步的业务复制（如多平台 IBM DB2 中的高可用性 & 灾难恢复，HADR）。

注意，支持在故障后进行 “冷” 启动的主用/备用架构可能无法满足 3 分钟的时间限制，但是支持完整异步数据复制的主/备架构可能也同样无法处理大量排队中的更新（因为同时有 50,000 名用户）。

事实上，集群技术组件（主节点和备节点）是由硬件（节点）和中间件（RDBMS）的组合，在灾难恢复站点使用了诸如磁盘存储等设备和与存储相连的通信路径。

对于 WebSphere 单元，选择冗余架构可以同时满足并发用户数以及备份处理环境的需求（以防主架构出现故障）。

图 9. 将操作性内容映射到技术元素

在 IBM Rational Software Architect plug-in for ArchiMate 中实现的扩展

对 ArchiMate 模型的扩展是在 Rational System Architect CORSO ArchiMate 1.0 插件之上实现的，后者可以从 IBM 获得。扩展包含在 Rational System Architect USRPROPS 文件中，它们增加了四种新的图类型和相关资源：

1. Operational Aspects 图：这是绘制新的企业架构操作视图的主要工具。除了 NFR 元素外，它还包括所有 ArchiMate 元素，如 图 6 所示。
2. Business Operational 图：它的目标是详细描述企业业务 模型的非功能性方面。为此，它包括大部分业务层元素，以及非功能性方面和区域符号。
3. Application Operational 图：它的目标是详细描述企业应用程序 模型的非功能性方面。为此，它包括大部分应用程序层元素和所有操作符号。
4. Technology Operational 图：应用程序层相同的考虑事项也适用于此。

图 10. Rational system Architect 屏幕，带 ArchiMate 操作扩展

结束语

我们提出一个建议来完善 TOGAF ArchiMate 企业 Architecture 模型，其中包含一个 Operational Aspects 视图，目的不在于描述系统做什么，而是怎么做以及为什么这么做，也就是说指出哪些需求来自于哪种架构设计。

我们将这种视图实现为 Rational System Architect ArchiMate 插件的扩展，生成一类新的非功能性图。