软件构架评估

软件构架评估

Version 1.0

2008-12-1

本文为《软件构架实践》一书的读书笔记。

一、            总述

Why：通过构架能了解系统的重要属性，即使系统还不存在，这是构架评估的理论依据；评估检验构架能否满足要求，带来诸多收益；

What：

When：可在多个点上进行——构架的早期，评估已经做出的决策与正在考虑的决策；构架完成后开始进入细节前；对已完成的早期系统的评估；采购软件系统前对其进行评估…

Where：XXX

Who：也许因评估方法而异；

How：定量方法与非定量方法；

How mush：参与人员的时间花费；

Preconditions：清楚的构架目标与需求；可控的明确的构架目标；合适的评估方法以保证收益大于付出；关键人员，设计师或至少透彻理解构架的人员的参与；称职、权威的评估小组，以使评估活动及结果能得到各方的尊重和认同；可管理的期望，理解组织对评估的期望；

Output：报告，描述了所关心的问题及其支持数据，如果存在未解决问题则确定其优先级；其他，包括对评估活动本身的总结，以提高以后的能力；

二、            ATAM

构架权衡分析方法：一种非定量方法，它可揭示构架满足特定质量目标的情况，及构架对质量目标的权衡；

1， 人员

评估小组：独立的评估小组，包括小组负责人、评估负责人、书记员、计时员、过程观察者、提问者等角色；

项目决策者：有权要求项目改变的人，管理人员，客户代表，设计师；

涉众：开发、测试、维护、用户等，他们说明构架应满足的具体目标；

2， 输出

能在1小时内表述的构架描述

清楚的业务目标

用场景捕获的质量需求

敏感点、权衡点、有风险决策、无风险决策…

3， 过程，4阶段法

l         0阶段，合作关系与准备，确定细节：人员名单，时间，地点；评估小组获取资料并进行初步了解分析；

l         1阶段，评估阶段，决策者参与，小组开始信息收集与分析；耗时约1周

1～2周中断期，评估小组进一步以非正式方式了解构架；

l         2阶段，评估阶段，涉众参与，分析继续；约2天；

l         3阶段，后续阶段，生成最终报告，进行评估活动总结；1周；

 

评估阶段的细分：

1）  评估负责人向决策者表述ATAM方法，使大家理解其过程，了解角色布局；

2）  决策者介绍系统商业动机、重要功能、各种限制、商业目标、驱动因素等；

3）  设计师介绍构架，技术限制、所用模式等；

4）  评估小组利用所有已知信息对构架方法进行分类；

5）  生成质量属性效用树，捕获详细的需求信息，为每个场景分配一个级别，如（高，中），前者为重要度，后者为实现难易度，重点放在（高，高）的场景；此处场景具备刺激、环境、响应三要素就可以了；

6）  评估小组分析所有重要场景，设计师解释如何支持该场景，检查所用构架方法，分析风险点、权衡点、敏感点；

 

效用树：效用为根，性能等质量属性组成二级节点，继续细分直到场景，场景为叶；

经过一段中断期，第2阶段开始，此时涉众开始参与；首先仍然需要一个对ATAM方法的介绍，并使涉众了解已有的成果；

7）  集体讨论并分析场景的优先级，以了解更广泛的涉众的想法；该过程可能产生新的场景；使用“有限票数法”投票确定每个场景的优先级——此处不考虑实现难度了吧；

8）  分析新的高优先级的场景，构架师解释构架是怎么满足各场景的；

9）  总结评估结果，评估负责人展示该结果；

注意，看起来第1阶段与第2阶段活动类似，但它们的关注点与具体操作并不相同。

4， 限制

ATAM不是一个准确的方法，且风险不可被量化；

5， 小结

看起来ATAM是一个通过捕获详细的质量属性场景，选择其中最重要的一部分，考虑构架如何满足这些场景来进行评估的方法；这是一个“过程”方法而非技术方法；

三、            CBAM

成本收益分析方法：对构架设计决策的成本和收益进行建模，一个定量计算的方法；与ATAM的关系是，它可以利用ATAM的输出。

定量计算存在太多不确定因素——看看老外是怎样设法解决某些“不可解决”的问题的。

1， 原理

CBAM使用“一组”场景进行评估，它们构成“效用—响应曲线”，其x轴为响应的取值，y轴为对应效用值，即y=f(x)；使用该曲线获得相应变化时所能获得的效用的变化值。

曲线生成——“4值近似法”（书中提及的第5个值，看起来不是用来生成曲线的，而是使用曲线的），这些值都需要从涉众处获得：

l         最好情况的质量属性级别，最好指继续提高质量属性也不能带来效用的提升，此时效用值取100（如1秒）；

l         最坏情况的质量属性级别，最坏指如果质量属性低于该值，系统将毫无价值（如10秒）；

l         本场景（曲线表现的是某个场景）当前的响应与效用级别（当前是5秒，用户愿意付钱50）；

l         期望的效用级别（如果能达到3秒，用户愿意支付80）

确定每个属性的权重，构架师选择策略，考虑策略对每个属性的影响，计算获得的总收益与成本；

2， 过程

1，  整理场景，根据商业目标确定优先级，选择1/3的场景；

2，  确定每个场景的最好、最坏、当前、期望情况的质量响应级别——此步仅处理响应级别，期望值有可能等于最好值；

3，  涉众投票确定场景优先级——这将同时获得各场景的权重，去掉一半低优先级的场景；

4，  涉众为剩下的场景，根据2中的响应确定效用；

5，  为场景开发构架策略，确定所期望的通过该构架策略所能获得的质量属性响应级别；需要分析该策略可能影响的所有场景；

6，  使用内插法确定策略的效用；

7，  计算每个场景的总收益；

8，  确定每个场景的成本/收益ROI，依照值的高低选择策略，除非其不能满足预算或进度要求；

9，  通过直觉检验结果，如果差别巨大，可能需重新考虑整个过程；

3， 问题

1，  为何不把3提前，首先去掉更多的场景以减少工作量？

2，  为何把响应级别与其效用的取值分开成两步来做？

难道这些仅仅是“最佳实践”？

4， 小结

本方法通过引入“效用—响应曲线”，主要解决了响应的提升所能带来的效用的计算问题；理论上，如果能获得准确的“效用—响应曲线”，加上准确的当前响应值（该值应该较易得到），加上策略所能产生影响的准确值，就能计算出策略的准确的ROI。

可见，要想获得准确的结果，至少下述问题需要解答：

怎样确保“效用—响应曲线”——哪怕仅仅是那4个点——足够准确？

怎样准确确定策略将影响到那些场景？

怎样确定策略对某个场景能产生多大的响应提升？

没有好的解决办法，甚至无所不能的“历史数据”，看起来都作用有限，于是目前只能完全依赖于检验了；这也是步骤9的由来：其实大家对某个策略所能产生的效果都有个“直觉值”，而CBAM的过程使涉众能够将那个总的直觉分解到各个步骤中，并且使用不同的、更规范的思维方式表现出来（对最好值的直觉、对策略的效应的直觉…）。这就是CBAM的结果应该与涉众直觉大体一致的原因。

四、            参考资料

《软件构架实践》。