本书全面阐述了关于创建具有响应性和可伸缩性软件所涉及的从体系结构问题到建模、度量标准和过程的各个方面，详细介绍了各种软件性能工程模型，讨论了如何根据面向对象开发过程的部分产品—体系结构和设计模型快速而轻松地建立定量模型，介绍了有效的数据采集技术和性能测量技术，探究了面向性能的设计原则。此外，本书中包括大量实时应用和案例研究，说明了如何将软件性能工程技术应用到重要应用领域，例如Web应用和嵌入式实时系统。
本书主要面向经验丰富的软件开发人员，同时也可以为项目经理、开发人员、性能工程师提供参考，还可以作为高等院校相关专业软件工程课程的教材。
我喜欢有计划的行动。
—John“Hannibal”Smith上校
“The A-Team”
作为软件开发人员的顾问、教师和指导者，我们看到太多的软件产品在最初构建时没有满足性能目标。解决这些问题代价高昂并且会造成进度延误、费用超支、生产率降低、客户关系紧张、市场机遇（market window）丧失、收益减少以及其他一大堆困难。极端的情况是，如果不进行大范围的重新设计和重新实现就不可能解决性能问题。有这种情况的项目会变成吞噬时间和金钱的无底洞，或者幸运地被取消。
这些问题可以通过系统地应用一些简单的性能分析和预测技术来避免。在过去的数年里，我们已经帮助许多客户开发满足性能目标的软件，并且准时发布，开销在预算范围内。本书是应客户和学生的要求而写的，以便对我们成功地使用和教授的技术提供参考。
目标
本书可以回答诸如此类的问题：
用户能在目标时间内完成任务吗？
硬件和网络能否处理这些负载？
系统能否扩展以满足未来的需要？
更重要的是，为了避免在投入大量时间和资金来实现项目却发现结果是断然的（而且是昂贵的）否定答案，你通过本书能够回答这些问题。
读者学完本书就可以立刻开始应用这些技术控制软件系统的性能。通过在许多种项目（包括基于Web的应用、分布式系统、实时系统、传统的数据库应用以及其他应用）中应用这些技术，你的技能将会逐渐提高。
软件性能
性能是软件产品的一种特征，原则上，你可以坐在计算机前手持秒表来测量。性能的范围包括响应性（响应时间或吞吐量）和可伸缩性。
项目如何出现性能问题？常常是因为对如何实现性能目标的根本误解。经常采用的方法是：“先让系统运行起来；然后让它转得更快。”这种观点是先实现正确的功能，然后再调节性能。不幸的是，在选定体系结构和设计方案之后，想通过调整来获得适当的性能可能为时已晚。认为潜在的性能问题与编码错误具有相同的复杂度也是错误的。编码错误相对容易改正，而性能问题可能需要大范围地修改代码。
控制软件性能的正确方法是：在整个开发过程中，系统地规划和预测正在形成的软件的性能。本书提出一套可以用来控制软件性能的简单技术，这些技术不需要高深的数学基础，也不会占用开发活动的大量时间。应用这些技术，可以在体系结构和设计方案中做出明智选择，并且充满信心地前进，因为你能控制软件将达到的性能目标。
本书提出的管理性能的方法是独一无二的。它来自于两位作者十多年来的合作，综合了软件性能工程和体系结构分析两方面的知识和经验。其他作者提出的优化建模技术，要么无助于实时系统，要么要求有数学博士学位才能应用。我们的方法实践性强、严密，非专家就可以应用。
软件性能工程
本书提出的技术统称为软件性能工程（SoftWare Performance Engineering, SPE）。SPE是控制性能的一种综合方法，包括创建响应性软件的原则、面向性能设计的性能模式和反模式、引出性能目标的技术、收集评估所需数据的技术，以及对开发过程各阶段需要进行的评估类型的指导。
SPE以模型为基础。建模是SPE和面向对象开发的核心。通过建立和分析软件的模型，能够探究其特性以便在真正交付实施前确定它能否满足需求。SPE利用模型定量评价形成中软件的性能。本书讨论如何根据面向对象开发过程的部分产品—体系结构和设计模型，快速而轻松地建立定量模型。
最后，这些技术既不是什么新技术也不具有革命性，它们是从有相当长历史的、被证实的量化规则中演化而来的。它们也不是银弹（silver bullet）。它们必须被使用才能生效，而且需要一些时间来学习如何应用，尤其是在最初的项目中。然而需要的时间并不太多，这适合于大多数项目的早期阶段。我们已经发现，当问题不可避免时，选择是：“要么是现在付出一点儿（为了你需要的可伸缩性和性能），要么是以后付出更多。”软件度量标准表明：解决代码中的问题比写代码之前解决体系结构中的问题要多付出高达100倍的代价。确定问题是否不可避免的惟一方法是尽早应用本书描述的量化技术。
本书读者对象
本书主要面向经验丰富的软件开发人员，他们已经在一个或多个开发项目中使用了面向对象的技术并且准备好进行下一步：学习如何开发具有内在可伸缩性和性能的软件系统。重点是如何应用这些技术。
其他读者也可以从本书中找到能使用的信息：
项目经理可以找到能立刻引入到项目中改进性能控制方法的技术，还可以学习如何实现SPE。
对于面向对象技术还是新手的开发人员，将发现如何使面向对象系统的性能控制成为可能，并找到建立具有响应性的软件的指导，这些软件深化了面向对象开发过程的研究。
性能工程师将学到如何使他们的技能适应面向对象系统，以及可应用于其他开发技术的新方法。
学生将学到在实际的、大规模的软件系统中出现的有关性能问题，以及应该如何应对它们。
精通面向对象概念会有帮助，但不是必须的。我们会解释对性能评估有用的部分统一建模语言（UML）符号。如果读者觉得自己需要更多的背景知识，请参考对象技术方面的其他书籍。
熟悉性能建模技术会有帮助，但不是必须的。我们假设读者将使用诸如SPED这样的SPE工具评估系统。我们还将对建模基础进行足够多的解释，以便使读者熟悉这些工具是怎样工作的。
本书内容
本书由以下几部分组成：
第一部分：概述。SPE的简要介绍和建模技术概述。
第二部分：SPE模型。描述SPE及其解决方案中所用模型的详细内容。
第三部分：数据采集。讨论如何获取SPE数据，并给出关于性能测量技术的一些背景知识。
第四部分：性能解决方案。提出在软件系统中设计性能并在整个生命周期中维护性能的技术。
第五部分：应用。说明SPE技术在一些重要类型的应用领域中的应用。
第六部分：实现SPE。讨论如何在开发组织中实现SPE。
附录。汇总全书使用的符号。
怎样阅读本书
对于本书，不同的人有不同的阅读理由，对其中的信息有不同的需求。下表针对几类读者给出阅读本书内容的方案建议。表中给出的读者类型是：
第一部分 第二部分 第三部分 第四部分 第五部分 第六部分
开发人员 A1 A2 A3 A4 A5 A6
经理 A1 C1 B1 B2 B3 A2
性能工程师 A1 A2 A3 A4 A5 A6
“消防”人员 A1 A4 A2 A3 A5 B1
学者 A1 A2 A3 A4 A5 B1
开发人员—负责软件开发并且需要保证代码满足性能目标。这类读者需要了解书中所有内容：什么是SPE、它能做什么、如何构造并评估模型、如何在软件中设计性能以及如何将SPE纳入到开发过程中。
经理—作为经理，必须了解SPE是什么、它能做什么、如何将它纳入软件开发过程中。建模的细节不那么重要。
性能工程师—负责与开发人员合作，辅助他们对其系统进行定量分析。这类读者必须了解的内容：如何解释SPE以及它能为开发人员做什么、如何构造并评估模型、如何识别和解释性能解决方案和性能问题以及如何将SPE纳入到开发过程中。
“消防”人员—面对有性能问题的系统，需要帮助系统摆脱困境。息事宁人后，可以回去并应用SPE技术，以免在将来的系统中出现这些问题。
学者—本书中的素材可以用作软件性能工程研究生课程的基础。但是，将SPE集成到软件开发过程中和实现SPE这两部分可能不太重要。
表中的各项用字母来表示对于不同读者，书中每一部分的优先级或重要性（A是至关重要，B是重要，C是有一些价值）。数字表示各部分应该阅读的顺序（1是首先阅读，2是其次阅读，以此类推）。
格式约定
特别重要的观点、意见和指导原则用手形图加楷体字强调，如下所示：
在体系结构阶段和早期设计阶段，软件执行模型一般足以用来识别严重的性能问题。
一个主题的描述经常引用其他地方讨论的另一个主题。为了帮助建立联系，在相应的位置用仿宋体提供交叉引用，如下面的例子所示：
软件执行模型的讨论在第4章。
除此之外，附加的评论和总的指导原则作为注释单独列出，如下面的例子所示：
注：执行图与程序流程图类似，但并不相同。执行图说明路径执行的频率，而且只模拟那些对性能比较关键的路径。
例子和文中其他重要但有可能打断正文的部分都被分开，如下所示：
例1-1 性能失败
呼叫处理 对电话交换机呼叫处理系统的重新实现，在开发初期也没有考虑性能问题。初始的面向对象设计需要所规定时间的几百倍才能完成一次呼叫。
互联网上的SPE
本书中的模型和SPE-ED工具的演示版都在互联网上，网址是http://www.prefeng.com/ PerfSolutions/models。关于SPE的其他信息在http://www.perfeng.com。有一个关于SPE的在线讨论组，网址为http:// www.egroups.com/group/softwareperfeng/。
如果你发现本书中的错误，请将其电邮到perfSolutions@perfeng.com，我们将定期把它们发送到http://www.perfeng.com/PerfSolutions/errata。
致谢
本书在出版之前经过了大量复查，甚至进行了“领域测试”。Thad Jennings和Brent Reeves审阅了每章早期的草稿，他们的意见有助于我们把内容重点放在目标读者身上，他们还提出了许多有益的建议。Rob Sartin仔细审阅了第12章后，建议增加几个有意义的部分。
Inkeri Verkamo（芬兰赫尔辛基大学）和Ken Sevcik（多伦多大学）将第1章至第9章的初稿作为软件性能工程的研究生课本，他们的反馈信息帮助我们确定那些需要进行进一步阐述的主题，并且证明本书作为SPE的介绍性课本是有用的。
我们还要感谢Addison-Wesley出版社的“官方”审阅者们：Paul Clements、Sholom Cohen、Bob Glass和Jerry Rolia，他们的不同观点使本书的内容得以改进，并确保了我们的内容更加集中于读者需要了解的内容。
最后，我们要向Paul Becker和Addison-Wesley出版社的其他编辑和制作人员以及janet Butler致谢，他们在本书出版的过程中给予了支持。
Connie U. Smith Lloyd G. Williams
于新墨西哥州圣达菲 于科罗拉多州巨石城
2001年 5月 2001年5月
软件开发团队需要面临多种压力，最主要的压力是对功能、成本、进度以及与原有系统兼容的要求。“churn”（减少客户流失）技术以及对复原力（resilience）的要求，特别是在大多数以Web为中心的系统中出现的连续变化，也是一种压力。安全性、自动防故障/容错、可靠性/可用性依据各种应用领域也产生了压力。最后（很不幸，通常最后才被考虑）是容量、响应性、可伸缩性以及性能所带来的压力。
即使开发团队在预算内、按照进度开发出了最优秀的功能系统，但如果系统行为不符合用户的要求，那么整个项目仍然是失败的。传统观点建议把响应性和可伸缩性放在后面考虑，但是Connie和Lloyd指出不应如此：性能是已构造系统的内在要素，不可能简单地指望一个低劣的系统能有好的质量，就像不能通过简单地修复使一个正在运行的系统变得更好一样—原因通常出自内部，源于系统的体系结构。
我认为读者手中这本书更好的名字应该是“你希望了解的但没有时间也无处可问的关于软件性能的一切”。Connie和Lloyd编写了一本关于性能实践和性能问题的易读、实用的书。这本书不仅可读性强，而且覆盖了关于创建具有响应性和可伸缩性软件所涉及的从体系结构问题到建模、度量标准和过程的各个方面。
Connie和Lloyd在这个领域有着丰富经验，他们在本书中将这些经验与大家分享。我从他们那里学到了很多东西，确信其他读者也会一样获益。
Grady Booch
Rational Software公司首席科学家
2001年4月
数十年来软件性能工程一直是专家研究的学术。理由很充分：它需要技巧。直到现在，对这个主题的很多论述仍无可救药地停留在排队论、马尔科夫（Markov）分析和深奥的调度算法等这些细节上。这个领域比其他任何东西都更像是一个老船员的航海图，图的角落醒目地标着“这里有魔鬼”，只有勇敢者冒险向前。组织中的性能工程师（竟然有性能工程师？真是少见）是自学成才的而且未被充分使用，他们默默的贡献几乎不被人所知，在自助餐厅里他们往往独自进餐，咕哝着一些听上去似乎是斐波纳契（Fibonacci）序列之类的东西。
这种情况不会再继续下去了。随着我们的行业逐渐成熟，已经有力量驱逐这些错误观念了。
首先，要求已经明确。所有安全性很重要的软件（如今其数量大得惊人）其性能也是非常关键的。一个关系到人的健康和安全或者环境的系统，没有谁会使用它而不首先确定它是否满足性能约束。问问那些研制防锁制动系统、医疗X射线控制器或电子设备软件的人们，性能是否很重要。他们会告诉你那是惟一要紧的事情。但是我们也已经认识到（即使已经晚了）所有软件都具有性能约束。如果你不相信，那么在下一次工作站操作系统没有什么明显的原因便出示小小的沙漏符号，而你点击鼠标、等待打开文件并低声地数到10的时候，再来回顾这个问题。如果你数到10、8甚至2，那么你就是一个性能问题的受害者。
其次，性能工程领域本身正在成熟，并正在产生一系列最佳实践，非专家也能应用并获得同样的成功。Connie Smith和Lloyd Williams一直站在这项成熟技术的前沿，他们确立了自己不仅是在性能工程理论上而且也是在性能工程实践方面的世界知名专家的地位。如果对Connie和Lloyd你还抱着“能者为之、不能者教之”的老观念，那你可就大错特错了。他们不仅能而为之，而且对我们来说更幸运的是，他们也能教之。他们有数十年帮助开发组织避开性能工程陷阱（或从中爬出来）的经验，并以此为基础，使性能工程名副其实。这些技术容易掌握而且立即可以应用。
第三，与软件体系结构正在形成的规律相一致，我们意识到，在建立系统之前，在所有错误决定被付诸代码实现之前，尽我们所能地认识系统的重要性，能够避免为改正错误而付出高昂代价。
简言之，性能工程最终（向作者致以最大感谢）将满足对它的新“要求”，这些要求来自建立真正的系统、面对真正挑战的真正的开发组织。
因此，是出一本书的时候了，但那只是事情的一半。这不是普通的一本书。通读这本书的时候，给我留下深刻印象（而且使我充满感激）的是，Connie和Lloyd从没忘记他们在为谁而写。每一页都循循善诱，那是直接讲给实践者的。人们对有用（相对于仅供娱乐）的书往往只读一次，但对参考书可能会读上几十或上百次，认识到这一点的作者是明智的。这本书的作者们对采用的文体约定深思熟虑，使本书更容易使用而且效率更高。某个信息在哪里用到、定义它的原文的位置都被列举出来，以供快速查阅、帮助读者回忆；举例与内容的主体被清晰地分开；重要原则用黑体显示；用以补充信息的注释随处可见，但是被直观地区分开以便不打断正文。有些技术书籍会使你觉得自己像是一个跳伞运动初学者，指导者只是冷漠地命令你“跳！”本书不是。每一步他们都和你在一起。
结果就是这样的一本书，它彻底地阐明了性能工程的工作（不再是学术）。走开吧，魔鬼！走开吧，专家！它使你觉得确实可以独立地完成工作。感谢Connie和Lloyd，你们会成功！
Paul Clements
卡内基－梅隆大学软件工程研究所（SEI）
2001年5月
（美）Connie U.Smith,Lloyd G.Williams：暂无简介
唐毅鸿 杨朝晖 刘倩羽：暂无简介
第一部分 概 述
第1章 引言 3
1.1 软件和性能 3
1.1.1 响应性 3
1.1.2 可伸缩性 4
1.2 性能的重要性 5
1.2.1 性能失败的影响 6
1.2.2 性能失败的原因 7
1.2.3 获得成功 8
1.3 如何管理性能 9
1.3.1 被动性能管理 9
1.3.2 主动性能管理 10
1.4 软件性能工程 11
1.4.1 SPE建模策略 12
1.4.2 SPE模型 12
1.5 面向对象系统的SPE 13
1.5.1 SPE的成本是多少 14
1.5.2 SPE需要什么 14
1.6 小结 15
第2章 SPE快速浏览 16
2.1 面向对象系统的SPE过程 16
2.2 案例研究 19
2.2.1 评估性能风险（第1步） 19
2.2.2 确定关键用例（第2步） 19
2.2.3 选择关键性能场景（第3步） 20
2.2.4 建立性能目标（第4步） 21
2.2.5 构造性能模型（第5步） 21
2.2.6 确定软件资源需求（第6步） 21
2.2.7 增加计算机资源需求（第7步） 22
2.2.8 评价模型（第8步） 24
2.2.9 验证和确认模型（第9步） 24
2.3 统一软件过程中的SPE 24
2.4 性能解决方案 25
2.4.1 性能原则 25
2.4.2 性能模式 26
2.4.3 性能反模式 26
2.4.4 实现解决方案 26
2.5 小结 27
第3章 SPE和UML 28
3.1 简介 28
3.2 扩展UML 28
3.2.1 构造型 29
3.2.2 标签值 29
3.2.3 约束 29
3.3 用例和场景 29
3.3.1 用例 30
3.3.2 场景 31
3.4 扩展顺序图符号 33
3.4.1 实例分解 33
3.4.2 循环、分支和引用 33
3.5 规定时间 35
3.5.1 定时标记 35
3.5.2 时间表达式 36
3.5.3 定时约束 36
3.5.4 顺序图中的时间 36
3.6 并发 37
3.6.1 线程和进程 38
3.6.2 Coregions 38
3.6.3 并行组合 39
3.6.4 同步 39
3.7 小结 41
第二部分 SPE模型
第4章 软件执行模型 45
4.1 目的 45
4.2 表示软件执行模型 46
4.2.1 执行图 46
4.2.2 执行图限制 49
4.3 模型解决方案 50
4.3.1 基本求解算法 51
4.3.2 更先进的求解技术 53
4.4 分析过程 53
4.5 由顺序图派生出的执行图 56
4.6 ICAD案例研究 56
4.6.1 体系结构1 57
4.6.2 体系结构2 61
4.6.3 结果分析 62
4.6.4 体系结构3 63
4.7 建模提示 65
4.8 小结 66
第5章 Web应用及其他分布式系统 67
5.1 简介 67
5.2 Web应用 68
5.3 分布式对象技术 69
5.3.1 中间件 70
5.3.2 分布式对象技术的局限性 70
5.3.3 利用分布式对象技术进行有效
开发 72
5.4 为分布式系统交互建模 72
5.4.1 系统交互的类型 73
5.4.2 软件执行模型表示 75
5.4.3 描述中间件开销 76
5.4.4 软件模型的近似求解 76
5.5 举例：Web电子商务应用 77
5.5.1 数据库场景 80
5.5.2 订购过程场景 81
5.5.3 实例小结 82
5.6 建模提示 82
5.7 小结 82
第6章 系统执行模型 84
6.1 引言 84
6.2 系统模型基础 85
6.2.1 性能度量标准 86
6.2.2 求解排队模型 88
6.2.3 排队网络 89
6.3 从软件模型结果得到系统模型参数 92
6.4 利用系统模型进行SPE 94
6.4.1 先进系统模型 95
6.4.2 可选的求解方法 95
6.4.3 可调度性 96
6.5 分布式系统案例研究 96
6.6 建模提示 103
6.7 小结 104
第三部分 数 据 采 集
第7章 SPE数据采集 107
7.1 简介 107
7.2 SPE数据需求 107
7.2.1 关键性能场景 108
7.2.2 性能目标 108
7.2.3 运行环境 109
7.2.4 软件资源需求 110
7.2.5 计算机资源需求 111
7.2.6 数据采集问题 112
7.3 性能遍历 112
7.3.1 主题 113
7.3.2 何时进行性能遍历 114
7.3.3 举例 115
7.3.4 成功进行性能遍历的提示 120
7.4 资源估算技术 122
7.4.1 使用测量 122
7.4.2 研究测量结果 122
7.4.3 请教顾问 122
7.4.4 最佳最差情况估算 123
7.4.5 估算什么 123
7.4.6 估算I/O需求 123
7.4.7 估算网络消息 124
7.4.8 获得计算机资源需求 125
7.5 小结 125
第8章 软件测量和探测 127
8.1 引言 127
8.2 应该测量什么 127
8.2.1 负载数据和数据特征 129
8.2.2 路径特征 129
8.2.3 软件资源和处理开销 129
8.2.4 计算机资源的使用 129
8.3 规划性能测量 129
8.3.1 关键考虑事项 130
8.3.2 性能基准程序 130
8.3.3 设计和指导测量研究 131
8.4 性能测量概念 133
8.4.1 术语 133
8.4.2 可能影响测量的因素 135
8.5 数据采集技术和工具 137
8.5.1 数据采集技术 137
8.5.2 测量SPE数据 139
8.6 探测技术 140
8.6.1 探测的设计考虑 141
8.6.2 实现可选方案 142
8.6.3 数据报告 143
8.7 应用资源测量 143
8.8 小结 145
第四部分 性能解决方案
第9章 面向性能的设计 149
9.1 面向性能的设计原则 149
9.2 性能控制原则 149
9.2.1 性能目标原则 150
9.2.2 探测原则 150
9.3 独立原则 151
9.3.1 中心化原则 151
9.3.2 固定点原则 152
9.3.3 本地化原则 153
9.3.4 处理与频率原则 154
9.4 协作原则 155
9.4.1 共享资源原则 155
9.4.2 并行处理原则 156
9.4.3 分散负载原则 157
9.5 使用原则 157
9.6 小结 159
第10章 性能模式 160
10.1 概述 160
10.2 快速通道 161
10.2.1 问题 161
10.2.2 解决方案 162
10.2.3 优点 163
10.2.4 后果 163
10.3 重要事情优先 163
10.3.1 问题 164
10.3.2 解决方案 164
10.3.3 优点 165
10.3.4 后果 165
10.4 耦合 165
10.4.1 问题 165
10.4.2 解决方案 166
10.4.3 优点 166
10.4.4 后果 166
10.5 批处理 167
10.5.1 问题 167
10.5.2 解决方案 167
10.5.3 优点 168
10.5.4 后果 168
10.6 替代路由 169
10.6.1 问题 169
10.6.2 解决方案 169
10.6.3 优点 170
10.6.4 后果 170
10.7 弹性时间 171
10.7.1 问题 171
10.7.2 解决方案 171
10.7.3 优点 172
10.7.4 后果 172
10.8 弱化周期性功能 172
10.8.1 问题 172
10.8.2 解决方案 173
10.8.3 优点 173
10.8.4 后果 173
10.9 小结 173
第11章 性能反模式 175
11.1 概述 175
11.2 “god”类 176
11.2.1 问题 176
11.2.2 解决方案 178
11.3 过量动态分配 178
11.3.1 问题 179
11.3.2 解决方案 180
11.4 迂回寻宝 180
11.4.1 问题 181
11.4.2 解决方案 182
11.5 单行道桥梁 183
11.5.1 问题 184
11.5.2 解决方案 184
11.6 交通堵塞 186
11.6.1 问题 186
11.6.2 解决方案 186
11.7 小结 186
第12章 实现解决方案 188
12.1 概述 188
12.2 性能调整 189
12.3 一般性能解决方案 191
12.3.1 快速通道加速法 192
12.3.2 改进可伸缩性 192
12.3.3 算法和数据结构的选择 195
12.3.4 时间与空间的折中 195
12.3.5 硬件/软件平台的依赖性 198
12.4 面向对象软件的性能解决方案 198
12.4.1 跨语言解决方案 198
12.4.2 C++解决方案 201
12.4.3 Java解决方案 201
12.5 小结 204
第五部分 应 用
第13章 Web应用 207
13.1 引言 207
13.2 性能问题 208
13.3 Web应用的SPE模型 209
13.4 案例研究：Nachtfliegen.com 211
13.4.1 计划航线场景 213
13.4.2 软件模型 215
13.4.3 硬件/软件环境 216
13.4.4 资源需求 218
13.4.5 软件模型解决方案 219
13.4.6 性能改进 221
13.4.7 系统执行模型 221
13.4.8 灵敏度和可伸缩性分析 224
13.5 典型的性能问题 224
13.6 小结 226
第14章 嵌入式实时系统 228
14.1 引言 228
14.2 嵌入式实时系统背景 229
14.2.1 时间要求 229
14.2.2 硬件约束 230
14.2.3 实时操作系统 231
14.2.4 分布式系统 231
14.2.5 数据库 231
14.3 性能问题 231
14.3.1 响应时间和吞吐量 232
14.3.2 可调度性 232
14.4 嵌入式实时系统的SPE模型 234
14.5 案例研究：电话交换 235
14.5.1 概述 235
14.5.2 体系结构和设计 237
14.6 典型的性能问题 242
14.7 小结 245
第六部分 实现SPE
第15章 SPE过程 249
15.1 引言 249
15.2 SPE过程 250
15.2.1 评估性能风险 251
15.2.2 确定关键用例 251
15.2.3 选择关键性能场景 252
15.2.4 建立性能目标 252
15.2.5 构造性能模型 253
15.2.6 确定软件资源需求 254
15.2.7 增加计算机资源需求 254
15.2.8 评价模型 255
15.2.9 验证和确认模型 255
15.3 生命周期后期的SPE活动 256
15.3.1 更详细的模型 256
15.3.2 更精确的数据 257
15.3.3 性能测试 257
15.3.4 基线模型 258
15.4 软件部署后的性能管理 258
15.4.1 演进性变化 258
15.4.2 容量管理 259
15.5 SPE制品 259
15.5.1 性能管理计划 260
15.5.2 性能验证和确认计划 260
15.5.3 SPE配置管理计划 260
15.5.4 性能驱动因素 261
15.5.5 性能场景 261
15.5.6 性能目标 261
15.5.7 执行环境规格说明 261
15.5.8 性能模型 261
15.5.9 模型结果 262
15.5.10 性能测量工具 262
15.5.11 性能验证和确认报告 262
15.5.12 性能测试计划 262
15.5.13 性能测试结果 263
15.6 将SPE集成为软件过程的一部分 263
15.6.1 瀑布模型 263
15.6.2 螺旋模型 264
15.6.3 统一过程中的SPE 264
15.7 小结 266
第16章 实现SPE过程 268
16.1 引言 268
16.2 工具 268
16.2.1 建模工具 269
16.2.2 开发工具 270
16.3 采用和使用SPE 271
16.3.1 经验 271
16.3.2 关键考虑因素 273
16.3.3 试点项目 275
16.3.4 成功采用和使用SPE的关键因素 275
16.4 SPE实现策略 277
16.4.1 组织方面的问题 277
16.4.2 谁支付SPE费用 278
16.4.3 费用 278
16.4.4 风险 279
16.5 项目成功的关键因素 279
16.6 SPE的未来 280
16.7 小结 281
附 录
附录A UML符号 285
A.1 用例图 285
A.2 顺序图 286
A.2.1 基本顺序图 286
A.2.2 扩展的顺序图 286
A.3 部署图 288
A.4 构造型、标签值和约束 288
A.4.1 构造型 288
A.4.2 标签值 288
A.4.3 约束 289
附录B SPE建模符号 290
B.1 执行图符号 290
B.1.1 基本节点 290
B.1.2 同步节点 290
B.2 信息处理图符号 291
参考文献 292
