软件架构设计读书笔记小李飞刀－－ 写在前面，软件架构评估是一个大型项目成功的保证，不管是否完全按照书中的操作来完成，但这总是 一个必须的过程老外的技术方面的书一般都很实在，在提出一定的事实和相应的理论基础后，一般就会列出 些很具体的方法，可操作性都比较强，当然，其实其理论在我们看来也没什么高深之处，可能是思维方式和长 期教育环境的不同造成的，在我看来，他们的理论就是对自己的观点或者方法的一个形而上的逻辑证明，但恰 恰这就是最重要的，如果在逻辑上就不具有可推导性，具体的方法再怎么说得天花乱坠也没有可信度，另外翻 译得也不错，不象有些书，根本就是外行瞎折腾，翻译出来只有鬼才看得懂，不如直接去看原版建议有空详读原文，我把这些摘录下来是希望能有所参照《软件架构评估》学习笔记〈Evluating Software Architectures 〉 Authors: Paul Clements, Rick Kazman, Mark Klein清华大学出版社 孙学涛 朱卫东 赵凯 译概念：架构方法： 就是一组架构决策，各个架构决策互相协调，共同实现所期望的质量属性目标架构评估： 架构来自许多离散的决策，而这些决策是可以被分析和审查的。
ATAM： 架构权衡分析方法Architectures Trade-off Analysis MethodATAM 方法步骤：共4大部分，9 个步骤部分步骤主要活动 者活动目的表述1＞ ATAM方法的表 述；评估负责人向评估参与者介绍ATAM方法并回答问题a. 评估步骤介绍b. 用于获取信息或分析的技巧：效用树的生成、基于架构方法的获 取和分析、对场景的集体讨论及优先级的划分c. 评估的结果：所得出的场景及其优先级，用以理解和评估架构的 问题、描述架构的动机需求并给出带优先级的效用树、所确定的一级 架构方法、所发现的有风险决策、无风险决策、敏感点和权衡点等使参与者对该方法形成 正确的预期2＞商业动 机的表述；项目发言 人（项目经 理或系统 客户）阐述系统的商业目标a. 系统最重要的功能b. 技术、管理、政治、经济方面的任何相关限制c. 与项目相关的商业目标和上下文d. 主要的风险承担者e. 架构的驱动因素（即促使形成该架构的主要质量属性目标）说明采用该架构的主要 因素（如：咼可用性，极咼 的安全性或推向市场的 时机）3＞架构的 表述；架构设计师对架构做出描述a. 技术约束条件，诸如要使用的操作系统，硬件，中间件之类的约 束b. 该系统必须要与之交互的其他系统c. 用以满足质量属性的架构方法d. 对最重要的用例场景及生长场景的介绍重点强调该架构是怎样 适应商业动机的2・调杳 和分 析4＞确定架 构方法架构设计师确定所用的架构方法，但不进行分析5＞生成质量属性效 用树生成质量属性效用树，详细的根结点为效用，一直细分到位于叶子节点的质量属性场景，质量属性 场景的（优先级，实现难度）用高（H）、中（M）、低（L）描述； 不必精确得出构成系统效用的质 量属性（性能、可用性、 安全性、可修改性、使 用性等）；具体到场景--刺激--响 应模式，并划分优先级6＞分析架 构方法根据上一步得到的高优先级场景，得出应对这一场 景的架构方法并对其进行分析要得到的结果包括：a. 与效用树中每个高优先级的场景相关的架构方法或决策；b. 与每个架构方法相联系的待分析问题；C.架构分析师对问题的解答；d.有风险决策，无风险决策、敏感点和权衡点的确认。
确定架构上的有风险决 策、无风险决策、敏感 点、权衡点等37＞集体讨根据所有风险承担者的意见形成更大的场景集合由所有风险承担者通过测试论,确定场 景优先级场景分类：a. 用例场景：描述风险承担者对系统使用情况的期望b. 生长场景：描述期望架构能在较短时间内允许的扩充与更改C.探察场景：描述系统生长的极端情况，即架构在某些更改的重压 的情况注：最初的效用树是由架构设计师和关键开发人员创建的在对场景 进行集体讨论的过程和设置优先级的过程中，有很多风险承担者参与 其中，与最初的效用树相比，两者之间的不匹配可以揭露架构设计师 未曾注意到的方面，从而使得我们发现架构中的重大风险表决确定这些场景的优 先级8＞分析架 构方法对第6步重复，使用的是在第7步中得到的高优先 级场景，这些场景被认为是迄今为止所做分析的测 试案例发现更多的架构方法， 有风险决策、无风险决 策、敏感点、权衡点等4_形成报告9＞结果的 表述评估小组根据在ATAM评估期间得到的信息（方法、场景、 针对质量属性的问题、效用树、有风险决朿、无风 险决策、敏感点、权衡点等），向与会的风险承担 者报告评估结果最重要的是如下ATAM结果：a. 已经编写了文档的架构方法；b. 若干场景及其优先级；c. 基于质量属性的若干问题；d. 效用树；e. 所发现的有风险决策；f. 已编写文档的无风险决策；e.所发现的敏感点和权衡点。
以上步骤并不是固定的，有时必须对评估规划做某些动态的更改，以容许人员或架构信息的改变ATAM 评估方法的的阶段：第0阶段建立评估小组，建立评估组织和待评估组织间的合作关系第1阶段以架构为中心，重点获取架构信息并对其进行分析评估阶段，上面的9个步骤在这时完成第2阶段以风险承担者中心，重点为获取风险承担者的观点，并对第1阶段的结果进 行验证第3阶段后续阶段，形成最终报告，对后续活动做出规划，评估组织在此阶段实现文 档和经验的更新评估小组各成员的角色及其职责角色职责理想的人员素质评估小 组负责 人准备评估；与评估客户协调；保证满足客户的需要； 签署评估合同；组建评估小组；负责检查最终报告的生成和提交；善于协调、安排，有管理技巧善于与客户 交流；能按时完成任务评估负责人负责评估工作；促进场景的得出；管理场景的选择及 设置优先级的过程；促进对照架构的场景评估；为现 场评估提供帮助能在众人面前表现自如善于指点迷津对 架构问题有深刻的理解，富有架构评估的实 践经验能够从冗长的讨论中得出有价值的 发现，或能够判断出何时讨论已无意义、应 进行调整场景书记员在得到场景的过程中负责将场景写到活动挂图或白板 上，务必用以达成一致的措辞来描述，未得到准确措 辞就继续讨论写一手好字，能够在未搞清楚某个问题之前 坚持要求继续讨论，能够快速理解所讨论的 问题并提取出其要点进展书记员以电子形式记录评估的进展情况。
捕获原始场景捕 获促成场景的每个问题捕获与场景对应的架构解决 方案打印出要分发给各参与人员所采用场景的列表打字速度快，质量高工作条理性好从而 能够快速查找信息对架构问题理解透彻 能够融会贯通地快速搞清技术问题勇于打 断正在进行的讨论以验证对某个问题的理 解，从而保证所获取信息的正确性计时员帮助评估负责人保证评估工作按进度进行在评估阶 段帮助控制用在每个场景上的时间敢于不顾情面地中断讨论，宣布时间已到过程观察员记录评估工作的哪些地方有待改进或偏离了原计划 通常不发表意见，也可能偶尔在评估过程中向评估负 责人提出基于过程的建议在评估完成后，负责汇报 评估过程，指出应该吸取哪些教训，以便在未来的评 估中加以改进还负责向整个评估小组汇报某次评估 的实践情况善于观察和发现问题，熟悉评估过程，曾参加过采用该架构评估方法进行评估过程监督者帮助评估负责人记住并执行评估方法的每个步骤对评估方法的各个步骤非常熟悉愿意并能 够以不连续的方式向评估负责人提供指导提问者提出风险承担者或许未曾想到的关于架构的问题对架构和风险承担者的需求具有敏锐的观 察力了解同类系统勇于提出可能有争议 的问题，并能不懈地寻求其答案。
熟悉相关 的质量属性商业目标分析结果表：内容列表详细备注主要商业目标为跨学科的地球科学研究提供支持大批量数据的并发摄入、处理和分配次要商业目标为外部开发的科学算法/应用程序提供支持科学数据再处理其他商业目标采用自动化操作，以尽可能减少操作成本系统质量属性列表：质量属性目标标识号（数字表示效用树 中的子序号）针对质量属性的要求可维护性M1更改某个子系统时不要求改动其他子系统M2把子系统的部署要求分别降到最低M3把回归测试时间从5天减少到1天可靠性R1不至于因为数据输入输出而导致某个系统资源崩溃或等待较长时间，如 超过10分钟R2请求（输入出）中的某一部分数据错误不会妨碍其他部分的正常使用R6因系统崩溃或备份造成的无法提供服务的时间不能超过1小时可操作性O10系统应该能在20分钟内根据用户类型、数据类型、介质类型、目的地 或用户对1000项定单重新设置优先级014应该能在不需要操作干涉的情况下，通过V0网关为1000个并发请求 提供服务可扩展性S2能同时支持50个场站S3能够支持来自100个数据源的输入性能P1在某种查询算法下，对Landsat L-7查询可使响应速度能提咼5倍第一阶段获得的带优先级的效用树：第1 层： 效用第2层：质量属性第3层：质量属性求精第4层：质量属性场景重要性难度累 加 和可维护性M1：对一个子系统的更改不要 求改动其他子系统M1.1：部署下一个科学数据服务器版本，实现对当 前版本的更新。
升级应该在8小时以内完成，并且 不应影响其他子系统及查找、浏览或预定功能的使 用303060M2：独立地回退子系统的部署M2.1：使科学数据服务器从M1回退202040可操作性010:系统应该能在20分钟内 根据用户类型、数据类型、介 质类型、目的地或用户对1000 项定单重新设置优先级010.1:积压任务管理--在系统连续24小时不能正 常工作后，应在30分钟内为所积压的任务设置优先 级，以保证各任务能够按优先级得以处理且正常的 操作能够得以维持，不会在恢复正常操作状态后降 低吞吐量302050014 :应该能在不需要操作干 涉的情况下，通过V0网关为 1000个并发请求提供服务014.1: M0DAPS连续24小时不能正常工作，恢复并请求2天的数据；按优先级进行处理202040014.2:接收100个并发查询请求，不拒绝高优先 级的请求，在性能允许的情况下完成处理，不使系 统过载202040可靠性/可用 性Ra1：失败的或挂起时间超过10分钟的数据输入输出不占 用系统资源Ra1.1： L-7按预定用FTP方式把数据推到某个FTP 服务器已经崩溃的节点，在第一个请求未能成功处 理的10分钟内系统被挂起，在请求被挂起期间内所 有资源可用，不影响其他节点的分配。
301040可扩展Sc2:系统能够支持50个节点Sc2.1 :跨节点订单可记录50个节点，跨5节点订203050性单历时2分钟SC2.2:跨节点用户注册在24个小时内经历50个节 点。