架构评审与决策

当架构设计基本完成而且已经编制了文档以后，需要做的一件最重要的工作就是架构决
策，我们必须知道我们构建的架构对系统重要的质量属性产生的影响，以及对架构方案的取
舍做出定。评估大型系统的架构是一项复杂任务，它的困难在于：
1，大型系统由于结构庞大，要在有限的时间里理解这个构架非常困难。
2，计算机系统的目的是支持商业目标，评估的时候需要把这些目标和技术支持联系起
来。
3，大型系统通常都有多个涉众，需要在有限的时间里把这些涉众的观点仔细管理并加
以评估，有的时候是非常困难的。
在进行架构评估的时候，有一些方法论可以帮助我们解决这些问题，比如我们可以使用
ATAM（构架权衡分析方法）是一种评估构架的综合全面的方法，这种方法不仅可以揭示出
架构满足特定质量目标的情况，而且可以使我们更清楚地认识到质量目标之间的关系。
ATAM 用以获取系统以及构架的业务目标，并且使用这些目标，通过涉众参与使评估人
员把注意力放在为实现这个目标最重要的构架部分上。
一、ATAM 的参与人员
ATAM 要求如下 3 个小组参与合作：
1，评估小组：
该小组时所评估架构项目外部的小组，通常由 3~5 人组成，每个人可能会扮演不同的角
色。这个小组可能是常设的，也可能临时组织的。可能从理解架构的人员中挑选出来，也可
能是外部咨询人员。在任何情况下，他们必须有能力、没有偏见而且私下也没有其它工作要
做的外部人员。评估小组具体的角色如下：
评估小组负责人：准备评估；与评估客户协调；签署评估合同；组建评估小组；最
终报告的生成与提交。
评估负责人：负责评估工作；促进场景的得出；管理场景的选择及优先级的过程；
促进对照架构的场景评估，为现场分析提供帮助。
场景记录员：在得出场景的过程中，把场景写到白板上，描述场景必须用已达成一
致的措辞，如果没有想出这样的措辞，先终止讨论，直到想出来为止。
进展书记员：以电子形式记录评估进展情况；捕获原始场景；捕获促使每个场景的
问题；捕获与场景对应的构架解决方案；打印出采用场景的列表并分发。
计时员：帮助评估人员使评估工作按时进行，评估过程中控制用在每个场景上的时
间。
过程观察员：记录如何改进评估过程，以及评估如何偏离了原计划。通常不发表意
见，但可以在过程中向评估负责人提出经过谨慎考虑的基于过程的建议。
过程监督者：帮助评估负责人记住并执行评估方法的各个步骤。
提问者：提出涉众可能没想到的关于架构的问题。
2，项目决策者：
这些人对开发项目有发言权，并有权要求进行某些改变，他们通常包括项目管理人员、
承担开发费用的客户代表也可以列入其中，架构设计师必须参与评估。
3，构架涉众：
涉众包括开发人员、测试人员、维护人员、性能工程师、用户以及与该项目交互的其它
项目人员，他们的任务是，清晰而且明白无误地说明架构必须满足的具体质量指标，例如可
修改性、安全性以及可靠性等。
二、ATAM 的结果
ATAM 评估至少应该包括如下结果：
一个简洁的架构表述：通常的架构文档是对象模型、接口及其签名的列表。但 ATAM
要求在一个小时内表述构架，这就要求有一个简洁、可理解的架构表述。
表述清楚的业务目标：业务目标能否表述清楚，关系到架构能否无歧义的实现，对
于开发小组这尤其重要。
用场景集合捕获的质量需求：业务目标导致质量需求，一些重要的质量需求是用场
景的形式来捕获的。
架构决策到质量需求的映射：可以根据构架决策所支持或者所阻碍的质量属性来解
释构架决策，对于 ATAM 期间分析的每个质量场景，确定哪些有助于实现该质量场
景的架构决策。
所确定的敏感点和权衡点集合：这是对一个或者多个质量场景有显著影响的构架决
策。比如，备份数据库是一个架构决策，它正面的影响了可靠性，是一个关于可靠
性的敏感点。但是保持备份消耗了系统资源，又负面的影响了系统性能。因此它是
可靠性与性能的权衡点，这个决策的风险在于，性能成本是不是超过了规定范围。
有风险决策和无风险决策：ATAM 中有风险决策的定义是：根据所陈述质量属性的
需求，可能导致不期望的结果的架构决策。无风险决策与之对应，被认为是安全的
架构决策。
风险主题的集合：分析完成以后，评估小组把发现的所有风险的集合列表，进而寻
找确定架构中系统弱点的总的主题，如果不采取措施，这些风险主题将会影响项目
的业务目标。
三、ATAM 的阶段
ATAM 的活动分四个阶段：
第 0 阶段：为合作关系和准备阶段，评估小组负责人和主要项目决策者进行非正式
会议，以确定此次评估的细节，项目代表向评估人简要概述项目，以使评估小组具
备适当的专业技术人员的协助。另外对于会议的地点、时间以及后勤保障需要实现
达成一致，对于需要什么样的架构文档也需要达成一致。
第 1 和第 2 阶段：为评估阶段，第一阶段，评估小组和项目决策者会晤（通常一天
时间），以开始信息收集和分析工作。第二阶段，构架涉众加入到评估中，分析继
续进行（一般用两天时间），后面会详细讨论这两个阶段的步骤。
第 3 阶段：小组需要生成一个最终的书面报告。在总结会议中，需要讨论哪些活动
比较理想，还有什么需要自我检查和改进的问题，以使评估工作一次比一次更好。
下面对第 2 和第 3 阶段进行讨论，这就是评估阶段的步骤。
第 1 步：ATAM 方法的表述
评估负责人需要向参加会议的项目代表介绍 ATAM，说明每个人要参与的过程，回答有
关问题，负责人需要使用一个简单的演示来简要描述 ATAM 步骤和评估的结果。
第 2 步：商业动机的表述
评估小组成员需要了解促成这个项目开发的主要商业动机，介绍的问题包括：
系统最重要的功能。
相关技术、管理、经济和政治的限制。
该项目相关的商业目标。主要的涉众。
架构驱动因素，也就是形成该构架的主要质量属性目标。
第 3 步：构架的表述
设计师表述架构的本质，在表述中，设计师首先必须谈到架构的约束条件，以及满足这
些条件所使用的模式。在表述中应该抓住重点和本质，讲述构架最重要的方面，而不需要面
面俱到甚至关注自己感兴趣但不太重要的方面。在讲述的时候尽可能使用视图而不是文字。
第 4 步：对架构方法进行分类
通过对每个质量属性使用的模式，可以对架构方法进行分类，评估小组应该对这些模式
和方法进行明确的命名。应该注意到每个方法都影响特定的质量属性，但也可能造成其它不
良的影响。比如分层模式提供了可移植性，但很可能是牺牲性能为代价的。
这个分类表应该由记录员记录下来，以供所有人传阅。
第 5 步：生成质量属性效用树
由于质量属性极大的影响了架构设计，而且不同的架构设计方法对不同的质量属性的影
响可能是矛盾的，比如对安全性要求极高的系统，性能极高的架构可能完全是错误的。
所以，我们必须对质量属性的优先级进行分配，可以生成质量属性效用树，这种树实际
上是一个鱼骨图，从不同的动机中寻找最主要的原因，具体的方法在系统分析中已经讨论过
了，这里不再重复。
第 6 步：分析架构方法
在这里，评估小组每次分析一个最高优先级的场景。方法是设计师解释架构如何支持这
个场景，小组成员通过提问探查设计师用来实现场景的构架方法。在这个过程中，评估小组
把相关架构决策编成文档，确定它的有风险决策、无风险决策、敏感点、权衡点，并且对它
进行分类。必要时说明设计师是如何避开这种架构的弱点并保证该方法满足要求的。
评估小组的目标是，确信这个方法能够达到质量属性的要求。
下面给出一个场景构架方法分析的表格，需要整体上把有风险决策、无风险决策、敏感
点、权衡点列成单独的表，表中 R8、T3、S4 等代表这个表中的条目。
场景号: 场景：检测主交换机的硬件故障并从中恢复过来
属性 可用性
环境 正常操作
刺激 某个 CPU 不能正常工作了
响应 切换可用概率是：0.999999
架构决策 敏感点 权衡点 有风险决策 无风险决策
备用 CPU S2 R8
无备用数据通
道
S3 T3 R9
看门狗 S4 N12
心跳 S5 N13
故障切换路由 S6 N14
至此第一阶段结束，评估小组需要对所获得的知识进行总结，并在 1 到 2 周的中断时间
内与设计师进行非正式会晤（通常用电话形式），如果必要，在这个阶段可以分析更多的场
景，也可以解决已澄清的问题。
当评估决策者准备就绪，把评估组成员再召集到一起的时候，第二阶段就开始了。
此时应该重复前面的第一步，重申在这个阶段每个人所扮演的角色，而且需要概述一下
第 2~6 步的结果，并给每个人一份有风险决策、无风险决策、敏感点、权衡点的当前列表，
当大家熟悉了以评估结果以后，就可以进行下面的 3 步了。
第 7 步：集体讨论并确定架构的优先级
上面第 5 步生成的质量属性效用树，主要是为了了解架构设计师是如何看待质量属性构
架驱动因素的，对场景进行集体讨论，则是为了了解多数涉众的看法，在参与评估的人员比
较多的时候，对场景进行集体讨论非常有效，可以创造出一个人的想法激发其他人灵感的氛
围。
这种讨论过程，能够促进相互交流、发挥创造性、并起到表达参评人员共同意愿的作用。
如果集体讨论确定了优先级的一组场景与效用树进行比较，如果相同，则说明设计师所想的
与大多数涉众的想法基本是一致的。如果又发现了其它驱动场景，则可能存在一个风险，表
明涉众与设计师的想法不一致。
在集体讨论中，不同的涉众对场景的要求可能是不一样的，比如，维护人员可能会更关
注易修改性，最终用户可能会关注一个功能或者易操作性，这就需要讨论和平衡。我们鼓励
涉众考虑在效用树中尚未分析过的场景，或者是在前面的分析中被认为没有引起足够重视的
场景。
确定了场景以后，就必须划分优先级，我们必须注意把有限的评估时间用在最重要的地
方。首先把涉众认为代表相同行为或者质量属性的场景合并起来，然后投票。
投票的方法是，每个涉众拿到总场景数 30%的选票（此数只入不舍，比如 20 个场景，
每个人 6 张选票），投票时可以任意使用这些选票，可以全投给一个场景，也可以一个场景
投一张。
每个涉众都要公开投票，然后评估负责人对场景进行排序，选择“某得票数之上的”场
景，供后续步骤使用。
第 8 步：分析架构方法
对于已经收集的若干场景并且确定了优先级以后，评估小组引导设计师实现第 7 步中得
到的优先级最高的场景。设计师对相关的构架决策如何有助于实现每个场景作出解释。理想
情况下，设计师使用已经讨论过的构架方法对这些场景作出解释。
第 9 步：结果的表述
最后，把 ATAM 分析中得到的各种信息进行归纳总结，并且呈现给涉众。一般来说应该
有一个书面报告，包括商业环境、促成该构架的主要需求、约束条件和架构策略等，然后表
述如下结果：
已经写了文档的构架方法。
经过讨论得到的场景和优先级。
效用树。
所发现的风险决策。
已经编成文档的无风险决策。
所发现的敏感点和权衡点。
我们在评估过程中得到了这些结果，并且对它进行了讨论分类，同时还可以根据一些常
见的基本问题或者系统缺陷把风险分解为风险主题，比如没有足够的重视文档编写、未提供
备份能力或者为提高可用性等。在这个过程中，很可能把某个经理认为是技术层面的风险，
提高为他该关心的某个问题的威胁，这都可能改变后期很多问题的做法。
通过以上讨论，我们得到了一些关于架构设计的有启发性的结论：
1，架构设计是保证软件质量的最重要的要素之一，因此必须由有多年工作经验、对相
关领域知识了解透彻、对质量和项目管理理解深入的人来担任系统构架的工作，架构人员的
想象力是至关重要的。
2，需求分析的系统全面，并且着重于描述高层需求，是架构设计成功的必要条件，因
此我们必须花大力气改善需求分析工作，尤其是需求分析人员必须受过很深的专业训练，对
问题点的把握要准确。
3，软件质量标准决定了架构的风格，所谓高质量软件对于不同的用户要求是完全不一
样的，因此架构设计必须把质量问题放在重要位置认真研究，以寻找恰当的架构策略。
4，研究质量就必须把每个质量属性细化，建立质量属性场景，并对每个场景确定解决
方案，最后综合出架构策略，最后的策略应该经过权衡，把设计的关注点集中在最主要的方
向上。