8.6.1 针对架构设计基本要素的架构评审
3、效果展示与评审方法： 在实现方法的效果评审中，应考虑采用按五个方面，进行分解的方法。 如：根据需求的OMT方法，把用例图转化为静态的类图、动态的行为（状 态图、时序图、协作图、活动图），以及反映系统架构的组件图和部署图 时，应分别报告：系统设计和实现，是如何分别满足五个方面的特定需求 和限制的。 4、评审的关注点： 评审老师应特别关注：作为系统架构设计的第一步和关键一步，系统一 步步被分解为子系统、包、接口、实现类、对象和方法等，其分解的依据 是什么？各逻辑单元的抽取与定义是如何体现对系统架构元素（模块、组 件、包、子系统）进行划分和分离的？分离点在哪里？理由是什么？这些 分离后的架构元素本身，是否满足： 抽象是否与系统目标相一致； 是否与作为类的责任相一致； 是否满足高内聚、松耦合的原则要求； 是否可以委托给其他类； 等等。
8.6 架构设计与评审
分析软件构架的原因
因为软件构架非常重要，它是风险承担者 之间的交流平台，是早期设计决策的体现， 可传递、可重用的模型；而且软件质量不 可能在软件开发的最后阶段追加上去，必 须在设计之初就考虑到。
8.6 架构设计与评审
架构验证的两个目的是：验证架构设计的可行性和验证架构 设计纪律的遵守程度。 上二节的架构验证，解决的是第二个目标。本节讨论的话题 ，则是前者。 那么，所谓架构设计的可行性验证，应该回答：在特定架构 需求、设计策略和设计方案确定后，如果按此方案实现的话 ，是否可以满足架构需求。 与先两节所讨论的架构验证不同，可行性验证往往是在系统 还没有实现之前进行的。因为架构设计具有全局性、整体性 和前瞻性，当系统已经完全开发完成，再发现架构设计的错 误，将会付出加大的代价，是不能接受的。
8.6.1 针对架构设计基本要素的架构评审
1、架构设计的基本要素与架构评审： 这里所谓的架构设计的“基本要素”，主要是指架构设计的“物理、逻 辑、开发、运行、数据”五个方面考虑因素。即指架构设计在这五个方面 限制条件下，是否满足其特定的需求。显然，这五个要素，是架构设计的 最基本考虑因素。 2、针对基本要素的架构评审： 针对五个基本素的架构设计评审，架构师应包括分别报告并接受审查以 下一些内容： 目标系统在这五个方面的具体需求和限制是什么？ 针对需求和限制的设计决策是什么？ 实现设计决策的方法是什么？ 通过一定的形式，例如：原型法、模拟运行环境、形式化方法等， 对采用上述设计方法可能达到的实现效果，进行展示和预期，并接受 老师的评审。
软件架构实践
SOFTWARE ARCHITECTURE
IN PRACTICE
软件系统设计与体系结构
软件架构实践
第 8章 基于关键需求的架构设计、 验证测试与评审
第8章基于关键需求的架构设计、验证测试 与评审
8.1 理解架构设计中的关键需求 8.2 基于关键需求的架构设计对策 8.3 影响架构设计的关键机制 8.4 架构设计的验证 8.5 架构的集成测试 8.6 架构设计与评审 8.7 电梯控制系统的架构设计实现与评审 8.8 本章小结与习题
6. 要保证评审小组中有构架方面的专家、领域专家、资料员 及后勤员。
7. 一定要有系统设计师。
8. 收集各种场景数据，并在此基础上形成评审清单。
8.6.2 针对关键质量属性需求的架构设计评审
ATAM（Architecture Tradeoff Analysis Method）是SEI提 出的一种软件构架评估方法。
评审方法与技巧
构架评审技巧可以分为两大类，应用不同的技巧需要付出 不同的代价，也能够得到不同的信息。 定性分析方法—提问的技巧 1. 场景—描述风险承担者和系统之间的具体交互
2.评审清单—对同一领域的若干系统进行评估后提出的 一组详细的问题
3.问卷—适用于所有构架的若干问题的清单
定量分析的方法——量化的技巧
1. 指标—对构架可观察到的参数的量化度量与解释 2. 模拟、原型与实验
评审方法与技巧
评审技巧的选用
定性分析：
场景->评审清单->问卷调查过程
评审环境与条件的准备
1. 评审环境—预先规划
2. 项目代表—风险承担者，组件负责人 3. 评审小组 • 评审小组的人员公证、客观、受尊重 • 成员必须专门从事评审工作
评审的一般过程
评审实施
• 强调那些与构架相符或相悖的重要问题。
• 必须记载评审中所提的每个问题。 • 按问题的重要性进行分类。
评审结果
对评审中的各个问题都要做出正式的阐述，同时也 要对赖以确定这些问题的数据做出相应的说明。
评审的一般过程
构架评审的主要指导原则如下： 1. 把由独立部门实施的正规的构架评审作为项目开发周期规 划的一部分。 2. 选择评审的最佳时间，尽早预审一次。 3. 选择恰当的评审技巧。 4. 签署评审合同。 5. 限制所要评审的质量属性的个数。
• 有对构架相关问题熟悉的人，其领导具有设计、评价经验
• 至少有一位该系统所属领域的专家 • 有专人负责文档、后勤，办公地点离评审对象近
4. 组织的期望—用合同明确 • 构架评审结束时应向谁报告什么内容 • 评审的标准是什么
• 向评审小组提供那些资源及人力
• 对评审小组和项目组以后的工作有什么期望 • 预计评审持续的最长时间 设定期望的目的是让所有人都理解评审结果的本质是判断可 行性，而不是提供任何保证。 5. 评审的准备—制定评审日程 • 系统需求文档 • 构架描述及介绍构架决策思想的材料 • 将系统的质量属性和功能要求按重要程度排序出前面3-5个
ATAM评估方法的主要目的就是：
1、提炼出软件质量属性需求的精确描述； 2、提炼出构架设计决策的精确描述； 3、评估这些构架设计决策，并判定其是否令人满意 的实现了这些质量需求。
ATAM： 一种进行构架评估的综合方法
ATAM评估方法并非把每个可以量化的质量属性 都进行详尽的分析，而是使众多的风险承担者（包 括经理、开发人员、测试人员、用户、客户等等） 都参与进来，由此而达到上述目标的。 ATAM是一种挖掘潜在风险，降低或者缓和现有 风险的软件构架评估方法。 因此，以下三点是评估中要特别注重的： 1、风险； 2、敏感点； 3、权衡点。