转：架构设计中的约束分析（作者：温昱）

文章洋洋洒洒，抛开自己已经懂得的，再抛开过于高深的（很多东西看懂了不代表得到了），剩下自己有心得的（往往是跟自己经历相关的），也就剩下用荧光笔标注出来的几句话了，但也足够了。 

 

 

架构设计对系统成败非常关键，那么什么对架构设计成败非常关键呢？

功能需求、质量属性、以及约束共同决定了架构（图1），对这三类需求的把握是否到位、设计决策是否合理，可以说是架构设计成败的关键所在。

质量属性和约束，同属非功能需求，都是重要的“架构决定因素”。质量属性是软件系统的整体质量品质——所谓整体品质，就是它往往和大多数功能都有关，而不是仅仅表现在某个功能“内部”。

至于约束性需求，它们要么是架构设计中必须遵循的限制，要么经过约束分析、转化为质量属性需求或者功能需求。但是，约束分析没有受到架构师的普遍重视，于是约束背后的“衍生需求”变成了“遗漏需求”，造成了架构设计的偏离甚至失败。

 

约束是最危险的需求

 

功能需求、质量属性、约束这三类需求，其“危险性”各有不同。

功能需求是需求变更的主要来源。一刀切地认为“需求变更无处不在”并不正确，也对实践有害（失去了把握较稳定需求的机会）。质量属性需求最为稳定，如多年以来，银行系统总是对安全性、持续可用性要求很高。而约束性需求也相对稳定，技术趋势发生变化、法律法规重新界定、用户组织调整改组等，可能使约束性需求变更。

质量属性往往是架构设计的难点所在。例如，为了满足高性能要求，必须考虑外部及内部不同因素、在各种情况下、对系统不同部分的影响。另外，不同质量属性之间往往相互影响，笔者在《软件架构设计》一书中归纳了其中规律:可重用性、可扩展性等开发期质量属性之间往往是相互促进的;性能和安全性与其他质量属性常有矛盾……

但是，不知道危险何在，才是最危险的！

一方面，质量属性“难”也好，功能需求“变”也罢，这些已为越来越多的人所认识，但对约束当前较为普遍的看法依然是“直接遵守即可”，这是危险的。Mike Dyer最早指出，从需求转入设计时，会激增出大量衍生需求。约束性需求背后就包含许多衍生需求，“约束直接遵守即可”的观点就像“一叶障目”的那片树叶，让架构师忘了约束分析的必要性。

另一方面，我们往往仅关注来自甲方的、位于技术层面的约束，这很危险。有与遗留系统集成的要求吗？行业趋势有何新的动向？……这些深刻影响架构的约束虽来自甲方，但都是非技术约束。乙方自身的技术水平如何？产品在整个产品路线图中的什么位置？……乙方约束，对架构设计亦影响重大！

看来，对架构师而言，最“危险”的需求非约束莫属。

 

对待约束的三种境界

 

境界一是“守”。既然书上说，“约束直接遵守即可”，那在架构设计中就不去费脑子分析约束，这种做法就是第一种境界。

境界二是“破”。尽信书不如无书，越来越多的架构师已经注意到了技术性约束、标准性约束、法律法规性约束等的不同之处，懂得分析约束直接遵守即可、还是会造成间接影响。例如，“必须基于J2EE平台”是条可直接遵守的约束，但“执行现行利率”这条法规性约束却牵扯出诸多功能、及质量考虑。

境界三是“离”。在架构师看来，所有影响架构设计的因素都是需求，只不过需求类型不尽相同罢了。所以，不仅技术方面会有约束，业务方面也会有约束。约束不仅来自于我们经常注意到的甲方，也来自于乙方自身……

外界（甲方）因素是一种约束条件，自身（乙方）能力也是一种约束条件。

守，意味着学习，照本宣科;

破，意味着突破，开始思考;

离，意味着创造，面向实践。

实践者自然崇尚“破”和“离”的境界，接下来的两节，分享一些笔者的实际经验。

 

正交表作为思维工具

 

实践中，我们可以用一个3×3的表格，来辅助全面理解需求、把握需求脉络、发现需求冲突、特别是分析约束背后的衍生需求。我把这种方法叫作“正交表”（图2）。

正交表的“行”代表需求的层次。一个成功的软件系统，对客户高层而言能够帮助组织达到业务目标，这些目标就是客户高层眼中的需求;对实际使用系统的最终用户而言，系统提供的能力能够辅助他们完成日常工作，这些能力就是最终用户眼中的需求;对开发者而言，有着更多用户没有觉察到的“需求”要实现……

正交表的“列”代表需求的类型。例如，一个网上书店系统的功能需求可能包括“浏览书目”、“下订单”、“跟踪订单状态”、“为书籍打分”等，质量属性需求包括“互操作性”和“安全性”等，而“必须运行于Linux平台之上”属于约束性需求之列。实践一再表明，忽视质量属性和约束性需求，常常导致架构设计最终失败。

值得注意的是，正交表的“约束”列纵穿了组织、用户、开发三级需求层次，这恰是正交表方法的特点所在，体现了“约束来自甲方也来自乙方”的思想。

首先，是组织级约束，例如行业标准、法律法规所约束的对象一般为组织。其次，是用户级约束，例如软件的最终用户是老人还是年轻人、是商务人士还是电脑水平较低的人，都会使得架构在易用性、鲁棒性方面有不同考虑。最终，乙方也有影响架构设计的约束，例如团队技术水平较低的话，架构师就要慎重选择较难掌握的技术。

 

架构设计中的约束分析

 

从需求转入设计时，有经验的架构师非常重视衍生需求对架构设计的影响，特别是针对约束、进行约束分析、发现约束背后隐藏的衍生需求。

总体而言，约束分析就是要区分约束影响设计的三种不同途径，并借助正交表方法把衍生需求找出来（结合图3示例进行说明）:

●直接制约设计决策的约束。例如，“系统运行于Unix平台之上”作为一条约束，架构师直接遵守即可。

●转化为功能需求的约束。例如，“本银行系统必须严格执行人行统一规定的利率”是一条约束，但分析后发现，正是它引出了一条功能需求:即必须提供调整利率设置的实用功能。

●转化为质量属性需求的约束。例如，有经验的系统分析员发现了一条重要约束:“任职于各储蓄所和分理处的柜员，计算机水平普遍不高”。由此，未来的软件系统必须具有很高的易用性（否则不会用）和鲁棒性（否则将导致系统瘫痪）。

所谓风险？风险是“你忘了它，它就会找上门来”的一类东西。所以，付诸实践而言，千万不要忘了架构设计中的约束分析环节。

 

图1功能需求、质量属性、以及约束共同决定了架构

 

图2 正交表帮助把握需求脉络、进行约束分析

 

图3 银行系统:约束分析示例