软件体系结构read.ppt

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 蓝色表示需解释 * 蓝色表示需解释 * * * * * * * * * * * * * * * * * * * ATAM步骤详述(9/13) 举例：体系结构方法分析示例 ATAM步骤详述(10/13) 第7步：集体讨论并确定场景优先级 在第7步和第8步，评估组测试所理解的体系结构，场景被用作测试的主要手段 第5步确定的场景主要是从体系结构设计人员的角度看待系统的质量属性需求，这一步是从相关人员的角度讨论场景 需讨论的场景：用例场景、生长场景、探测场景，这些场景可能同效用树的场景保持一致，也可能发现更多的驱动场景，这也是一个重要收获 相关人员对场景投票确定优先级 比较场景讨论结果和质量效用树 新场景与效用树中的某个叶节点场景相匹配 新场景成为效用树中某个已有分支的新叶节点 新场景表达的是以前未曾考虑到的质量属性，因而与效用树中的任何分支都不匹配 将场景讨论结果放到质量效用树当中，即系统体系结构设计和系统需求一致 ATAM步骤详述(11/13) 效用树生成和场景集体讨论的差异 *风险承担者 (Stakeholders) 生产者(Producers) 软件体系结构设计师，开发者，维护者，集成者，测试者，标准专家，效率工程师，安全专家，项目经理，产品线经理 客户(Consumers) 客户，终端用户，应用系统构造者（基于产品线体系结构），任务专家/计划者（mission specialist/planner） 服务者(Servicers) 系统管理员，网络管理员，服务代理 同系统有接口的其他人员 领域（或团体）代表，系统设计师，设备专家 体系结构评估的原则 对高质量的评估，体系结构相关人员的积极参与是绝对必要的 软件体系结构评估的质量在相当大的程度上依赖于你能够为之组织的相关人员的质量 设计师或设计团队必须在评估现场 ATAM步骤详述(12/13) 第8步：分析体系结构方法 在已确定了若干场景并进行了分析之后，评估小组就可以引导体系结构设计师在所描述的体系结构的基础上实现第7步中得出的最高优先级的场景，对相关的体系结构决策如何有助于该场景的实现做出解释 与第6步类似 对新增的场景，分析其体系结构方法；对不变的场景，进行检查 ATAM步骤详述(13/13) 第9步：陈述结果 最后，需要把在ATAM分析中所得到的各种信息进行归纳总结，并呈现给相关人员 在这一陈述中，评估负责人概要介绍ATAM评估的各个步骤和得到的各种信息，包括商业环境、促成该体系结构的主要需求、约束条件和体系结构等，但最重要的结果如下： 文档化的体系结构方法 若干场景及其优先级 基于质量属性的若干问题 效用树 风险、无风险、敏感点、权衡点 形成风险主题，根据某些常见的基本问题或系统缺陷将风险分组 ATAM评估方法的阶段 以时间为维度，评估分为4个阶段， 第0阶段：建立阶段 合作关系的建立——评估客户和评估人员之间 准备工作——组建评估小组，召开开工会议，进行准备 第1阶段：第1~6步 以体系结构为中心 重点是获取体系结构信息并对其进行分析 第2阶段：第7~9步 以相关人员为中心 重点是获知相关人员的观点，并验证第1阶段的结果 第3阶段：后续阶段 形成最终报告、对后续活动（如果有的话）做出规划 评估小组在此阶段实现文档和经验的更新 第0阶段的工作 合作关系的建立 评估人员和评估客户的交流 评估客户应该是对所评估体系结构对应的项目有一定影响力的人，而且可以联系到很多位体系结构相关人员 客户应对所要采用的评估方法有基本了解，并且知道在评估过程中都要做哪些工作 客户应对所要评估的体系结构及其系统做出描述 假设评估负责人已经决定可以进行评估，则应商谈并签署关于评估工作的合同或协议 要解决好信息专有性问题。例如，评估小组可能需要签署不得泄漏该评估信息的协议 准备工作 组建评估小组 角色：评估小组负责人，评估负责人，场景书记员，进展书记员，计时员，过程观察员，过程监督者，提问者 召开评估小组开工会议 就评估的经验和体会进行广泛的交流，同时指定每个成员要扮演的角色 为第1阶段进行必要的准备 第1阶段的工作 完成第1~6步的工作 通过收集足够多的信息，以决定： 之后的评估工作是否可行、能否顺利展开 如果不行，就可在为第2阶段的工作召集更多的相关人员之前，在第1阶段及时终止 是否需要更多的体系结构文档 如果需要，则应明确需要的是哪些类型的文档，以及应以什么形式提交这些文档 哪些相关人员应参与第2阶段的工作 在第一阶段的最后，评估出资人要保证让合适的相关人员参与第2阶段的工作 第2阶段的工作 在简要重复第1~6