软件体系结构 (Software Architecture)

1. 软件体系结构(Software Architecture) 讲义七：软件体系结构评估

2. 客户对体系结构评估的认识(1) • “复杂软件或复杂系统的体系结构涉及诸多难度较大的决策，对这些决策进行修改往往要付出高昂的代价。成功的产品开发和演化依赖于体系结构的选择是否恰当。你能承受由于不鉴别、不评估体系结构而带来的后果吗？” ——Alexander Ran (Nokia CSA) • “如果体系结构是构建系统的基础，体系结构评估则是得到一个‘好’体系结构的基础中的一部分。如何在构建系统之前对体系结构进行评估，确定它是否可行、是否适合要开发的系统？” ——Rich Hilliard (ConsentCache CTO)

3. 客户对体系结构评估的认识(2) • “很多系统的性能或其他问题都是由于体系结构不当引起的。也就是说，这些问题早就存在，但通常很晚——快要到最后期限时，或者更为糟糕的，在问题已经被炒得沸沸扬扬时才发现。在这种情况下采取补救措施会导致一系列问题：延期交付、成本超支、不能满足上市时间要求、损坏与客户的关系或其他类似问题。如果能尽早对若干个备选体系结构进行评估，从中选择一个合适的系统，就可以很容易地避免上述问题。” ——Connie U. Smith (L&S)

4. 体系结构是软件系统的基础 • 任何软件系统的基础都是其体系结构，即用独立开发的构件建造软件的方式，以及这些构件彼此交互和联系的方式 • 性能、可修改性、可用性、安全性、可靠性、…… • 采用恰当的体系结构是项目成功的第一步。体系结构不当，必将导致灾难性的损失 →如果你所在组织的未来依赖于某系统或一系列相关系统的体系结构，怎样才能保证所采用的体系结构是恰当的？ • 创建体系结构的实践日臻成熟 • 我们可以确定出软件体系结构设计决策与按此体系结构设计出的一个或多个系统的质量和特性之间的因果关系。这就意味着可能根据所要开发的系统的质量目标和需求对体系结构进行评估，对体系结构决策进行分析

5. SA: 相关人员的交流工具 • 体系结构是系统的公共抽象，为相关人员提供了可以理解、讨论的共同语言 • 用户：可用性、可靠性 • 客户：进度、预算 • 项目经理：进度、预算、开发效率、可控性 • 开发人员：可实现性 • 测试人员：可测性 • …… • 体系结构为大型复杂系统提供了一个可供各类相关人员进行早期决策的、复杂度受控的共同语言 • 多视图 • 逻辑、进程、实现、部署、Use Case • 功能、并发、代码、实现、物理

6. SA: 展示早期设计决策 • 软件体系结构是一组一致、合理的系统早期设计决策的集合，这些决策将影响系统多种性质 • 体系结构的早期设计决策将允许或排除几乎所有的系统质量属性，例如性能、可修改性、安全性、可靠性 • 体系结构将影响组织，通常在体系结构和组织结构之间有很强的对应关系，遵循“高内聚、低耦合”原则，人员注意力的分离必须同软件注意力的分离相匹配 • 体系结构中的早期设计决策导致对实现的约束，如易于集成的商业构件的选择 →体系结构的早期设计决策应该围绕现有的基础设施，如框架、早期的骨架系统等，保持一个始终可运行的原型系统，对于鼓舞团队士气、增加顾客信心和为管理层提供评估依据都有益处

7. SA: 可复用、可传递的系统抽象 • 体系结构可以成为一个软件产品线的可复用资产 • 基于体系结构的产品线正在被许多组织证明是重大的商业成功 • 软件产品线开发面临着同单个产品开发不同的挑战 • 尽管系统的解决方法并不是很成熟，但众多的研究和工业实验表明，基于体系结构的软件产品线能在生产率、上市时间和费用等方面产生数量级的改进

8. 体系结构评估的原因 • 问题发现越早，解决问题的代价越小 • SA决定系统的属性 • 性能（Performance） • 安全（Security） • 功能性（Functionality） • 可修改性（Changeability） • SA决定项目的结构 • 配置控制库（Configuration control libraries） • 进度和预算（Schedules and budgets） • 性能目标（Performance goals） • 团队结构（Team structure） • 文档化组织（Documentation organization） • 测试和维护（Testing and maintenance） →所有的活动围绕体系结构安排 • SA评估是避免灾难的低成本手段

9. 体系结构评估方法 • SAAM：Software Architecture Analysis Method • 专用于对SA的可修改性和功能性进行评估 • ATAM：Architecture Tradeoff Analysis Method • 在SAAM基础上发展而来 • ARID：Active Reviews for Intermediate Designs • 适用于SA的可行性和适宜性进行测试，及对尚不完全的SA进行评估

10. 体系结构评估的时机 • 一般情况 • SA确定之后，具体实现之前 • 迭代或增量生命周期模型 • 最近一次开发周期中 • 通用情况 • SA生命周期的任何阶段 • 早期 • SA确定之前，可以评估已有部分，也可以在若干项中选择 • 例如：发现评审（discovery review），目的在于发现重要的系统需求，以及初步的解决方案 • 后期 • SA已经确定，并且实现已完成 • 适用于评估遗产系统，目的在于理解遗产系统的体系结构，以及能否满足要求的系统属性 →经验：进行评估的合适时机是，应该在开发小组开始制定依赖于体系结构的决策时，并且修改这些决策的代价超过体系结构评估的代价

11. 体系结构评估的参与者 • 评估小组 (Evaluation team) • 主持评估，进行分析 • 风险承担者 (Stakeholders)：在该体系结构以及根据该体系结构开发的系统中有既得利益者 • 用户：便于使用、功能丰富 • 客户：按时完成、不超出预算 • 项目决策者 • 体系结构设计者 • 构件设计者 • 项目管理者 • （不推荐）项目开发组成员：编码人员、集成人员、测试人员、维护人员等，易于构建、复用资源、易于修改等

12. 体系结构评估的结果 • 评估结果：一份报告，形式和内容随所用的方法而不同 • SA是否适合待开发系统 • 候选的两个或多个SA方案，哪个更合适？ • 适宜性（suitability）：需考虑特定的环境 • 根据SA开发的系统，满足质量目标。例如，性能要求、修改性、安全约束、行为功能 • SA可构建（buildable）：在现有资源条件下，人员、预算、遗产软件、进度等 • 适宜性只有在与构架及其对应系统的具体目标相关的上下文环境中才有意义 • 评估将告诉我们哪些地方需要改进

13. 理解质量属性 • 体系结构评估所关注的焦点是质量属性 • 任何大系统的质量属性都是由其体系结构决定的 • 体系结构决策对于能否实现质量属性具有深远的影响，因此成为体系结构评估关注的焦点 • 体系结构评估的目标 • 获取并提炼对质量属性需求的精确表述 • 获取并提炼对体系结构设计决策的精确表述 • 确定体系结构决策能否实现质量属性需求 • 质量属性刻画 • 外部刺激：导致体系结构作出反应或进行修改的操作 • 响应：具体的、可测度的或可观察到的指标 • 体系结构决策：对实现质量属性响应有直接影响的体系结构某些方面

14. 质量属性分析的不确定性 • 质量属性没有被量化，它们存在于特定目标的上下文中，例如 • 可修改性：相对于特定类型的改变 • 安全：相对于特定类型的威胁 • 可靠性：相对于特定类型的错误发生 • 性能：相对于特定的评价标准 • 产品线的适宜性：相对于产品线范围 • 可建造性：相对于特定的时间和预算约束 • 我们使用“场景(scenario)”描述上下文 • 场景是描述了系统的某个风险承担者和系统之间的一次交互的简短陈述 • 每个场景同一个特定的相关人员相联系，并针对特定的质量，如用户、维护者、开发者、客户

15. 体系结构评估的输出结果(1/2) • ATAM / SAAM / ARID的共同输出 • 划分了优先级的质量属性需求 • 从体系结构方法到质量属性的映射 • 有风险决策和无风险决策 • ATAM的特有输出 • 所使用的体系结构方法的分类 • 为相关人员提供熟悉体系结构的材料 • 针对所采用的方法和特定质量属性的分析方法 • 能够用于后续体系结构演化的评估，避免走错方向

16. 体系结构评估的输出结果(2/2) • 敏感点(Sensitivity Points)和权衡点(Tradeoff Points) • 敏感点是对于达到特定的质量属性响应至关重要的一个或多个构件（和/或构件关系）特性 →敏感点告诉设计人员或分析人员当试图理解一个质量目标是否达到时，需将注意力集中到什么地方 • 权衡点是影响多于一个属性 (attribute) 的特性 (property)，并且是多个属性的敏感点。例如，改变加密算法级别会对安全性和效率有显著影响 →权衡点是体系结构设计中最关键的决策，因此需要非常仔细地加以关注

17. 体系结构评估的收益分析 • 体系结构分析可以发现潜在的问题，从而产生更好的体系结构 • 把各相关人员召集到一起 • 增进彼此的了解，对各自冲突的目标进行妥协 • 迫使对具体质量目标做出清楚的表述 • 场景提供了显式的质量基准 • 为相互冲突的目标划分优先级 • 迫使对SA做出清楚的解释 • 提高体系结构文档的质量 • 发现项目之间交叉复用的可能性 • 来自项目之外的相关人员或评估小组，工作或熟悉更高组织的其他项目，这就为项目之间的交叉复用提供了可能 • 提高SA实践水平 • 增加时间和人员开销

18. ATAM评估方法 • ATAM：Architecture Tradeoff Analysis Method（体系结构权衡分析方法） • 特点 • 评估SA对特定质量目标的满足情况，揭示诸多质量目标之间的相互作用和权衡 • 结构化的评估方法，可重复 • 同样适合遗产系统的分析 • 方法来源 • 体系结构风格 • 质量属性分析方法 • SAAM (Software Architecture Analysis Method)

19. ATAM步骤简述(1/2) ATAM主要部分包括4组，共9个步骤： • 陈述，包括通过它进行的信息交流 • ATAM方法的陈述：评估负责人 • 商业动机的陈述：项目经理或系统客户 • SA的陈述：系统设计人员 • 调查与分析，包括对照体系结构方法评估关键质量属性需求 • 确定体系结构方法：系统设计人员 • 生成质量属性效用树（utility tree）：说明构成系统“效用” 的质量属性（性能、有效性、安全性、可修改性、可用性） ，具体到场景层次，标注刺激/反应，并区分不同的优先级 • 分析体系结构方法：基于步骤5识别出的高优先级的场景，说明和分析针对这些场景的体系结构方法。在这一步骤中，体系结构风险、非风险、敏感点和权衡点被识别出来

20. ATAM步骤简述(2/2) • 测试，包括对照所有相关人员的需求检验最新结果 • 集体讨论并确定场景优先级 • 分析体系结构方法：针对步骤7的高等级场景 • 形成报告，包括陈述ATAM的结果 • 结果的表述：包括方法、场景、特定属性的问题、效用树、有风险决策、无风险决策、敏感点和权衡点 提示：上述步骤顺序并不严格，可根据需要适当调整

21. ATAM步骤详述(1/13) • 第1步：ATAM方法的陈述 评估负责人向参加会议的相关人员介绍ATAM方法。在这一步，要对每个人解释参与的过程，并留出解答疑问的时间，明确其他工作的环境和预期 • ATAM评估步骤简介 • 用于获取信息和分析的技巧：效用树的生成、基于体系结构方法的获取和分析、对场景的集体讨论及优先级的划分 • 评估的结果：场景及其优先级、用以理解和评估体系结构的问题、描述体系结构的动机需求并给出其优先级的效用树、所确定的一组体系结构方法、所发现的有风险决策、无风险决策、敏感点和权衡点等

22. ATAM步骤详述(2/13) • 第2步：商业动机的陈述 项目决策者从商业角度，向相关人员介绍系统概况和主要的商业动机 • 系统最重要的功能 • 技术、管理、经济、政治方面的任何相关限制 • 与该项目相关的商业目标和上下文 • 主要的相关人员 • 体系结构的驱动因素，即促使形成该体系结构的主要质量属性目标

23. ATAM步骤详述(3/13) • 第3步：体系结构陈述 在适合的细节层次上描述体系结构，体系结构信息直接影响可能的分析及分析的质量。在进行更实质的分析之前，评估小组通常需要询问更多的有关体系结构的信息 • 技术约束条件，诸如要求使用的操作系统、硬件、中间件等 • 该系统必须要与之交互的其他系统 • 用以满足质量属性需求的体系结构方法、样式、模式和采用的机制 • 高层体系结构视图：功能、代码、并发、物理

24. ATAM步骤详述(4/13) • 第4步：确定体系结构方法 体系结构方法定义了系统的重要结构，描述了系统演化、对更改的响应、对攻击的防范以及与其他系统的集成等 • 强调体系结构方法和体系结构风格的确定，代表了所评估的体系结构用以事先具有高优先级的质量属性的手段，保证关键需求按计划得以实现的手段 • 体系结构风格，包括构件类型及其拓扑结构的描述，对构件间数据和控制交互模式的描述和使用该样风格的优缺点的非正式表述 • 体系结构的约束条件，对构件及其交互的约束，这些约束条件限定了满足质量属性需求的设计决策 • 基于属性的体系结构风格(attribute-based architectural styles, ABASs)，一种带有解释该风格如何实现某些质量属性的体系结构风格

25. ATAM步骤详述(5/13) • 第5步：生成质量属性效用树 评估小组与项目决策者合作，共同确定出该系统的最重要的质量属性目标，并设置优先级，进行进一步的细化，该步指导其他的分析 这种方式将所有风险承担者和评估小组的精力集中到对系统的成功与否具有重要意义的体系结构的方面上 效用树为我们提供了一种直接而有效地将系统的商业驱动因素转换为具体的质量属性场景的机制，该步骤的输出结果是对具体质量属性需求（以场景形式实现）的优先级的确定 • 效用树中质量属性细化为场景 • 确定最重要的质量属性目标，并设置优先级 • 效用树设置优先级标准 • 每个场景对系统成功与否的重要性 • 体系结构设计人员所估计的实现这种场景的难度

26. ATAM步骤详述(6/13) • 举例：效用树样例

27. *场景 (Scenarios) • 场景是描述系统相关人员同系统一次交互的简短陈述 • 使用场景的三重理由：简单创造和理解；便宜（不必花费太多时间就能产生）；高效 • 场景提供了把含糊的质量转变为某些具体事情的手段 • 使用者：使用系统完成某些任务，类似于OO说法中的use case • 维护者：针对系统的变化，例如以某种方式升级操作系统或者增加一个新功能 • 开发者：使用体系结构构造系统或预测它的性能 • 产品线经理：如何复用体系结构，用于产品线的第二个工程中，可快速构造产品线的产品

28. *场景的结构 • 刺激：相关人员启动同系统进行交互的行为 • 用户可以激活一个函数；维护人员可以对系统进行改变；测试人员可以运行一个测试用例；操作人员可以某种方式重新配置系统；等等 • 环境：刺激发生时系统所处状态等 • 系统状态如何？哪些非正常的条件在起作用？系统处于重负载吗？某个处理器是否宕机？某个通信信道是否流量过大？ • 任何同理解场景相关的周边条件都应该被描述 • 响应：系统通过体系结构将怎样对刺激进行反应 • 函数执行了吗？测试是否成功？系统重配置是否发生？维护需要多大的工作量？

29. *场景的类型 • Use Case场景：现有系统的典型应用，用于信息启发 • 用户希望不重新输入项目数据的情况下，检查在不同财年的预算和实际发生数据（可用性） • 用户把一个图的布局从水平改为垂直，该图在1秒钟内被重新绘制（效率） • 成长场景 (Growth Scenarios)：系统的预期变化 • 在不影响系统延迟的情况下，改变显示以同时跟踪多个目标 • 以少于1个人年的工作量，移植到同一家族的其他操作系统，或现有操作系统的新版本 • 以少于1个人周的工作量，向系统增加新的消息类型 • 探测场景 (Exploratory Scenarios)：预期“压迫”系统的极端变化——暴露设计的边界情况 • 把底层Unix平台改变为Macintosh • 把25年历史的软件复用在新一代飞机上

30. ATAM步骤详述(7/13) • 第6步：分析体系结构方法 针对划分了优先级的质量需求（第5步）和采用的体系结构方法（第4步），评估它们的匹配情况 • 与效用树中每个高优先级的场景相关的体系结构方法或决策，评估小组应该能够期望在前面第4步中已经得出了所有体系结构方法 • 与每个体系结构方法相联系的待分析问题，这些问题是与对应于场景的质量属性相匹配的。问题可以来自于对这些方法的文档编写实践、关于体系结构的书籍、参加评估的风险承担者的经验等 • 体系结构设计师对问题的解答 • 风险、无风险、敏感点、权衡点的确认

31. ATAM步骤详述(8/13) • 体系结构方法分析模板

32. ATAM步骤详述(9/13) • 举例：体系结构方法分析示例

33. ATAM步骤详述(10/13) • 第7步：集体讨论并确定场景优先级 在第7步和第8步，评估组测试所理解的体系结构，场景被用作测试的主要手段 第5步确定的场景主要是从体系结构设计人员的角度看待系统的质量属性需求，这一步是从相关人员的角度讨论场景 • 需讨论的场景：用例场景、生长场景、探测场景，这些场景可能同效用树的场景保持一致，也可能发现更多的驱动场景，这也是一个重要收获 • 相关人员对场景投票确定优先级 • 比较场景讨论结果和质量效用树 • 新场景与效用树中的某个叶节点场景相匹配 • 新场景成为效用树中某个已有分支的新叶节点 • 新场景表达的是以前未曾考虑到的质量属性，因而与效用树中的任何分支都不匹配 • 将场景讨论结果放到质量效用树当中，即系统体系结构设计和系统需求一致

34. ATAM步骤详述(11/13) • 效用树生成和场景集体讨论的差异

35. *风险承担者 (Stakeholders) • 体系结构评估的原则 • 对高质量的评估，体系结构相关人员的积极参与是绝对必要的 • 软件体系结构评估的质量在相当大的程度上依赖于你能够为之组织的相关人员的质量 • 设计师或设计团队必须在评估现场

36. ATAM步骤详述(12/13) • 第8步：分析体系结构方法 在已确定了若干场景并进行了分析之后，评估小组就可以引导体系结构设计师在所描述的体系结构的基础上实现第7步中得出的最高优先级的场景，对相关的体系结构决策如何有助于该场景的实现做出解释 • 与第6步类似 • 对新增的场景，分析其体系结构方法；对不变的场景，进行检查

37. ATAM步骤详述(13/13) • 第9步：陈述结果 最后，需要把在ATAM分析中所得到的各种信息进行归纳总结，并呈现给相关人员 在这一陈述中，评估负责人概要介绍ATAM评估的各个步骤和得到的各种信息，包括商业环境、促成该体系结构的主要需求、约束条件和体系结构等，但最重要的结果如下： • 文档化的体系结构方法 • 若干场景及其优先级 • 基于质量属性的若干问题 • 效用树 • 风险、无风险、敏感点、权衡点 • 形成风险主题，根据某些常见的基本问题或系统缺陷将风险分组

38. ATAM评估方法的阶段 • 以时间为维度，评估分为4个阶段， • 第0阶段：建立阶段 • 合作关系的建立——评估客户和评估人员之间 • 准备工作——组建评估小组，召开开工会议，进行准备 • 第1阶段：第1~6步 • 以体系结构为中心 • 重点是获取体系结构信息并对其进行分析 • 第2阶段：第7~9步 • 以相关人员为中心 • 重点是获知相关人员的观点，并验证第1阶段的结果 • 第3阶段：后续阶段 • 形成最终报告、对后续活动（如果有的话）做出规划 • 评估小组在此阶段实现文档和经验的更新

39. 第0阶段的工作 • 合作关系的建立 • 评估人员和评估客户的交流 • 评估客户应该是对所评估体系结构对应的项目有一定影响力的人，而且可以联系到很多位体系结构相关人员 • 客户应对所要采用的评估方法有基本了解，并且知道在评估过程中都要做哪些工作 • 客户应对所要评估的体系结构及其系统做出描述 • 假设评估负责人已经决定可以进行评估，则应商谈并签署关于评估工作的合同或协议 • 要解决好信息专有性问题。例如，评估小组可能需要签署不得泄漏该评估信息的协议 • 准备工作 • 组建评估小组 • 角色：评估小组负责人，评估负责人，场景书记员，进展书记员，计时员，过程观察员，过程监督者，提问者 • 召开评估小组开工会议 • 就评估的经验和体会进行广泛的交流，同时指定每个成员要扮演的角色 • 为第1阶段进行必要的准备

40. 第1阶段的工作 • 完成第1~6步的工作 • 通过收集足够多的信息，以决定： • 之后的评估工作是否可行、能否顺利展开 • 如果不行，就可在为第2阶段的工作召集更多的相关人员之前，在第1阶段及时终止 • 是否需要更多的体系结构文档 • 如果需要，则应明确需要的是哪些类型的文档，以及应以什么形式提交这些文档 • 哪些相关人员应参与第2阶段的工作 • 在第一阶段的最后，评估出资人要保证让合适的相关人员参与第2阶段的工作

41. 第2阶段的工作 • 在简要重复第1~6步工作的基础上，进行第7~9步的工作

42. 第3阶段的工作 • 生成最终报告 • 在ATAM评估快要结束时，必须撰写并提交最终的评估报告：做了哪些工作、有何发现、得出了什么结论等 • 收集数据 • 针对参与者/评估小组成员的改进意见调查，询问对评估实践的看法 • 针对评估客户/评估小组成员的成本调查 • 针对评估客户的长期收益调查 • 更新工作产品仓库 • 对在刚完成的评估中所用到的或所生成的工作产品进行维护，这将有助于更好地进行未来的评估工作，包括：成本/收益信息、场景、待分析的问题、参与者的意见、评估的最终报告

43. ATAM评估方法总结(1/3) • 场景的优势 • 对场景的集体讨论和优先级的确定一般都有助于相关人员的交流，并能促进相互协作 • 所生成的场景集经常是相关人员迄今为止所看到的对系统需求的最佳表示 • 把“分析”加入到分析方法中 • 确定质量属性效用树 • 确定采用的体系结构方法 • 分析体系结构方法对质量属性的满足程度

44. ATAM评估方法总结(2/3) • ATAM方法的两个方面

45. ATAM评估方法总结(3/3) • ATAM概念流图

46. ATAM案例研究(1/6) • 战场控制系统（Battlefield Control System, 简称BCS） • 该系统供部队的营级单位使用，用于在战场实时环境下控制部队的行军、战略和作战 • 准备工作 • 第1步：ATAM方法表述 • 第2步：商业动机表述 • 对系统所要辅助完成的在战场上执行的各种任务的介绍，并指出这些任务的具体需求 • 支持一个指挥官节点，控制和指挥一组士兵及其装备 • 与能够为它提供指挥与情报信息的其它系统交互 • 定期收集当前执行任务的状态信息 • 软件/硬件限制：要求极高的物理健壮性、能够适应来自与之交互的其它系统的消息格式的频繁变更，其它性能指标

47. ATAM案例研究(2/6) • 第3步：体系结构的表述

48. ATAM案例研究(3/6) • 第4步：确定体系结构方法 • 客户机 / 服务器 • 采用备用指挥官节点——可用性 • 采用一组针对领域的设计模式——可修改性 • 采用独立通信构件——性能

49. ATAM案例研究(4/6) • 第5步：生成质量属性效用树

50. ATAM案例研究(5/6) • 第6步：分析体系结构方法 • 针对备用指挥官节点方法——可用性 • 客户机 / 服务器方法可能存在单点故障 • 关键刺激是由于受到攻击或因软硬件故障而导致的系统中某个节点（特别是指挥官节点）的崩溃 • 可用性受指挥官节点崩溃速度和指挥官节点修复速度的影响 • 有风险决策：不能生成新的备用节点 • 可以提供多个备用节点，n个接收节点/ m个被动接收节点 • QA = g ( n , m ) • 针对独立通信构件方法——性能 • 客户机 / 服务器方法可能服务器是一个潜在瓶颈 • 无线调制解调器较低的速度（9600波特）是BCS系统的单个最重要的性能驱动因素 • 使用性能模型的目的是，获取影响消息的大小和分布情况的体系结构决策 • QP = h ( n , m , CO ) CO指其他通信开销