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

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 Bergquist说得精辟：“我的第一个

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

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

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

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

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

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

10、可能会引起架构设计不再适合。因此，我们希望能通过所有需求的一个子集来“驱动我们的架构决策过程，这样可以减少需求变更对架构设计方案带来的冲击，使架构设计趋于稳定。如图6-1所示。图6-1 关键需求决定架构，其余需求验证架构特别是，功能需求的数量是相当巨大的；通过选取不到20%的典型功能需求，进展有重点的深入分析来带动架构设计，可以节约很多时间。如果再考虑到需求变更的问题，在架构设计期间80%的功能需求的变更都不会对架构设计的推进造成冲击，这太有诱惑力了；毕竟，架构设计之时一般难以到达所有需求都稳定的状态。6.3 确定关键需求在软件过程中所处的位置6.3.1 对架构关键的需求vs.需求优先级在软件

11、过程上游的需求分析活动中，我们有必要识别并记录需求的优先级，这对工程管理乃至控制交付围等都有重要影响。那么，工程经理所关心的需求优先级和软件架构师所关心的对架构关键的需求之间，到底是什么关系呢？一“图以蔽之。如图6-2所示，高优先级的需求和对软件架构关键的需求之间，既有区别又有联系。图6-2 对架构关键的需求vs.需求优先级一个事物是否关键、是否优先考虑，要视具体目标不同而定。我们通常所说的“需求优先级是针对客户而言的同时要从技术角度考虑需求之间的依赖关系，而本章的主题“对软件架构关键的需求是对架构设计的影响而言的，请读者注意区分。需求优先级主要是针对功能需求而言的，除却被依赖的需求应当优先实

12、现之外，需求优先级主要反映了客户希望最终系统提供某功能需求的迫切程度。一般而言，需求优先级可以分为三级：高优先级。必不可少的功能。只有在这些需求上达成一致意见，软件才可能被承受。这些功能的实现质量必须趋于完美；中优先级。必要的功能。这些功能是系统所需要的，如果有必要可以延迟实现。虽然不提供这些功能系统也有可能被承受，但最好不要忽略它们。值得为这些功能的质量付出努力；低优先级。锦上添花式的功能增强。低优先级的需求可以实现也可以不实现；但如果资源允许的话，实现这些需求将会使产品更臻完美。另外，对于这些需求的实现质量要求不是很高，甚至可以容忍不严重的缺陷存在。鉴于此，我们也就不难理解，一个工程中，需

13、求优先级为高、中、低的需求的比例应该科学比方3:4:3，从而有利于工程管理。如果将需求优先级统统定为高，或者需求优先级为高的需求明显占了压倒性的比例，这显然是不科学的做法，违背了设定需求优先级的初衷，不利于工程管理中权衡与调整。鉴于工程管理不是本书的主题，对此我们不再展开讨论。总之，可以这么说，需求优先级是工程经理的一种权衡和决策的工具如图6-3所示。该工具使工程经理可以在一定程度上获得对工程管理的灵活调整的余地，为了在工程的时间、本钱和质量要求围顺利完成目标，对工程所提供的功能围Scope进展调整。图6-3 需求优先级是工程经理的一种权衡和决策工具6.3.2 关键需求对后续活动的影响确定了对

14、架构关键的需求之后，软件架构师下面的活动将主要针对这些关键需求展开如图6-4所示：无论对于概念性架构的设计第14章，还是实际架构的设计第16章，都需要对关键用例进展分析。此时将采用鲁棒图等用例分析技术，最终将各鲁棒图进展综合，得到整体的软件系统职责划分模型也被称为逻辑设计模型或分析模型；质量属性分析中，采用“质量属性场景决策表等技术手段，分析质量属性要求，制定架构级设计决策；当然，经过质量属性分析之后得到的架构决策，可能引起软件系统职责划分模型的调整。以高性能设计为例，无论是“对消息采用多线程并发处理还是“将图片效劳器独立出来以便进展专门的缓存和索引等加速处理都需要对软件系统职责划分模型进展细

15、化等调整。图6-4 关键需求与后续活动6.4 什么是对软件架构关键的需求对软件架构关键的需求包括功能需求、质量属性需求、商业需求三类，下面一一讨论之。6.4.1 关键的功能需求任何功能需求，都是由一条特定的“模块协作链完成的。所谓软件架构就是关于如何构建软件的一些最重要的设计决策，这些决策往往是围绕将系统分为哪些局部、各局部之间如何交互展开的。而一个完整的软件功能的实现，那么需要这些不同的“局部之间相互配合，形成一条“模块协作链，从而才能满足一个完整的应用功能。控制权在模块协作链中来回传递，而功能需求就相当于串起不同模块的线索如图6-5所示。图6-5 功能需求与模块协作链参考?AOSD中文版?

16、所以，所谓对软件架构关键的功能需求，就是它涉及或串起的模块最多、最典型的功能需求。毕竟，由于功能需求数量众多，其实会有很多功能需求的完成所涉及的“模块协作链都非常相似。软件架构师通过分析少数关键的功能需求，往往就可以完成一般性的模块划分、职责分配、协作机制定义等和功能需求密切相关的架构设计工作。6.4.2 关键的质量属性需求要到达高质量属性要求，是有本钱的。例如，持续可用性的本钱最为明显，它往往要求通过硬件及网络连接的冗余来实现，使本钱投入非常可观。因此，现实中一般应慎重考虑对哪些质量属性提出高要求。另一方面，不同质量属性之间往往具有相互制约性，使得有些质量属性需求同时到达高要求比拟困难。例如

17、，“互操作性需求往往给“平安性需求造成威胁，而为了满足“高性能需求，往往需要使用特定平台的非标准能力，这势必影响了系统的“可移植性，不一而足。于是，我们自然应该权衡哪一局部质量属性是架构设计的重点目标。综上所述，对架构至关重要的质量属性需那些经过权衡取舍、最终决定重点支持的质量属性需求。6.4.3 关键的商业需求商业需求又称业务需求其实对应的英文都为Business Requirement。一般情况下，商业需求指“组织或客户高层次的目标。但作为“架构设计驱动因素的商业需求有着更广泛的含义：它关注从客户群、企业现状、未来开展、预算、立项、开发、运营、维护在的整个软件生命周期涉及的商业因素，包括了

18、商业层面的目标、期望和限制等。目标和期望的例子很多。例如投资开发一个软件系统的企业可能期望“业务处理能力提高50%，产品型的软件公司可能期望“半年该产品的市场占有率达40%或者“半年销售20万套，等等。出于商业方面考虑的限制因素五花八门，但它们往往对架构设计有很大影响。表6-1进展了归纳总结。表6-1 商业需求中可能的限制因素因素分类因素对架构的影响经济因素本钱收益预算多少会影响架构师对技术的选择可重用性、可维护性、可移植性上市时间重用程度、技术选型通过采购模块或平台减少开发工作量客户群多国语言架构对多国语言的支持移动与便携支持哪些协议、哪些客户端是否按产品线进展规划可移植性企业现状遗留系统的

19、集成互操作性企业人员和部门分布分布式系统架构可维护性、平安性未来开展期望的系统生存期可伸缩性、可扩展性、可移植性续表因素分类因素对架构的影响阶段性方案可重用性可伸缩性、可扩展性、可移植性其他因素法律法规可扩展性可修改性、可维护性竞争对手技术选择易用性6.5 如何确定对软件架构关键的需求图6-6展示了确定对软件架构关键需求的步骤，下面我们将一一讨论。图6-6 确定对软件架构关键需求的步骤6.5.1 全面整理需求软件架构师为了确定关键需求，他需要全面整理需求，从而对需求建立通盘认识。为此，软件架构师可能需要：研究?愿景和围文档?研究?软件需求规格说明书?参加需求讨论会询问客户、用户、领域专家、系统

20、分析员大多数情况下需求文档未必有软件架构师需要的所有信息，例如易扩展性、易测试性等开发期质量属性往往是?软件需求规格说明书?相对薄弱的环节，所以软件架构师必须通过通盘理解需求，将缺失的、隐含的需求找出来。如果条件允许，软件架构师应该多参与需求活动，这样更有利于把握需求的轻重缓急。6.5.2 分析约束性需求对约束性需求进展分析非常有必要，因为很多约束之中“藏着一些隐含的需求，我们必须将它们找出来。总体而言，约束性需求可能通过三种途径影响设计如图6-7所示。图6-7 约束性需求影响设计的三种途径直接制约设计决策。例如，“系统运行于Linux平台之上作为一条约束，架构师直接遵守即可；转化为功能需求。

21、例如，“本银行系统必须严格执行人行统一规定的利率是一条约束，但分析后发现，正是它引出了一条功能需求：即必须提供调整利率设置的实用功能；转化为质量属性需求。例如，有经历的系统分析员发现了一条重要约束：要开发的软件系统的预期用户计算机水平普遍不高。由此，未来的软件系统必须具有很高的易用性否那么不会用和鲁棒性否那么可能把系统搞瘫痪了就是非常必要的啦。6.5.3 确定关键功能需求如何确定关键功能需求？对此，Per Kroll和Philippe Kruchten在?Rational统一过程实践者指南?中所论述的相当令人信服或许读者需要一点RUP知识根底：在初始阶段，应该确定出一些大概占总数的20%至30

22、%对系统起关键作用的用例。这些用例通常对创立架构具有重要影响。A. 作为应用程序的核心或实现了系统的主要接口的功能，因此，对系统架构有很重要的影响。通常系统架构师通过分析冗余的管理策略、资源互斥风险、性能风险和数据平安风险等来识别出哪些用例是最重要的。例如，在销售系统中，从信用卡划账和支付是最主要的用例，因为它是与信用卡确认系统的接口，它的负载和性能特性也很重要。B. 必须被实现的功能。这些功能反映了系统的本质，如果这些功能不能实现，那么开发出的应用程序就没有价值了。通常领域专家和相关方面的专家知道用户最需要哪些功能主要行为、数据处理的峰值和关键的控制操作等。比方，如果没有承受订单的功能，就不

23、能实现一个订单发布系统。C. 覆盖了系统架构的一些方面，但没有被其他重要的用例覆盖到的功能。要确保解决所有主要技术风险，就必须全面了解系统的每个方面。否那么，即使架构中的某个方面看起来没有重大风险，但是在设计、实现和测试时就很有可能发现这个局部中潜伏着巨大的技术风险。读者还要识别用户需求中的一些难于实现的、未知的或者存在风险的元素也许包括一些非功能性的元素，并且要找到一些用例或者用例的一局部来说明当前遇到的困难以及解决方案的风险。在这个过程中，通常会有一些技术性风险转移到系统架构的根底局部中。例如，如果系统对时间响应特性或负载特性有特殊的要求，就要识别出一个用例或者用例的一个事件流来说明这个需

24、求，同时还要表现出对特性的要求。还有其他一些例子，比方错误恢复策略和系统初始化策略等。最后，还要识别出这样的一些用例：它们既不会对系统架构产生重要影响也没有技术风险，但是它们描述了尚未涉及到的系统功能。这样，在细化阶段完毕时，才能创立出表达系统要领的整体架构。例如，要确保每个主要的“业务实体都至少与一个核心用例交互。6.5.4 确定关键质量属性需求为了确定对架构设计关键的质量属性需求，需要做如下三方面的工作：考虑为了提高要开发的软件系统受认可的程度，应着重提高哪些方面的质量属性要求接下来，充分考虑这些质量属性的相互制约或相互促进关系，以调整不同质量属性的要求标准例如，你可能会决定高性能要求最最重要，而可扩展性也比拟重要；同时，必须满足各种约束性需求。