6.1与构架商业周期的关系
阁6.3向我们展示了空中交通符制系统与构架商业周期的关系。这里的最终用户足联 邦航空管理部门，客户则足美W联邦航空局。开发组织足-家为美国政府提供了许多取耍 的软件密集型系统的大公司。技术环境因素包括要求使用Ada语言作为政府大型软件系统 的实现语言.以及将分布式计算作为构建系统及保证容错性的常用手段。
.png)
6.2需求与质量
考虑到空中交通竹制很引人注意，商业团体、官方及普通民众都对它1丨:常关心，而且 如果该系统不能良好运行，就可能造成生命财产损失，该系统的两个耍的质》属性需 求是：
(1)极高的可用性。即必须保证系统不能止:常x作的状态只延续极短的时间》
(2)高性能„即系统必须在不“丢失’’任何数据的情况下对大量数据（多达2440架 飞机）进行处理通信网络必须能够处理这种负载，软件必须能够快速地、带有预测性地 进行计算-
另外，下列需求虽然不像上面两个那样与飞机及乘客的安全息息相关，但也是构建该 系统构架的重耍驱动力和指导原则：
• 幵放性。即该系统必须能够与按商业运作开发出来的其他软件相集成.包括与空 中交通管制功能和诸如图形显示等基本计算服务的集成。
• 能够提交该系统的子集。这对于应付可能出现的因缩减预筇而使这个耗资达数10 亿笑元的项0流产是非常必要的——实际上后来真的发生了。
• 能够更改功能和处理软硬件的升级（如新处理器、新丨/0设备和驱动程序、新版 Ada语言编译器〉。
• 能够与众多外部系统相接并协同工作。这些系统可能是软件，也可能是硬件，有 的可能已经使用数10年，有的则可能还没行完全实现。
最后，该系统还必须满足众多涉众的要求，特别是作为系统最终用户的控制人员的要 求。这似乎没有什么不同寻常之处.但实际上这些控制人员完全有可能在系统功能满足要 求的情况下，因系统不符合他们的习惯而拒绝使用它。这-情况对系统滞求的确定和系统 的设计影响很大.大大减缓了系统开发的进程。
我们用区段组（sector suite)来表示某-区段的所有控制人员，他们邡像图6.4所表示 的那样聚集在某个控制台前，共同控制该中途中心所管辖空域的区段中的所有飞机。这里 我们对空中交通管制系统做进步的简化，即假定飞机在飞行过程中所受的管辖不仅要从 —个中心转到另•个中心，而且要从同一中心中的一个区段转向另•个區段》这些区段的 划分随所在中心的不同而不同。某个中心的区段划分可能要考虑到该中心控制人员的工作 摄，例如飞机飞经次数较少的区段的范围可能要比飞经次数较多的区段更大些。
在-个区段中衍多少个控制站这-方面，1SSS系统的设计耍求與佴足够的灵活性，即 允许在-个区段中有1到4个控制站，而且应该能够在保持整个系统正常运转的情况下做 —些管理上的更改。每个区段中耍求至少配备两名控制人员。-个是雷达控制员，其任务是监视雷达数据，负责与机组人员通话联系和保证实现飞机的安全隔离。该控制人员也负责管理该区段中的一些具体问题。另-个是数据控制员，其任务是获取可能已经在该区段 中或马上将进入该区段的每-架飞机的数据（如飞行计划等）数据控制员为雷达控制员 提供飞机的飞行目的数据，以便能够安全、高效地引导该飞机飞越此区段。
6.3构架解决方案
构架影响着系统的行为、性能、容错和可维护性。反过来’这些方面的荷刻要求同样影响构架。对于ISSS系统，到目前为止最重要的质量指标是对该系统可用性的极高 耍求：一年内的停机时间不超过5分钟。与其他要求相比’这一要求在更大程度上左右着
ISSS构架的决策。
我们通过描述软件所处的物理环境来说明ISSS构架，然后给出大量的软件构架视图
(已在第2章叙述)，并突出每个视图所釆用的战术（已在第5章叙述)。在讨论中，我们
介绍了以前没有讨论过的-个新视图：容错。在讨论了视阁之间的关系后，我们介绍了 -个针对可修改性和可扩展性的“抽象通用服务”战术的求精.给出nsss的构架图。
6.3.1 ISSS物理视图
ISSS是-个分布式系统，由通过局域网连接的许多元素组成-图6.5给出了 ISSS系 统的物理视图。该图中并没有给出任何ISSS支持系统或这些支持系统与ISSS设备的接口。也没有表示出丨SSS软件的结构。物理视图的主要元素及每个元素所扮演的角色为：
• 主计箅机系统是中途自动化系统当前的核心。每个中途中心有两台主计算机. 台负责常规处理.另一台则用于在前者出现故障时接管处理工作。主汁算机负责 对监控数据和飞行计划数据进行处理。监控数据显示在控制人员所使用的中途显 示控制台上，行数据根据需要输出到飞行条打印机上，有些飞行数据元素显示 在与雷达监控信息相关的数据标签上。
• 通用控制台是空中交通管制人员的工作站。这些控制台以平面图（雷达显示〉的 形式显示飞机所在方位及相关数据，用电子飞行条的形式显示飞行计划数椐， 并显示其他•些信息。管制人员也可以在这些控制台上修改飞行数据.控制所显 示信息的内容和格式。•个区段组有1到4台通用控制台.负责对某-空域的某-控制区段的控制。
• 通用控制台经由本地通信网（LCN)与主计算机相连，该网络是ISSS系统中的 主要网络。每台主机都通过双LCN接口单元与LCN相接，这两个LCN接口互 为冗余，提供容错能力。
• LCN由4个并行令牌环网组成，以提供冗余能力并平衡总负载。其中个令牌环 用以实现把监控数据广播到各个处理器，另一个令牌环用以实现处理器间的点到 点通信，还有一个用来把显示数据从通用控制台发送到数据记录部件以备后用， 最后•个令牌环则是备用的。桥接部件用以实现访问环和骨千环之间的连接。桥 接部件也提供在某个令牌环出现故障时用备用环来替代它的能力，并实现其他一 些路由选择功能。
•增强直接访问雷达信道（EDARC)提供飞机方位的后备信息，并将飞行数据块 信息限定显示在中途显示控制台上。使用EDARC式为了防止由主机发送的显示 数据的丢失，EDARC实质上提供的是未做处理的职始雷达数据和到ESI (外部 系统接口)处理器的接口。
.png)
后备通信网（BCN)是采用TCP/IP协议的以太网《该网格用以实现除EDARC 接口之外的其他系统功能，也可作为LCN的后备网络。
LCN和BCN都有相关的监控（Monitor and Control. M&C)控制台。通过这搜
控制台，系统维护人员可以查看系统状态，并实施某畔控制操作。M&C控制台 和普通的控制台没有什么大的区别，只是加装了支持M&C功能的软件’并可提 供高层或全局可用性管理功能。
测试与培训子系统提供了在不影响正常的空中交通符制工作的悄况下•对新的软 硬件进行测试以及对用户进行培训的功能=
中央处理器采用的是大型机上用的处理器，在丨sss系统的早期版本中用以提供 数据存储和冋放功能。
每个通用控制台都同时与LCN和BCN相连。.个场站内可能会有大量的通用控制台 多达210台）,所以要采用多个LCN访问环来保证这鸣控制台能够iK常丄作。这就是丨SSS系统的物理视图它突出了软件所驻留的硬件。
6.3.2模块分解视图
ISSS操作软件的模块元素被称为计算机软件配置项，它足按照政府软件幵发标准定义 的.是应客广耍求而使用的。CSCI基本上与任务划分相对应，有很多人参与了 CSC1的设 计.构建和测试。每个CSCI基本上都是围绕一个中心问题展幵的，包括了与之相关的所 有软件成分（如软件包、进程等)。
ISSS系统中共有5个CSCI,分别如下：
(1)显示管理，负责通用控制台上显示内容的产生与维护。
(2)通用系统服务，负责提供空中交通管制软件中的通用实用程序一前面提到过 开发人员曾经试图构建AAS软件之下的其他系统。
(3)记录、分析与回放，负责捕获空中交通管制系统中的会话以备亊后分析。
(4)全国空域系统修改，要求对驻留在主机上的软件做相应的修改（不在本书讨论 范围之内）。
(5)IBM AIX操作系统，为操作软件提供了基本的操作系统环境。
这些CSCI构成了可提交的文档和软件单元，标志着开发工作的进程.每个都负责 执行逻辑上相关的某个ISSS功能部分。
模块分解视图反映了几个可修改性战术，这已在第5章进行了讨论。“语义一致性” 是为每个CSCI分配定义良好且不重叠的责任的全部战术。通用系统服务模块反映了 “抽 象通用服务”的战术。记录、分析和回放csci反映了可测试性的“记录/回放”战术。可以通过仔细设汁的软件接口获得每个CSCI的资源，这反映了 “预期变更的期塑”、“泛化该模块”以及“维持接口的稳定性”。
63.3进程视图
丨SSS中并发的基础位于称为“应用程序”的元素中。从Dijkstra所说的协作顺序进程的意义上看。这里的应用程序与进程大致相当。这里的应用程序也是丨SSS设计人员用来 |保证容错性的重要手段。应用程序被实现为Ada “main”单元（可由操作系统调度的进程)， 并形成了 CSC1的•部分（这可以帮助我们确定模块分解视图和该进程视图之间的映射）。应用程序通过消息传递进行通信.它是该组件-连接器视图中的连接器。
ISSS系统是按照多处理器的环境设计的。这些处理器（己在物埋视阁中讲述）在逻辑 上组成处器组„处理器组的目的足要分别运行-个或多个应用程序的副本。这一思想对于支持容错性和可用性是非常重耍的。在多个运行副本中，•个为主，其他为辅，所以我们将同一应用程序的不同副本称为主地址空间（PAS)和备用地址空间（SAS)。 •个主地 址空间和与其相应的备用地址空间的集合称为操作单元。某一特定的操作单元完全驻留在 同•处理器组的处理器中，而一个处理器组最多可包括4个处现器。未以这种容错方式（即 主地址空间和备用地址空间并存）实现的ISSS系统的其他部分则在不同的处理器上独立 运行，我们将其称为功能组。功能组可根据需要出现于各个处理器上，毎个副本都有独立 程序的独立的实例.各自维持自己的状态。
总之，应用程序可以是一个操作单元.也可以是•个功能绀。这两者的不同表现在是 否用一个或多个辅助版本来与主版本的状态和数据保持一致，并在主版本出现故障时接管 主版本的工作。操作单元采用了这种容错性设计，而功能组则没有。如果可用性是起关键 作用的质最属性，就要以操作单元的形式來实现应用；否则就用功能组的形式来实现。
各应用程序之间按客户机/服务器模式进行交互。客户机向服务器发送服务谘求消 息.服务器对之做出应答。（像在其他的客户机/服务器模式中•样，某个特定的参与者—— 这里也就是应用程序——可能在某次通信中作为客户机，而在另一次通信中又作为服务 器。）在操作单元内.PAS将状态变化情况通知其各个SAS，而各SAS则等待超时或其他 标志PAS或其处理器失败的信号，以便接替出现故障的PAS。阁6.6对同-应用程序的主 地址空间和备用地址空间相互协调的情况做了总结，并给出了它们与处理器组的关系。
.png)
当某个功能组收到消息时.它只霈要做出应答并适当地更新自己的状态。一般地.
操作单元中的PAS代表整个操作单元接收消息并做出响应，然后PAS还要对自己的状态 和其SAS的状态进行更新，在这一过程中要向SAS发送更多的消息。
如果某个PAS出现了故陣，则按如下步骤完成接管工作：
(1)一个SAS提升为新的PAS
[(2) PAS重新设立与该操作单元中各客户机的关系（对各操作单元来说这是一个固 定的列表).在此过程中新PAS要向各客户机发送消息，该消息的基本内容就是：原来提 供服务的操作单元出现了故障.正在等待PAS发送消息吗？然后新PAS就处埋所接收到 的任何服务请求。
(3)启动某个新SAS,代替原有的PAS。
['(4)新启动的SAS将自己的存在告之于新的PAS,新PAS向新启动的SAS发送信 息.使之保持最新状态。
[如果在SAS内部发现了错误，就要在另外的处埋器上启动新的SAS。新的SAS要与 其PAS协调工作.并接收状态数据。
为了添一个新操作单元，应采用如下的详细步骤：
•确定必要的输入数据及所在的位置。
•确定哪些操作单元需要用到这个新操作单元的输出数据。
•以--种使该图仍然保持非循环的方式将该操作单元的通信模式加到整个系统的 非循环通信图中.以避免发生死锁。
•设计消息，实现所期望的数据流。
•确定在进行系统评审时必须要用到的內部状态数据，以及在从PAS到SAS的更 新通信中必须包括的状态数据。
•将状态数据划分为能够很好地适应网络要求的消息。
•定义必须用到的消息类型。
•规划在PAS失畋时的切换：要对更新数据做合理的规划，保证能够完全反映出各
种状态。
•保证在切换发生时数据的一致性。
•保证各个处理步骤能够在不超过一次系统“心跳”的时间内完成。
•规划与其他操作单元的数据共享和数据锁定协议。
该过程不适用于新手.但有经验的小组成员可以按照上面的指示幵展工作。下面所讨论的战术代码模板可使该过程更加可重复.并减少出错的可能性。
该进程视图反映了几个可用性战术，包括“状态再同步”、“shadowing”、“主动冗余” 和“从服务中删除'
6.3.4客户机-服务器视图
因为该进程视图中的应用程序以客户机-服务器的模式交互，因此给出一个ISSS的客 户机服务器视图是合理的，尽管它所描述的行为主要镜像了己经给出的进程视图所捕获 的行为。出于完整性目的，图6.7给出了该系统的客户机-服务器视图。
.png)
客户机和服务器经过了精心设计，它们具有一致的接口。这通过使用用于交互的简单 的消息传递协议得到了促进。结果反映了 “维持接口的稳定性”、“组件更换”和“遵守已 定义协议”的可修改性战术。
6J.5代码视图
在第2章没有讨论但有时会出现在大型系统的构架中的视图就是代码视图。代码视图 展示了如何把功能映射到代码单元上。
在ISSS中，Ada (main)程序是在一个或多个源代码文件的骓础上创建出来的，般 包括多个子程序，芄中一些子程序位于可独立编译的程序包中。1SSS系统的软件就是由若 干个这样的程序组成的.其中有许多是以客户机/服务器模式工作的。
—个Ada程序可以包括一个或多个任务（task),这里的“任务”就是彼此能够并发执 行的Ada实体。这些是进程视图中所描述的进程的代码-视图结果。由于Ada任务是由Ada 运行系统控制的，所以丨SSS中也采用了从Ada任务到UNIX (AIX)进程的映射，这意味 着所有的单个控制线程（不管是独立的Ada程序还是某• Ada程序屮的任务）都是并发运行的独立的AIX进程。
应用程序（即操作单元和功能组）被分解成Ada程序包，有些程序包中只有类型定义， 而有的则在不同应用程序中重用。打包（packaging)是种设计活动，其目的是包含抽象 和信息隐藏，这一工作通常是由操作单元的首席设计人员完成的。
6.3.6分层视图
在ISSS的处理器系统上运行空中交通管制应用程序所采用的是商业UNIX操作系统、 AIX.然而，UNIX操作系统并不能提供支持像丨SSS这样的分布式容错系统所必需的所有 服务。所以，还必须使用其他的系统服务软件丨图6.8以一组层的形式给出了典型的丨SSS 处理器中的总体软件环境。'
图中最低的AIX层之上的两层表示对在AIX内核地址空间中运行的A1X的扩展。考 虑到对A1X操作系统的性能和兼容性的要求，这些扩展•般都使用C语言编写的小程序。 因为它们足在操作系统的内核地址空间中运行的，所以如果这些扩展程序出错，就有可能 殃及AIX操作系统：因此，这些程序必须是相对较小、反映了第5章中所讨论的“限制暴 露”战术的可信赖的程序.尽管该战术是基于安全性的——即防止拒绝服务-但在ISSS 中它用来增强可用性，是•个补充目标。让人高兴的是.有时可以用一个战术较为满意地 实现多个质量属性。
原子广播管理器在•个区段组的本地可用性管理器模块间的通信中起着非常重要的 作用，这些模块用于管理一个组内功能的可用性。场站管理器在LCN上提供数据报服务， 是LCN网络管埋服务的本地模块。网络接口子层（NISL)为点到点的消息传递提供了类 似功能，与场站管理器共亨网络信息。
再上面的两层表示在A1X操作系统内核地址空间之外运行的操作系统扩展。因此，如 果这些程序出现错误，不会对AIX操作系统本身直接造成破坏。这些程序一般遥用Ada I语言编写的。
消息准备为应用程序处理LCN消息。BCN消息准备对在BCN上发送的消息也执行类 似的功能^这些程序所要完成的功能之一就是确定在同一K段组的应用程序的多个冗余副 |本中.哪个是主副本，从而作为这些消息的接受方。本地可用性管理器提供了做出这一决 I定所需要的控制信息。
.png)
©严格地说.图6.8是分层视图和纽件-连接器视图的重叠。因为它展示了层中子模块之间的运行时连接。 在“AAS服务”和“ 其他设备驱动程序”这两种情况下，并没有给出分层视图中的这些和其他子模块 之间的连接.因为这样的话图会太乱。大多数分层系统都可以自由使用这些服务。实际连接列在了该 视图的支持文档中。
图中的顶层是应用程序。本地可用性管理器和内部时间同步程序是应用级上的系统
服务..本地可用性管理器负责管理应用程序的启动、终止及其可用性》它与其自身处理器 中的毎个地址空间进行通信，控制其运行并检査其状态。它还与本区段组内其他处理器中 的本地可用性管理器进行通信，以管理本区段组内功能的可用性，包括在适当的时候从应 用程序的主副本切换到后备副本。本地可用性管理器与驻留在M&C控制器台上的全局可 用性管理应用程序进行通信，报告当前状态并接受控制命令。内部时间同步程序负责将本 处理器的时钟与其他1SSS处理器的时钟进行同步，这对可用性管玴功能的正常运行具有重要意义（参见图6.9的容错视图）。
.png)
6.3.7 —个新视图：容错
正如我们已经说过的一样，第2章并没有彻底详尽地列出所有视图。实际上对任何 系统或所有系统来说，没有一个能够涵盖组成完整软件构架的视围的列表。软件构架中 一种备受欢迎的趋势是认识到了构架在实现质量属性中的重要性，因此也就认识到了明确陈 述构架要提供的质最属性的重要性。为了达到这种目的，设计师通常会产生展示构架如何 实现某个特定质量厲性的视图：比如安全性视图。对于运行时质量属性，这些视图属于组 件-连接器类。展示了运行时元素交互；对于非运行时质量属性，这些视图属于模块类， 展示了如何设计实现单元以获得（例如〉可修改性。
对ISSS系统可用性的极高要求使容错性在该系统的设计中占椐了很耍地位。首先， 在系统出现故陣时不能进行冷启动。直接（或至少是比较快地）切换到备用组件似乎是-种最好的办法。随着设计的展开，这•思想越来越明确，从而诞生了一种新的构架层次上 的结构：容错层次（参见图6.9)。该结构描述了如何检错、如何隔离以及系统如何恢复。 PAS/SAS模式能够捕获单个应用程序内的错误并从中恢复，而容错层次则是用于捕获应用 程序间交互的错误并从中恢复。
ISSS系统的容错层次提供了多种不同层次的错误检测和恢复机制。在每个层次上都能 异步地：
• 检测自身、同级实体和低层实体的错误
• 处理来自低层的例外情况
• 诊断、恢复、报告或提交例外情况
每个层次都要在下层所产生的可用性的基础上进一步提高系统的可用性。这些层次 包括：
• 物理层（网络、处理器及输入/输出设备）
• 操作系统
• 运行时环境
• 应用程序
• 本地可用性
• 组可用性
• 全局可用性
• 系统监视与控制
在该层次屮的每个层上都要做错误检测与隔离工作。错误检测是以内建测试、事件超 时、网络电路测试、组员协议以及人对瞥告及指示信息的反应等方式实现的。
在该软件的各个层次上都进行错误恢复操作，可以用自动或手工两种方式完成。对本 地、组和全局可用性管理器而言，是以表驱动方式完成恢复的。在PAS中冇4种类型的恢复。恢复类型的选用取决于当前操作状态，由使用决策表的本地可用性管理器来决定，即：
• 在切换时，SAS几乎立即接管PAS的工作。
• 热启动时用到检查点数据（写在非易失性存储器上)。
• 冷启动使用默认数据，丢火状态历史信息。
• 用中间数据转换到新（或旧）逻辑或适应性数裾。
网络硬件（LCN、BCN及相关的桥等）、处理器硬件（每个处现器组中有多达4个处 理器.采用冗余数据记录）和软件（每个操作单元采用多个地址空间）都提供了冗余性.
除了已经在进程视图中看到的可用性战术外，容错视图还添加了 “命令/响应”和“心 跳”作为检测故障的方法，将错误过滤到适当的地方以进行纠正的异常.以及执行恢复的 备件。
6.3.8将视图彼此关联起来
在前面的讨论中，-个视图中的元素也可能在其他视图中以客人的形式出现。尽管视 围形成了理解系统的骨千.但我们可以通过分析视图彼此之间的关系，尤其是分析从•个 视图到另一个视图的映射.来更深入地了解系统。这给出了构架的个更完整的视图。
在ISSS中，CSCI是模块分解视图中的元素，它们由应用组成，应用反过来又是进程视图和客户机-服务器视图中的元素。应用被实现为Ada程序和软件包（在代码视图中）， 它们又映射到并发视图中的元素线程上（没有给出）。分层视图以-种展示允许它们使用 什么功能的方式，描述了分配给分解视图中的模块的功能。最后，-个侧重于某个运行时质量厲性实现的专门的视图——容错视图——使用了进程、分层和模块视图的元素。
第9章讨论了软件构架编档，规定了在文档软件包中专门用于捕获视图关系的地方。 对1SSS来说，该映射包括了一些表，表中列出了来自各个视图的元素.并展示了它们如 何像上面描述的那样彼此对应。
6.3.9自适应数据
ISSS系统广泛使用了 “配置文件”的可修改性战术，它需要自适应数据。对于22个 中途屮心来说，有针对各中心的自适应数据，丨SSS系统就足根据这些数据部署到各个中途 中心的，所以这些自适应数据又叫预置自适应数据。这些数据将能够使ISSS软件适应在 开发和部署过程中所出现的更改情况，但不能宪全代表各中途中心之间的区别。对于具体场站需求、具体用户或中心喜好、配置的更改、需求的更改以及其他随时间或场站部署的 不同而改变的情况来说，自适应数据是系统进行修改的极好的、重要的简便途径•按照实 际的设计，该系统要从输入数据中读取操作参数和行为参数，所以考虑到该数据所能表示的行为，此系统是完全通用的（反映了 “泛化模块”战术)。例如，在某更改实践中要将 该空中交通管制系统的•个窗口划分成两个窗口。实践表明这一修改只需对某几行代码做 些修改就可以了，主要就是通过更改自适应数据实现的。
自适应数椐所带來的负面影响是使维护工作变得复杂。例如，给系统添加新的命令或 命令规则（从操作单元的角度看）非常简单方便，但其实现却要用复杂的解释性语言。另 外，各自适应数据之间可能有复杂的交互问题，这可能会影响到正确性，而且没有防范这 种不一致性所带来的影响的自动或半自动的机制。最后，自适应数据极大地增大了操作软 件正确运行所需的状态空间，这对系统测试有着较大影响。
6.3.10对“抽象通用服务”进行求精的战术：应用程序的代码模板
前面提到过，在主铺地址空间模式下是靠冗余来实现容错性的：软件的多个副本保存 在不同的处理器中。当主副本运行时，要时常向其辅助副本发送状态信息，以保证在需要时辅助副本能够顺利接管原来主副本的工作。这些副本的实现耍求这两类副本都是根据完 全相同的源代码生成的。即使主副本和辅助副本从来不在相同的时间做相同的工作（主副 本执行自己的操作并向其辅助副本发送状态更新信息，而辅助副本则等待接受状态更新信 息并准备随时接管主副本的工作)，主副本的程序和辅助副本的程序的源程序也必须足完 全相同的。为做到这一点，承包商为每种应用程序都开发了标准的代码模板，其样式如图6.10所示。
该模板的结构是个持续不断的循环，每一次循环都耍对所接收的事件进行处理。如 果所接收的事件要求应用程序做某个常规（即与容错性无关的）操作，该应用程序就执行 该操作，并对其辅助副本进行更新，以保证辅助副本能够在必要时接管此程序的工作。大 多数应用程序能够处理50到100个常规事件。其他事件则涉及状态信息及数据更新的传 送（发送和接收）最后一组事件包括该单元成为主地址空:间的声明，以及来向客户机对 前一个主地址空间（现已失败）未完成服务的请求。
模板对构架也有一些影响：使用该模板后，简化了向系统中添加新的应用程序的工作， 只需对模板中的容错机制的少量细节加以考虑。应用程序的编写人员和维护人员只需要在 抽象层次上了解消怠处理机制就可以了，他们不需要考虑自己编写的应用稈序是否具有容 错性——这•问题已经在更高的设计层次（构架）上做了妥善处现。
代码模板是对“抽象公共服务”战术的求精，即把每个应用中共有的那.部分实例化 于该模板中。该战术与用于可修改性的其他几个战术相关。在可以变更，并为进程提供了 “语义一致性”的部分，代码模板反映了 “对预计变更的预期”，因为抽象地看，它们都 在做同样的事情。该模板可以使程序员把精力放在其应用的细节上，从而促成了 “泛化模块”，通过使接口和协议成为模板的一部分，它们“维持了接口的稳定性”并实现了 守已定义的协议"。
表6.1总结了丨SSS软件构架满足其质量面目标的方法和战术。
表6.1 ATC系统如何实现其质量目标
.png)
6.4小 结
与本书中的所有案例分析一样，ISSS说明了构架解决方案在实现应用软件的高性能耍 求方面的重要作用。表6.1总结了所使用的关键方法。按照规划.该系统的使用寿命长、 成本高、规模大、作用重要且受到各力面的广泛关注，因此，ISSS系统在其极岛的使用要 求方而承受着巨大的更改压力。人机界面、新的硬件、新的商业组件、操作系统和网络升 级、以及容量的提高不仅是可能的.而是可以预料的必然结果。通过使用包括硬件和软件 冗余以及分层错误检测在内的标准容错机制（和代码模板），以及采用消息传递的分布式 计算.该构架能够满足极其复杂的、广泛的使用要求。
需要说明的是，当美国政府考虑放弃ISSS,转而采用•个功能更简单-、成木更低的解 决方案时.-•个由•流的专家绀成的小组已经对ISSS构架进行了大量软件审核。该审核 小组评估了构架提供所要求的性能和可用性的能力.并通过遍历几个更改场景.测试了其可修改性，包括：
• 对监控（M&C)方位的人机界面做重大修改
• 在丨SSS系统中引入第三方开发的空中交通管制应用程序
• 在系统中添加新的空中交通管制视图
• 用一个具有类似功能的芯片更换RS/6000处理器
• 删除丨SSS中对支持电子飞行条的要求
• 把系统中飞行跟踪能力提高50%
在每种情况下,审核小组都发现isss软件构架经过了精心设计，从而使得修改能够直截了当、有时甚茧是非常简单地进行。这足以说明该构架经过了精心设计、明确考虑了 质量属性以及实现这些质量厲性的构架战术。
6.5可进一步参阅的文献
很多文献中都谈到美国联邦航空局试图对空中交通管制软件进行级的问题，例如 [Gibbs 94]„ [Brown 95]对关于ISSS系统可挽救性评审的情况做了介绍。在这歧论文中， 维护性被看作是带有二重性的质量属性，即不仅与系统本身有关，而且与实施这种维护的组织的能力有关。对可维护性的重要方面-即系统所需要的维护和组织所能够提供的维护之间的适应问题——大多没有进行讨论。
6.6讨论题
(1)高可用性是本葷所讨论的构架的主要推动力》该需求是如何影响诸如性能之类的 其他质量厲性的？如果没有这•需求，构架会变成什么样子？
(2)在ISSS软件构架中有多少种构架样式？
(3)对于在6.2节中给出的需求，尽可能多地为其构造质量属性场锻（已在第4萆描 述)，并在遗漏了必要信息的地方，给出合理的替代信息。