5.5安全性战术

 

可以把实现安全性的战术分为：与抵抗攻击有关的战术、与检测攻击有关的战术以及 与从攻击中恢复有关的战术。这3种战术都非常重要。我们对此做个很熟悉的比较，给 门装锁就是在抵抗攻出，在房子中放-个运动传感器就是在检测攻击.给房子上保险就是 从攻击中恢复过来。阁5.8给出了安全性战术的目标。

 

5.5.1抵抗攻击

在第4章对安全性的描述中，我们把认可、机密性、完整性和保证确定为目标。可以 组合使用下而的战术来实现这些0标。

 

•    对用户进行身份验证。身份验证能够保证进行访问的用户或远程计箅机确实&它 所声称的用户或计算机。密码、•次性密码、数字证书以及生物识别均提供身份

•    对用户进行授权。授权能够保证经过了身份验证的用广冇权i方M和修改数据或服 务。这通常通过在:系统中提供一些访问控制模式进行管理。可以对单个用户进行 访问控制，也可以对某•类用户进行访问控制。可以根据用户分组、用户角色或 个人列表定义用户类。

 

•    维护数据的机密性。应该对数据进行保护，以防止未经授权的访朐。•般通过对 数据和通信链路进行某种形式的加密来实现机密性。加密能够对持续维护的数据 提供额外的保护（授权并不能提供此类保护）。兄•方面，通信链路•般不具有 授权控制。对于通过公共可访问的通信链路传送数据来说.加密是惟•的保护措 施。对基于Web的链路.可以通过虚拟专用网（Virtual Private Network, VPN) 或安全奁接层（Secure Socket Layer, SSL)来实现该链路。加密可以是对称的（双 方都使用相同的密钥）或不对称的（公钥和私钥）。

 

•    维护完整性。应该如期提供数据。数据中可能有冗余信息.如校验和或哈希值.

它们可以与原始数据一起进行加密，也可以单独加密。

 

•限制暴露的信息。攻击者通常会利用暴露的某个弱点来攻击主机上的所有数据和 服务。设计师可以设计服务在主机上的分配，以使只能在每个主机上获得受限的 服务。

 

•限制访问。防火墙根据消息源或目的地端口来限制访问。来自未知源的消息可能 是某种形式的攻击。限制对已知源的访问并不总是可行的。例如，一个公共网站 上可能会有来自未知源的请求。这种情况中使用的一个配置就足所谓的解除管制 区（DMZ)。当必须对Internet服务而非专有网提供访问时使用DMZ。它位于 Internet和内部网前面的防火墙之间。DMZ包含预计会从任意源接收消息的设备， 这些信息源包括Web服务、e-mail和域名服务等。

 

5.5.2检测攻击

 

检测攻击检测通常通过“入侵检测”系统进行。此类系统的工作方式是比较网络通信模式与数据库系统。在误检测的情况下，将通信模式与已知攻击的历史模式进行比较。在 异常检测的情况下，将通信模式与其本身的历史基线进行比较。通常，必须对数据包进行 过滤，以进行比较。可以根据协议、TCP标记、有效负荷大小、源或目的地地址以及端口 ,进行过滤。

 

入侵检测器必须有某种检测攻击的传感器，进行传感器融合的管理器.存储事件供以后进行分析的数据库，用于离线报告和分析的工具以及一个控制台，以使分析员能够修改 入侵检测操作。

 

5.5.3从攻击中恢复

 

可以把从攻击中恢复的战术分为与恢复状态相关的战术和与识别攻击者相关的战术 (用于预防性的或惩罚性的目的）。

 

在将系统或数据恢复到正确状态时所使用的战术与用于可用性的战术发生了重叠，因 为它们都是从不一致的状态恢复到一致状态。二者的差别就是要特别注意维护系统管理数 据的冗余副本，如密码、访问控制列表、域名服务和用户资料数据。

 

用于识别攻击者的战术是“维持审计追踪”。审计追踪就趄应用到系统中的数据的所有 事务和识别信息的一个副本。可以使用审计信息来追踪攻击者的操作，支持认可（它提供 进行了某个特定请求的证据）并支持系统恢复。审计追踪本身通常就是攻击目标，因此应 以•种可靠的方式对其进行维护。

 

图5.9对安全性战术进行了总结。

5.6可测试性战术

可测试性战术的目标是允许在完成软件开发的•个增量后.较轻松地对软件进行测 试。图5.10给出了可测试性战术的使用情况。提高软件可测试性的构架技巧未能如在更成 领域中那样受到更多关注，如可修改性、性能和可用性。但是，£如我们在第4章已经说 明的那样.因为测试在系统开发成本中占了很高的比例，因此，设计师所能做的降低该成 本的任何工作都将产生极大的收益。

尽管在第4祭我们已经把设计评审作为了-•个测试技巧，但在本萆我们仅关注对运行 系统的测试。测试的目的是发现错误。这要求将输入提交给被测试的软件并捕获输出。 执行测诚过程耍求某个软件为被测试的软件提供输入并捕获输出。这种软件被称为测

试专用软件。在这里，我们并没有考虑测试专用软件的设计和生成问题。在一些系统中， 这需要花费很多时间和费用。

 

我们对两类用于测试的战术进行讨论：提供输入并捕获输出：内部监视。

 

5.6.1输入喻出

 

有3种用于管理测试的输入和输出的战术。

 

•记录/回放。记录/回放是指捕获跨接口的信息.并将其作为测试专用软件的输入。 在正常操作中跨•个接口的信息保存在某个存储库中，它代表来自-个组件的输 出和传到-个组件的输入。记录该信息使得能够生成对其中-个组件的测试输 入.并保存用于以后的比较的测试输出。

 

• 将接口与实现分离。将接口与实现分离允许实现的代替，以支持各种测试目的。 占位实现允许在缺少被占位的组件时，对系统的剩余部分进行猁试„用.个组件 代替某个专门的纽件能够使被代替的组件充当系统剩余部分的测试工具。

 

•特化访问路线/接口。具有特化的测试接口允许通过测试工具并独立于其正常操 作，来捕获或指定组件的变量值。例如，可以通过特化的接口提供元数据，测试工具利用该接口推动其活动。应该将特化的访问路线和接口与针对所要求功能的 访问路线和接口分离开。使构架中的测试接口分层意味着可以在构架的任何层次 上应用测试用例，并且已经具备观察响应的测试功能。

 

5.6.2内部监视

 

组件可以根据内部状态实现战术，以支持测试过程。

 

•内置监视器组件可以维持状态、性能负载、容量、安全性或其他可通过接口访 问的信息。此接口可以是该组件的一个永久接口，也可以是通过instrumentation 技巧临时引入的接口，如面向方面编程或预处理程序宏。-个常见的技巧就是当 监视状态被激活时记录事件。监视状态实际上会增加测试工作，因为随着监视的 关闭，可能必须重复测试。尽管额外测试需要一定的开销，但这却使组件活动的 可见性得以提高，这样做是值得的。

 

图5.11对用于可测试的战术进行了总结。

 

5.7易用性战术

第4章已经讲过，易用性与用户完成期望任务的难易程度以及系统为用户提供的支持 种类有关。有两种类型的战术支持易用性，每种战术所针对的是两种类别的“用户"。第一类是运行时，包括那些在系统运行期间支持用户的战术。第二类基于用户接口设计的迭 代特性，它在设计时支持接口开发人员。易用性战术与已经讲过的可修改性战术有很密切 的关系。

 

阁15.12给出了运行时战术的目标。

 

5.7.1运行时战术

系统执行，就可以通过为用户提供关于系统正在做什么的反馈，以及为用户提供 发出基于易用性命令的能力来增强易用性，如第4章所讲述的那些命令。例如，在纠错或更高效的操作中，“取消’’、“撤销’、“聚合’’和“显示多个视图”均为用户提供支持。

 

人机交互的研究人员使用术语“用户主动”、“系统主动”和“混合主动”来描述在执 行某些操作时，哪方采取主动以及如何进行交互。第4章列举的易用性场景“理解质最属 性”从两个角度组合了主动。例如，当取消命令时用户发出取消——“用户主动"——系 统做出响应。然而在取消期间，系统可以提供•个进展指示器——“系统主动”。这样， 取消展示了 "混合主动”。我们使用用户主动和系统主动之间的这一区别来讨论设计师用 来实现各种场景的战术。

 

当用户采取主动时，设计师设计一个响应，就如同实现其他功能-•样。设计师必须列 举出该系统的责任.以对用户命令做出响应。我们仍考虑取消示例：当用户发出取消命令 时，系统必须收听该命令（因此需要有-个固定的收听者，它不会被所取消的任何命令的 操作所阻碍)；必须删除（kill)要取消的命令：必须释放被取消的命令所使用的所有资源： 必须通知与被取消的命令协作的组件，以使它们能够采取适当的操作。

 

当系统采取主动时，它必须依赖关于用户的某些信息（--个模型)，即用户所承担的任务或系统本身的状态。每个模型都要求各种类型的输入以完成其主动。系统左动性战术 就是那些确定系统用来预测其自身行为或用户意图的模型的战术。封装该信息能够使设计 师更轻松地剪裁和修改这些模型。剪裁和修改既可以基于用户过去的行为，也可以在开发 期间脱机进行。

 

•    维持任务的一个模型，在这种情况下，所维持的模型是关于任务的信息。任务模型用于确定上下文，以使该系统了解用户试图做什么，并提供各种协助。例如， 知道句子通常以大写字母开头能够使应用程序纠正该位置的小写字母。

 

•    维持用户的一个模型，在这种情况下，所维持的模型是关于用户的信息。它确定 了用户对该系统的了解，用户在期望的响应时间方面的行为，以及特定于某个用 户或某类用户的其他方面。例如，维持用户模型能够使系统以用户可以阅读页面 的速度滚动页面。

 

•    维持系统的一个模型，在这种情况下，所维持的模型就是关于系统的信息。它确 定了期望的系统行为，以便为用户提供适当的反馈。系统模型预测了诸如完成当前活动所需要时间这样的项目。

 

5.7.2设计时战术

 

在测试过程中，通常会频繁修改用户接口•也就是说，易用性工程师将为开发人员提 供对当前用户接口设计的修改，开发人员将实现这些修改。这导致了对语义一致的可修改 性战术的求精：

 

•    将用户接口与应用的其余部分分离开来。局部化所期望的变更是语义一致的一个

基本原理。因为在开发中和部署后，我们预计用户接口会频繁发生变化，因此单 独维护用户接口代码将会把变更局部化在某个地方。开发用于实现该战术并支持 用户接口修改的软件构架模式为：

 

•    模型-视阌-控制器

 

•    表示-抽象-控制

 

•    Seeheim

 

•    Arch/Slinky

 

图5.13对实现易用性的运行时战术进行了总结。

 

5.8战术与构架模式的关系

 

我们已经表述了设计师可以用于实现特定质量属性的战术集合。实际上.设计师通常 会选择个精心设计的模式或模式集合，来实现•个或多个战术。然而，每个模式都实现 了多个战术，不管是否是所期望的。我们通过讨论Active Object设计模式来对此进行说明’ [Schmidt 00]将此描述为：

 

Active Object设计模式将方法执行从方法调用中分离出来，以增强并发，并简化对驻 留在其自身控制线程中的对象的同步访问.

 

该模式由6个元素组成：代理，它提供了允许客户对主动对象调用公共可访问方法的接口；方法请求，它定义了用于执行主动对象的方法的一个接口；激活列表，它维持了挂起方法请求的一个缓冲器：调度程序，它决定接下来执行什么方法请求；附属(servant), 它定义了建模为主动对象的行为和状态；将来（fimirc),它允许客户获得方法调用的结果。

 

该模式的动机就是增强并发性——这足•个性能目标。因此，其主要目的就是实现 “引入并发”性能战术。然而，还要注意该模式包含的其他战术。

 

•    信患隐藏（可修改性)。每个元桌都选择了它将实现的责任，并将其实现隐藏在接口后面。

 

•    仲裁者（可修改性）。该代理充当着将把变化缓冲到方法调用中的仲哉者。

 

•    绑定时间（可修改性）。主动对象模式假定对该对象的请求在运行时到达该对象, 然而.并没有确定客户机与代理的绑定时间。

 

•    调度策略（性能）。调度程序实现一些调度策略。

 

任何模式都会实现几个战术，它们通常与不词的质量属性有关；而且该模式的任何实 现都对战术做出了选择。例如，实现可以维护对主动对象的请求日志.以支持恢复、维护 审计追踪或支持可测试性.

 

对设计师来说.分析过程包括理解嵌入在实现中的所有战术：设计过程包括在关于哪 些战术的组合将实现系统期望的目标方面.做出个明智的选择。

 

5.9构架模式和样式

 

软件中的构架模式（也被称为构架样式）与建筑物中的构架样式类似.如Gothic, Greek Revival^Queen Anne„它由几个将它们组合起来以维持构架完整性的关键特性和规则组 成。构架模式由以下几个因素确定：

 

•    一组元素类型（如数据存储庳或计算数学函数的组件),，

 

•    指出其相互关系的元素的拓扑布局。

 

•    一组语义限制（如管道-过滤器样式中的过滤器是纯数据转换器——它们以增量 形式将其输入流转换为输出流，但并不控制上游流或下游元素)。

 

•    -组交互机制（如子例程调用、事件-订阅者、黑板），它们确定元素将如何通过 允许的拓扑进行协调。

 

Mary Shaw和David Garlan在一部具有影响力的著作中，试图对他们称之为构架样式 或术语的--组构架模式进行分类。软件工程团体将此演变为现在更为我们所熟知的构架模 式.它们与设计模式和代码模式类似。

 

[Shaw96]从事这•项目的动机是观察到了复杂系统存在离层抽象，但我们并不研究它

 

们.也不对其进行分类，这在其他工程规范中是很常见的•

 

这些模式不仅定期出现在系统设计中，而且有时很难识别出它们，因为在不同的规范 中，相同的构架模式可能会有不同的名字。因此，我们对许多道复出现的构架模式、其属 性和优势进行了分类。图5.14给出了这样的一个分类。

 

在该图中，模式以一种继承的层次被分类为相关的组。例如，事件系统是独立元素的一个 子样式。事件系统本身有两个子模式：隐式调用和显示调用。

 

构架模式和战术之间是什么关系？正如己经说明的那样，我们把战术看作是设计的基 本“构建块”，并根据该战术创建构架模式和策略。

 

5.10小 结

本章讲述了设计师如何实现特定的质量属性需求。这些節求是系统实现业务H标的手 段。此处我们感兴趣的是设计师使用构架模式和策略创建设计方案的战术。

 

我们提供了一个用于实现第4章所说明的6个质:tt诚性的战术列表：可用性、可修改 性、性能、安全性、可测试性、易用性。对于每一个质量属性•我们都讨论了可以获得并 得到了广泛实践的战术。

 

iK如我们所讨论的，在将战术与模式关联起来的过程中，选择了战术后，设计师的任 务才刚刚开始。任何设计都使用多个战术，理解这些战术实现什么属性、其副作用是什么 以及不选择其他战术的风险对构架设计足必不可少的。

5.11讨论题

 

(1)正如在第4章的讨论题中的第3题那样,考虑一个有很多人访问的网站,如Amazon 或eBay。、选择满足在该问题中列举的性能需求的构架模式或构架策略时，需要考虚什么 战术？

 

(2)给定您在第1题中选择的战术集，在使用这些战术集时，您预计会与其他质俎属 性进行什么样的权衡（如安全性、可用性和可修改性）？

 

(3)在构架设计中，易用性不-定会得到应有的关注，使易用性成为系统目标通常是 很难实现的.因为易用性是作为事后考虑事项的。考虑个您熟悉其构架的系统，并试筘 列举出它所采用的易用性战术，如果有的话。

5.12可进一步参阅的文献

 

安全性方面的文献请参见[Ramachandran 02]；关于易用性和软件构架模式之间的关系 的请参见[Bass Ola]：关于分布式系统可用性技巧的读物请参见[Ja|ote94]。[McGregor01 ] 中提供了关于可测试性的信息。

 

关丁•构架模式的参考文献由第I卷[Buschmann 96】和第2卷[Schmidt 00]组成，第1卷 讨论了 MVC和PAC模式，第2卷讨论了面向模式的软件构架。

 

关于Simplex构架的可用性的讨论.请访问网站hnp://www.sei.cmu.edu/simplex/。

 

[Bachmann 02]对把战术作为可修改性和性能分析的锥础进行了讨论：[Chretienne 95] 讨论了各种类型的调度理论：[Briand 99]讨论了耦合的度盟指标,，

 

梭型-视图-控制器模式编档在[Gamma 95]中：表述-抽象-控制模式编档在[Buschm ann96]中；Secheim 模式编档在[Pfaff 85]中；Arch/Slinky 模式编档在[UIMS 92]中。