从质量属性及其应对策略的视角优化架构

通过从系统工程的角度分析与组织需求信息，我们已经由需求分析得到了一个框架性的
架构雏形，但那只是架构的一个大概形状，在具体进行架构设计之前，架构师必须进行架构
的进一步分析和设计，从不同的角度审视架构设计，多角度、多层次的修改架构设计方案，
从而得到一个合理的架构基线产品。
对初步的架构轮廓作第一个方面的审视，是从需求分析中仔细思考质量需求对架构的要
求，换句话说就是获取架构因素。架构分析的本质，是识别可能影响架构的因素，了解它的
易变性和优先级，并解决这些问题。其难点是，应该了解提出了什么问题，权衡这些问题，
并掌握解决影响架构重要因素的众多方法。
1，架构分析需要解决的问题
架构分析是高优先级和大影响力的活动。架构分析对如下的工作而言是有价值的：
降低遗漏系统设计核心部分的风险；
避免对低优先级的问题花费过多的精力；
为业务目标定位产品。
架构分析是在功能性需求过程中，有关识别非功能性需求的活动，这些信息对于架构设
计来说，是最值得关注的。
架构分析的一般步骤如下：
辨识和分析影响架构的非功能性需求。
对于那些具有重要影响的需求而言，分析可选方案，并做出处理这些影响的决定，
这就是架构决策
2，识别和分析架构因素
1）架构因素
任何需求对一个系统架构都有重要影响。这些影响包括可靠性、时间表、技能和成本的
约束。比如，在时间紧迫、技能有限同时资金充足的情况下，更好的办法是购买和外包，而
不是内部开发所有的组件。然而，对架构最具影响的因素，包含功能、可靠性、性能、支持
性、实现和接口。通常是非功能性属性（如可靠性和性能）决定了某个架构的独到之处，而
不是功能性需求。
2）质量场景
在架构因素分析期间定义质量需求的时候，推荐应用质量场景。它定义了可量化（至少
是可观测）的响应，并且因此可以验证。质量场景很少使用模糊的不具度量意义的描述，比
如“系统要易于修改”。质量场景用<激发因素><可量化响应>的形式作简短的描述，如：
当销售额发送到远程计税服务器计算税金的时候，“大多数”时候必须 2 秒之内返
回。这一结果是在“平均”负载条件下测量的。
当系统测试志愿者提交一个错误报告的时候，要在一个工作日内通过电话回复。
这里，“大多数”和“平均”需要软件架构师作进一步的调查和定义。质量场景直到做
到真的可测试的时候，才是真正有效的。这就意味着需要有一个详细的说明。
3）架构因素的描述
架构分析的一个重要目标，是了解架构因素的影响、优先级和可变性（灵活性以及未来
演变的直接需要）。因此，大多数架构方法，都提倡对以下信息建立一个架构因素表。
因素 测量和质量场景 可变性（当前灵活性和未来演化） 因素（和其变化）对
客户的影响，架构和
其它因素
优
先
级
困难
或风
险
可靠性 --- 可恢复性
从
远 程
服 务
失 败
中 恢
复。
当远程服务失败
的时候，侦听到远程
服务重新在线的一
分钟内，重新与之建
立联系，在产品环境
下实现正常的存储
装载。
当前灵活性—我们的 SME 认为直
到重新建立连接前，本地客户简化
的服务是可以接受的（也是可取
的）。
演化—在 2 年之内，一些零售商
可能选择支付本地完全复制远程服
务的功能（如税金计算器）。可能
性？高。
对大规模设计影
响大。
零售商确实不愿
意远程服务失败，因
为这将限制或阻止
它们使用 POS 进行
销售。
高 低
…… …… …… ……
注：SME 表示主题专家。
4）从需求文档中获取架构因素
在架构设计中，中心功能需求库就是用例，它的构想和补充规范，都是创建因素表的重
要源泉。在用例中，特殊需求、技术变化、未决问题应该被反复审核。其隐含或者清晰的架
构因素要被统一整理到补充规范里面去。
3，架构因素的解析
架构设计的技巧就是根据权衡、相互依赖关系和优先级对架构因素的解决做出合适的选
择。但这还不全面，老练的架构师具有多种领域的知识（例如：架构样式和模式、技术、产
品、缺陷和趋势），并且能把这些知识应用在它们的决定中。
1）记录架构的可选方案、决定和动机
不管目前架构决策的原则有多少，事实上所有的架构方法都推荐记录：
可选的架构方案；决定；影响因素；显著问题；决定动机。
这些记录按不同的的形式或者完善程度，被称之为：技术备忘录；问题卡；架构途径文
档。技术备忘录的一个重要的方面就是动机或者原理，当开发者或者架构师以后需要修改系
统的时候，架构师可能已经忘了他当初的设计依据（一个资深架构师同时带多个项目的情况
非常多见），备忘录对理解当时的设计背后的动机极为有用。解释放弃被选方案的理由十分
重要，在将来产品进化的过程中，架构师也许需要重新考虑这些备选方案，至少知道当初有
些什么备选方案，为什么选中了其中之一。技术备忘录的格式并不重要，关键是简单、清楚、
表达信息完整。
技术备忘录
问题：可靠性---从远程服务故障中恢复
解决方案概要：通过使用查询服务实现位置透明，实现从远程到本地的故障恢复和本地服务的部分复制
架构因素
从远程服务中可靠恢复
从远程产品数据库的故障中可靠恢复
解决方案
在服务工厂创建一个适配器……
动机
零售商不想停止零售活动……
遗留问题
无
考虑过的备选方案
与远程服务厂商签订“黄金级”服务协议……
2）优先级
下面是指导做出架构决定目标：
不可改变的约束，包括安全和法律方面的事务
业务目标
其它全部目标
早期要决定是否应该避免保证未来的设计，应该实事求是的考虑，哪些是将要推迟到未
来的场景，有多少代码需要改变？工作量将是多少？仔细考虑潜在的变更将有助于揭示什么
是首要考虑的重要问题。一个低耦合高内聚的产品，往往比较容易适应将来的变化，但也要
仔细分析这样付出的代价，在这个问题上，架构师的掂量往往是决定这个项目的生命线。