软件架构评估读书笔记.docxVIP

第 PAGE \* Arabic 12 页 软件架构设计读书笔记 小李飞刀 －－　写在前面，软件架构评估是一个大型项目成功的保证，不管是否完全按照书中的操作来完成，但这总是一个必须的过程。老外的技术方面的书一般都很实在，在提出一定的事实和相应的理论基础后，一般就会列出些很具体的方法，可操作性都比较强，当然，其实其理论在我们看来也没什么高深之处，可能是思维方式和长期教育环境的不同造成的，在我看来，他们的理论就是对自己的观点或者方法的一个形而上的逻辑证明，但恰恰这就是最重要的，如果在逻辑上就不具有可推导性，具体的方法再怎么说得天花乱坠也没有可信度，另外翻译得也不错，不象有些书，根本就是外行瞎折腾，翻译出来只有鬼才看得懂，不如直接去看原版。建议有空详读原文，我把这些摘录下来是希望能有所参照。　《软件架构评估》学习笔记〈Evluating Software Architectures〉 Authors: Paul Clements, Rick Kazman, Mark Klein清华大学出版社 孙学涛 朱卫东 赵凯 译 概念：架构方法： 就是一组架构决策，各个架构决策互相协调，共同实现所期望的质量属性目标。架构评估： 架构来自许多离散的决策，而这些决策是可以被分析和审查的。ATAM： 架构权衡分析方法Architectures Trade-off Analysis MethodATAM方法步骤：共4大部分，9个步骤 部分 步骤 主要活动者 活动 目的 1. 表述 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. 有风险决策，无风险决策、敏感点和权衡点的确认。 确定架构上的有风险决策、无风险决策、敏感点、权衡点等 3. 测试 7 集体讨论,确定场景优先级 根据所有风险承担者的意见形成更大的场景集合场景分类：a. 用例场景： 描述风险承担者对系统使用情况的期望。b. 生长场景： 描述期望架构能在较短时间内允许的扩充与更改。c. 探察场景： 描述系统生长的极端情况，即架构在某些更改的重压的情况。注：最初的效用树是由架构设计师和关键开发人员创建的。在对场景进行集体讨论的过程和设置优先级的过程中，有很多风险承担者参与其中，与最初的效用树相比，两者之间的不匹配可以揭露架构设计师未曾注意到的方面，从而使得我们发现架构中的重大风险。 由所有风险承担者通过表决确定这些场景的优先级 8 分析架构方法 对第6步重复，使用的是在第7步中得到的高优先级场景，这些场景被认为是迄今为止所做分析的测试案例 发现更多的架构方法，有风险决策、无风险决策、敏感点、权衡点等 4. 形成报告 9 结果的表述 评估小组 根据在ATAM评估期间得到的信息（方法、场景、针对质量属性的问题、效用树、有风险决策、无风险决策、敏感点、权衡点等），向与会