确定对架构的关键需求.doc

1、关键需求决定架构。软件架构师没有时间对“所有需求”进行深入分析，这是现实大多数项目都面临项目工期的压力，软件架构师必须在一定的时间内定夺架构设计方案；否则，没有软件架构所提供的对技术的足够指导以及对分工协作的足够限制，后期的团队开发将面临巨大风险。软件架构师没有必要对“所有需求”进行深入分析，这是策略把大部分时间和精力花在对决定架构最重要的一部分需求上，好钢用在刀刃上，最终你设计出的软件架构的质量反而会更高；否则，所有需求的分析都不够深入，导致最终设计出的软件架构可能会流于形式。6.1 虚拟高峰论坛：穷兵黩武还是择战而斗解释一下这两个隐喻。所谓“穷兵黩武”是指把所有需求彻底分析一遍从而设计出软

2、件架构的做法，而“择战而斗”是指为了设计架构仅重点分析对软件架构起关键作用的一部分需求的做法。读书犹如和作者交谈。本节的写作形式颇为轻松：我们假设把一些高人请到了一起，就“从软件需求到软件架构”问题展开一个“高峰论坛”（当然是虚拟的）。6.1.1 需求是任何促成设计决策的因素说到底，一个软件系统的软件架构最终设计成什么样，是由软件需求决定的。咨询专家 Brian Lawrence 提出：“需求是任何促成设计决策的因素（Anything that drives design choices）。”6.1.2 很少有开发者能奢侈地拥有一个稳定的需求集“需求决定架构”。话虽这么说，但现实要复杂得多，因

3、为软件需求本身会因需求背景的变化和项目人员的理解等问题发生变更。正如软件需求管理：统一方法的作者 Dean Leffingwell 所说：“很少有开发者能奢侈地拥有一个稳定的需求集”6.1.3 关键性的第一步是缩小范围勿在浮沙筑高台。倘若作为架构设计重要依据的软件需求变化了，你建起的软件架构这个“高台”岂不是要倒塌？杰拉尔德温伯格的话让人更深刻地体会到了“运筹帷幄”应有的含义，他说：“关键性的第一步是缩小范围”6.1.4 要择战而斗穷兵黩武还是择战而斗，这或许不是问题，因为我们已经倾向于择战而斗了。但问题在于，择战而斗怎么个“择”法。PeopleSoft 公司的首席技术官 Rick Bergq

4、uist 说得精辟：“我的第一个老板 John Grillos 曾说过，要择战而斗。择战的标准如下：它们要具有重要性，它们要具有可能性，它们的数量要少。”6.1.5 功能、质量和商业需求的某个集合塑造了构架方向已经明确了，不是吗？软件架构师要着重深入分析的是软件需求的一个子集，再结合自己的经验，最终设计出软件架构。卡内基梅隆大学软件工程研究所的 Len Bass 指出：“功能、质量和商业需求的某个集合塑造了构架。我们把这些塑造需求称为构架驱动因素。知道了构架驱动因素后，就可以开始构架设计了。”6.2 关键需求决定架构6.2.1 实践中的常见问题在从需求工作向架构设计工作转移的环节上，我们在实践

5、中暴露出一些问题。对于软件架构师而言，这些问题在一定程度上相当普遍，所以我们一起来解决它们。问题一：抱怨留给架构设计的时间太短，而不是接受项目节奏普遍加快的现实。从根本上讲，这是没有意识到软件开发所根植于的业务背景当然，我相信或多或少也受到瀑布模型的影响。无论是对于企业业务还是个人业务，在复杂和高速变化的经济环境里，在对手云集的竞争条件下，软件系统“上马”太慢本身就潜藏着巨大风险。在非程序员第 50 期中有一篇来自 Markus Vlter 和 Jorn Bettin 的论文模型驱动软件开发模式，其中强调新的商业应用的开发期最多不得超过 9 个月： 每三个月至少要提供可交付代码。理想情况下，每

6、三个月应将代码部署到产品中，并得到实际反馈。新的商业应用的开发，必须在九个月之内“哇哇坠地”，否则就可能危及“妈妈”（开发组）或“婴儿”（应用）的生命问题二：认为必须详细分析所有的需求，只有这样才能设计出满足所有需求的软件架构有仗就打、有人讨敌骂阵就出战，这种情形在历史小说里经常见到，但往往出现在有勇无谋的武将身上。与此类似，想要将所面对的所有需求都分析一遍的软件架构师是否想过：这是否现实？在有限的时间里，将精力分散在过多的问题上，其结果往往是效果更差。我们的策略是：关键需求决定架构，其余需求验证架构。顺着“全面认识需求”的策略思考开去，很容易让人产生疑问：你是在说瀑布式开发吗？当然不是。我们

7、的策略是：在架构设计期间，关键需求决定架构，其余需求验证架构。也就是说，“关键需求决定架构”和“全面认识需求”的策略是不矛盾的。非关键需求可以用来验证架构，比如以架构方案评审的方式，从每项非关键需求的角度对架构方案进行走查。问题三：认为软件架构必须是完美的技术解决方案。关于这一点，Philippe Kruchten 在他的论文Common Misconceptions about Software Architecture中明确地进行了批评，并指出架构“够用就好”：通常，在进行系统架构设计时，时间非常关键。架构师根本没有时间去系统地研究每一种可能的解决方案，以找出最佳解决方案；而是必须快速决策

8、，以便让软件开发工作进行下去。项目开发就像一场“战斗”，如果慢慢吞吞地研究出了最佳解决方案，只怕整场“战斗”早已结束多时了，这显然毫无意义。我经常这样描述架构师的工作：在有些事情并未完全清楚的情况下，快速做出一系列并不算完美的设计决策。架构并不是静态功能，因此无法优化至最佳无论是设计约束，还是棘手问题，都不会长时间不变而“等”你找到最佳方案。架构不是要完美，而是要足够满意。6.2.2 关键需求决定架构采用关键需求决定架构的方法，其好处有二：一曰防守，二曰进攻。说到“防守”，多少有些“不得不为”的意味。的确如此。一方面，把所有需求统统确定下来之后再开始下游活动是不现实的。需求来自于实践的需要，而

9、实践是发展的，所以“确定的需求”只能是暂时的。于是，我们不得不在“部分需求已确定”的情况下进行架构设计。另一方面，项目何时交付往往是由客户业务的需要决定的，或者是由市场形势决定的，这使得项目工期成了不可改变的“外部限制”（上市时间是一种非功能需求）。时间有限，我们不得不在就项目的业务目标及核心需求达成共识之后开始架构设计，而这时需求并未完全清晰化。至于“进攻”就是对期望目标的“主动追求”了。我们希望追求的目标有两个：第一，用有限的精力深入分析最为重要的需求。人的思维能力所能应对的复杂性是有限的，因此人们总是有意识地将问题分解、化简和转换。当我们把全部精力放在相对少的需求上时，可以更为深入地分析

10、这些需求，有利于得到透彻的认识，从而设计出合理的架构。第二，因为需求是“促成设计决策的因素”，因此需求的变更可能会引起架构设计不再适合。因此，我们希望能通过所有需求的一个子集来“驱动”我们的架构决策过程，这样可以减少需求变更对架构设计方案带来的冲击，使架构设计趋于稳定。如图 6-1 所示。图 6-1 关键需求决定架构，其余需求验证架构特别是，功能需求的数量是相当巨大的；通过选取不到 20%的典型功能需求，进行有重点的深入分析来带动架构设计，可以节约很多时间。如果再考虑到需求变更的问题，在架构设计期间 80%的功能需求的变更都不会对架构设计的推进造成冲击，这太有诱惑力了；毕竟，架构设计之时一般难

11、以达到所有需求都稳定的状态。6.3 确定关键需求在软件过程中所处的位置6.3.1 对架构关键的需求 vs.需求优先级在软件过程上游的需求分析活动中，我们有必要识别并记录需求的优先级，这对项目管理乃至控制交付范围等都有重要影响。那么，项目经理所关心的需求优先级和软件架构师所关心的对架构关键的需求之间，到底是什么关系呢？一“图”以蔽之。如图 6-2 所示，高优先级的需求和对软件架构关键的需求之间，既有区别又有联系。图 6-2 对架构关键的需求 vs.需求优先级一个事物是否关键、是否优先考虑，要视具体目标不同而定。我们通常所说的“需求优先级”是针对客户而言的（同时要从技术角度考虑需求之间的依赖关系）

12、，而本章的主题“对软件架构关键的需求”是对架构设计的影响而言的，请读者注意区分。需求优先级主要是针对功能需求而言的，除却被依赖的需求应当优先实现之外，需求优先级主要反映了客户希望最终系统提供某功能需求的迫切程度。一般而言，需求优先级可以分为三级：高优先级。必不可少的功能。只有在这些需求上达成一致意见，软件才可能被接受。这些功能的实现质量必须趋于完美；中优先级。必要的功能。这些功能是系统所需要的，如果有必要可以延迟实现。虽然不提供这些功能系统也有可能被接受，但最好不要忽略它们。值得为这些功能的质量付出努力；低优先级。锦上添花式的功能增强。低优先级的需求可以实现也可以不实现；但如果资源允许的话，实

13、现这些需求将会使产品更臻完美。另外，对于这些需求的实现质量要求不是很高，甚至可以容忍不严重的缺陷存在。鉴于此，我们也就不难理解，一个项目中，需求优先级为高、中、低的需求的比例应该科学（比如 3:4:3），从而有利于项目管理。如果将需求优先级统统定为高，或者需求优先级为高的需求明显占了压倒性的比例，这显然是不科学的做法，违背了设定需求优先级的初衷，不利于项目管理中权衡与调整。鉴于项目管理不是本书的主题，对此我们不再展开讨论。总之，可以这么说，需求优先级是项目经理的一种权衡和决策的工具（如图 6-3 所示）。该工具使项目经理可以在一定程度上获得对项目管理的灵活调整的余地，为了在项目的时间、成本和质

14、量要求范围内顺利完成目标，对项目所提供的功能范围（Scope）进行调整。图 6-3 需求优先级是项目经理的一种权衡和决策工具6.3.2 关键需求对后续活动的影响确定了对架构关键的需求之后，软件架构师下面的活动将主要针对这些关键需求展开（如图 6-4 所示）：无论对于概念性架构的设计（第 14 章），还是实际架构的设计（第 16 章），都需要对关键用例进行分析。此时将采用鲁棒图等用例分析技术，最终将各鲁棒图进行综合，得到整体的软件系统职责划分模型（也被称为逻辑设计模型或分析模型）；质量属性分析中，采用“质量属性场景决策”表等技术手段，分析质量属性要求，制定架构级设计决策；当然，经过质量属性分析之

15、后得到的架构决策，可能引起软件系统职责划分模型的调整。以高性能设计为例，无论是“对消息采用多线程并发处理”还是“将图片服务器独立出来以便进行专门的缓存和索引等加速处理”都需要对软件系统职责划分模型进行细化等调整。图 6-4 关键需求与后续活动6.4 什么是对软件架构关键的需求对软件架构关键的需求包括功能需求、质量（属性）需求、商业需求三类，下面一一讨论之。6.4.1 关键的功能需求任何功能需求，都是由一条特定的“模块协作链”完成的。所谓软件架构就是关于如何构建软件的一些最重要的设计决策，这些决策往往是围绕将系统分为哪些部分、各部分之间如何交互展开的。而一个完整的软件功能的实现，则需要这些不同的

16、“部分”之间相互配合，形成一条“模块协作链”，从而才能满足一个完整的应用功能。控制权在模块协作链中来回传递，而功能需求就相当于串起不同模块的线索（如图 6-5 所示）。图 6-5 功能需求与模块协作链（参考AOSD 中文版）所以，所谓对软件架构关键的功能需求，就是它涉及（或串起）的模块最多、最典型的功能需求。毕竟，由于功能需求数量众多，其实会有很多功能需求的完成所涉及的“模块协作链”都非常相似。软件架构师通过分析少数关键的功能需求，往往就可以完成一般性的模块划分、职责分配、协作机制定义等和功能需求密切相关的架构设计工作。6.4.2 关键的质量属性需求要达到高质量属性要求，是有成本的。例如，持续

17、可用性的成本最为明显，它往往要求通过硬件及网络连接的冗余来实现，使成本投入非常可观。因此，现实中一般应慎重考虑对哪些质量属性提出高要求。另一方面，不同质量属性之间往往具有相互制约性，使得有些质量属性需求同时达到高要求比较困难。例如，“互操作性”需求往往给“安全性”需求造成威胁，而为了满足“高性能”需求，往往需要使用特定平台的非标准能力，这势必影响了系统的“可移植性”，不一而足。于是，我们自然应该权衡哪一部分质量属性是架构设计的重点目标。综上所述，对架构至关重要的质量属性需求是那些经过权衡取舍、最终决定重点支持的质量属性需求。6.4.3 关键的商业需求商业需求又称业务需求（其实对应的英文都为 B

18、usiness Requirement）。一般情况下，商业需求指“组织或客户高层次的目标”。但作为“架构设计驱动因素”的商业需求有着更宽泛的含义：它关注从客户群、企业现状、未来发展、预算、立项、开发、运营、维护在内的整个软件生命周期涉及的商业因素，包括了商业层面的目标、期望和限制等。目标和期望的例子很多。例如投资开发一个软件系统的企业可能期望“业务处理能力提高 50%”，产品型的软件公司可能期望“半年内该产品的市场占有率达 40%”或者“半年内销售 20 万套”，等等。 出于商业方面考虑的限制因素五花八门，但它们往往对架构设计有很大影响。表 6-1 进行了归纳总结。表 6-1 商业需求中可能的限制因素因素分类 因素 对架构的影响经济因素 成本收益预算多少会影响架构师对技术的选择可重用性、可维护性、可移植性上市时间重用程度、技术选型通过采购模块或平台减少开发工作量客户群 多国语言架构对多国语言的支持