4.4.3性能

 

性能与时间有关。事件（中断、消息、用户请求或时间已到）发生时.系统必须对其 做出响应。事件到达和响应有很多特性，但性能苺本上与事件发生时，将要耗费系统多长 时间做出响应有关。

 

在使性能变得复杂的众多因素中，其中一个因素就是事件源的数量和到达模式。事件 可以来自用户请求、其他系统或系统内部。基于Web的金融服务系统从其用户处获得事件 (大概有数千或数万个）。引擎控制系统从“时间已到"处获得请求，必须控制汽缸在正 确位置时的点火，并控制燃料的混合，以使功率最大，污染最小。

 

对基于Web的金触系统，响应可能是在一分钟内可以处理的交易的次数。对于引擎控 制系统，响应可能是点火时间的变化。在每种情况下，均可以刻画事件到达模式和响应模 式，这种刻画形成了用于构造一般的性能场景的语言。

 

 

性能场欺首先以到达系统的对某种服务的请求开始。满足该请求需要消耗资源。在这 •请求到达时.系统能同时为其他请求提供服务。

 

可以将事件的到达模式刻画为周期性的或随机的。例如，周期性事件可以每隔10毫 秒到达。在实时系统中馗常看到周期性事件的到达。随机到达意味打哳件楚根据某种概率 分布到达的。啦件也可以偶尔到达.也就是说，以•种周期性或随机特性均不能捕获的模 式到达。

 

还可以通过改变事件的到达模式对多个用户或其他负载因素进行建模。换句话说，从 系统性能的角度来说，它并不关心是-个用户在一段时间内提交了 20个请求，还是两个 用户在这段时间内每人提交了10个。重要的是在服务器端的到达模式和请求中的依赖关系。

 

可以用等待时间（刺激到达和系统对其做出响应之间的时间）、处理期限（例如，在 发动机控制器屮，当汽缸在某个特定位置时，就应该把燃料点燃，这就引入了处理期限问 题）、系统吞吐量(如系统在一秒钟内可以处理的交易次数）、响应抖动（等待时间的变化)、 由于系统太忙因而无法做出响应所导致的未处理事件的数量，以及因为系统太忙所丢失的 数据.

 

请注意，以上论述并没有考虑到系统是联网的还是单机的。然而.，它也没有考虑系统的配置或资源的消耗。这些问题依赖于构架解决方案.我们将在第5章讨论此问题。

 

性能的一般场景。从这这些考虑事项中我们可以看出性能的一般场景的组成部分，图 4.5给出了个示例：用户随机启动了在正常操作下每分钟1000次的交易，处埋这些交易 的平均等待时间为2秒。

 

•    刺激源.刺激来自外部（有可能是多个）或内部源。在我们的例子中.该刺激源 是用户的集合。

 

•    刺激,，刺激是事件到达。可以把到达模式刻画为周期性的、随机的或偶然的。在 我们的例了-中，刺激是随机启动每分钟1000次的交易。

•    制品正如在我们的例子中一样，制品总是系统的服务„

 

•    环境。系统可以处在各种操作模式下，如正常、紧急或超载模式。在我们的例子 中，系统处于正常模式。

 

•    响应。系统必须处理到达的事件。这可能会导致系统环境的变化（例如，从正常 模式变为超载模式)。在我们的例子中，交易被处理。

 

•    响应度置.，响应度最就是系统处理到达的事件所用的时间（等待时间或必须处理 事件的期限）、该时间的变化（抖动）、在某一特定时间间隔内可以处理的事件数量（吞吐量)或对不能处理的事件的描述（缺失率、数据丢失）。在我们的例子 中，应该在平均等待时间2秒内处理交易。

 

表4.3给出了刻画性能的一般场景的元素。

 

在软件过程发展史的大部分时间内，性能一直是促使系统构架发展的重要驱动力。同 样.它也经常影响所有典他质最属性的实现。随着硬件性价比的急剧下降和软件开发成本 的提高，其他质量厲性的地位己经和性能这一属性不相上下了。

 

4.4.4安全性

 

安全性是衡量系统在向合法用户提供服务的同时，阻止非授权使用的能力。试图突破 安全防线的行为被称为攻击（一些安全专家使用“威胁”)，可以有很多形式。它可以是未 经授权试阁访问数据或服务.或试图修改数据，也可能是试图使系统拒绝向合法用户提供 服务。

 

对很多介质来说，攻击经常发生，其范围从进行电子转账时盗取资金到修改敏感数据： 从盗窃信用卡号到破坏计算机系统上的文件，以及由蠕虫或病毒执行的拒绝服务攻击。尽 管如此，安全性的一般场景的元素与其他一般场景的元素是相同的——刺激、源、环境、

攻击目标、所期望的系统响应以及对该响应的度量。

 

可以把安全性刻画为一个提供认可、机密性、完整性、保证、可用性和审核的系统。 对于每条，我们都提供一个定义和一个示例。

 

(1)认可就是交易（访问或修改数据或服务）不能被交易的任何一方拒绝的属性。这意味着如果您通过Internet定购了某个项目的话.就不能否认。

 

(2)机密性就是未经授权不能访问数据或服务的属性。这意味蒞黑客不能访问您在 某台政府汁算机上的所得税申报表。

 

(3)完整性是根据计划来提交数据或服务的属性。这盘味着自从老师给您分配等级 后，等级就没有改变过。

 

(4)保证就是交易的各方是所声称的人的厲性。这意味着当客户发送一个信用卡卡号到Internet商家时，该商家就是客户所认为的商家。

 

(5)可用性就是系统可用于合法用途的属性。这意味着相绝服务攻击不会阻碍您定 购“本”书。

 

(6)审核是系统在其内部跟踪活动的属性，跟踪的级别足以对活动进行重构。这意 味着如果您在瑞士把资金从一个账户转到另一个账户，系统将会把转账过程记录下來。

 

在这几类安全性中，每一类都产生了一个一般场景的集合。

 

安全性的一般场景。下面给出了安全性的-般场景的各部分。围4.6给出了一个示例。

 

一个经过了身份验证的个人试图从外部站点修改系统数据；系统维持了一个审核踪迹，并 在一天内恢复了 正确的数据。

 

•    刺激源。攻击源可能是人，也可能是另一个系统，可能以前已经确定了该攻击源

(正确地或错误地)，也可能当前还是未知的。如果攻击源有很强的动机（比如政 治动机)，那么，诸如“我们知道你是谁，我们将起诉你”这样的防御措施很可 能不会秦效；在这种情况下，用户的动机可能是重要的。如果攻击源能够访问大 量的资源（如政府部门），那么，防御措施就非常困难。攻击本身是未经授权的 访问、修改数据或拒绝服务。

 

安全性所存在的困难是允许访问合法用户并确定合法性。如果惟一的目标就 是阻止访问系统，那么，禁止所有访问就是一个有效的防御措施..

 

•    刺激    刺激就是攻击或试图违反安全性。我们把这刻画为未经授权的人或系统试 图显示信息、改变和/或删除信息、访问系统服务或降低系统服务的可用性。在图 4.6中，刺激就是试图修改数据。

 

•    制品     攻击的目标可能是系统提供的服务，也可能是系统中的数椐。在我们的例 子中，目标是系统中的数据。

 

•    环境    遇到攻击时有很多种可能的情形：在线或离线；联网或与网络断幵；连接

有防火墙或直接连到了网络上。

 

•    响应。未经授权使用服务或阻止合法用户使用服务的目的不同于查看敏感数据或 修改敏感数据。因此，系统必须授权合法用户.并保证他们能够访问数据和服务， 同时拒绝未经授权的用户，拒绝他们访问，并报告米经授权的访问。系统不仅需 耍提供对合法用户的访问，而且需要支持访问的授予或撤消。防止攻击的一个手 段是，维持修改或试图访问的审核踪迹，以此让攻击者对将会遭受的惩罚产生恐 慌心理，进而使其放弃攻击。在从一次得逞的攻击中恢复过来时.审核踪迹也是 很有用的。

 

•    响应度量.系统的响应度量包括发动各种进攻的困难程度和从攻击中恢复过来从 而幸免于难的困难程度。在我们的例子中，审核踪迹能够使被盗用的账户恢复到 最初状态。当然，盗用资金者仍然挪用了资金，但我们必须追捕他并收回他所盗 用的资金，这已经超出了计算机系统的讨论范围。

表4.4给出了安全性的-般场景生成表。

 

4.4.5可测试性

软件可测试性是指通过测试（通常是基于运行的测试）揭示软件缺陷的容易程度。在 开发设计良好的系统的成本中，至少有40%是用在了测试上。如果软件设计师能够降低此 成本，则将会收到巨大的回报。

 

特别地，可测试性是指假设软件中至少有-个错误，软件在“下次"测试运行时不能 正常工作的可能性。当然，计算这种可能性并不容易，在谈到响应度量吋.将使用其他度量指标。

 

要想对系统进行正确的测试.必须能够“控制”每个组件的内部状态及其输入，然后 “观察”其输出。这通常通过使用“测试工具（test harness) ”进行，这是一种专门设计 的软件，用于执行所测试的软件。这可能会如同在各种接口上回放己记录的数据一样简单, 也可能会像测试发动机的燃烧室-样复杂。

 

测试由各种开发人员、测试人员、验证人员或用户进行，它是软件生命期各部分的最 后一步。可以对代码部分、设计和整个系统进行测试。可测试性的响应度最处理的是测试 在发现缺陷方面的效率，以及要想达到某个期望的覆盖范围.需要用多长时间进行测试。

 

可测试性的一般场景.。图4.7给出了可测试性场景的一个示例，它所关注的是一个单元测试的性能：单元测试人员在一个已完成的系统组件上执行单元测试，该组件为控制其 行为和观察其输出提供了一个接口；在3个小时内测试了 85%的路径。

 

•    刺激源。该测试由单元测试人员、集成测试人员、系统测试人员或客户执行。可 以由其他开发人员或外部小组执行设计测试。在我们的示例中，测试由某个测试 人员执行。

 

•    刺激    该测试的刺激是到达了开发过程中的一个里程碑。这可能是完成了分析或

设计的增量；完成了编码增量（如某个类）、完成了子系统的集成或完成了整个 系统。在我们的例子中，测试由完成了代码单元触发。

 

•    制品.    设计过程、一段代码或整个系统都是被测试的制品。在我们的例子中，要 进行测试的是代码单元。

 

•环境.        该测试可以在设计时、开发时、编译时或部署时进行。在图4.7中，测试 是在开发时进行的。

 

•响应。    由于可测试性与可观察性和可控制性相关，因此所期望的响应就是可以控 制系统以执行所期望的测试，并且可以观察到对每个测试的响应。在我们的例子 中，可以控制该单元并捕获其响应。

 

•响应度量。响应度量就是在某些测试中执行的语句的百分比，最长测试链的长度 (对执行测试的困难的度量）以及对发现额外的缺陷的可能性的估计。在图4.7 中，度量就是可执行语句的百分比。

表4.5给出了可测试性的一般场景的生成表。

 

4.4.6易用性（也可以称为对用户的友好性，健壮性，好用，比如：进度条，状态栏界面元素的使用，填写复杂表单，返回上一个表单时，信息还在。响应式、自适应性布局）

 

易用性关注的是对用户来说完成某个期望任务的容易程度和系统所提供的用户支持 的种类。可以将易用性分为如下几个方面：

 

•    学习系统的特性。如果用户不熟悉某个特定的系统或该系统的某特定方式，那 么，系统可以如何使学习任务变得更容易？

 

•    有效地使用系统 系统如何能提高用户的操作效率？

 

•    将错误的影响降到最低。系统怎样使用户所犯的错误造成的影响最小？

 

•    使系统适应用户的需要。用户（或系统本身）可以如何使用户的任务变得更轻松？

 

•    提高自信和满意度。系统可如何使用户确信采取了正确的行动？

 

在过去的5年中，我们已经加深了对易用性和软件构架之间的关系的理解（参见引文 “我对易用性应负的责任”)。正常的开发过程通过构建原型和进行用户测试来检测易用性 问题。问题发现的越晚，修复对构架的影响就越大，时间和预箅方面也就越紧张。在我们 的场景中，我们所关注的是易用性对构架有主要影响的方面。因此，在构架设计开始前， 这些场景必须是正确的，以便在用户测试或建立原型时不会发现易用性问题。

 

我们一直声称系统的质量主要源于构架的质量，在本书的第1版中.我们有时会在没 有足够证据时，试图对此进行证明.然而，在构架的质量和系统的质量之间存在很强大的 关系。在这5年的时间里，我们一次又一次地认识到这一点。实际上，所有的证据都证明 了这一点，事实证明易用性也不例外。许多易用性问题都是属于构架方面的..实际上，准 确地说最难实现的易用性（尤其是那些在系统构建完成后最难添加的特性）就是那些属于 构架方面的特性.

 

如策您想使用户能够在进展中取消某项操作，返回操作开始前系统所处的状态，就需 要在构架中规划该能力。同样，如果您想使用户能够撤销以前的某个操作，而且想给用户 提供操作的进展的反馈，也需要在构架中规划。还有许多其他的例子。

 

易用性的一般场景“图4.8给出了易用性场景的一个示例：想把错误的影响降到最低 的用户希望在运行时取消系统操作，取消在1秒内发生。易用性的一般场景的几个部分为：

 

•刺激源。最终用户永远是刺激源。

 

•刺激、刺激是最终用户想有效地使用系统，学习使用系统，把错误的影响降到最 低，适配系统或对系统感到满意。在我们的示例中，用户希望取消操作，这是把 错误的影响降到最低的个示例。

 

•制品.    制品通常都是系统。

 

•环塊    易用性所涉及的用户操作总是在运行时或系统配置时发生。在此之前发生 的任何操作都由开发人员执行，尽管用户也可能是开发人员，但即使是由同一个 人执行，我们也对这两个角色加以区分。在图4.8中，取消是在运行时发生的。

 

•响应。  系统应该为用户提供所需要的特性，或预计到用户的需要。在我们的例子 中.取消是按照用户的意愿进行的，系统恢复到以前的状态。

 

•响应度量。该响应由任务时间、错误的数量、所解决问题的数量、用户的满意度、 用户知识的获取、成功操作在总操作中所占的比例.错误发生时所损失的时间或 丢失的数据。在图4.8中，取消应该在1秒内发生。

 

表4.6给出了易用性的一般场景生成表。