确定对架构的关键需求

《确定对架构的关键需求》由会员分享，可在线阅读，更多相关《确定对架构的关键需求（21页珍藏版）》请在装配图网上搜索。

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

2、武”是指把所有需求彻底分析一遍从而 设计出软件架构的做法，而“择战而斗”是指为了设计架构仅重点分析对软件架 构起关键作用的一部分需求的做法。读书犹如和作者交谈。本节的写作形式颇为轻松：我们假设把一些高人请到 了一起，就“从软件需求到软件架构”问题展开一个“高峰论坛” （当然是虚拟 的）。6.1.1 需求是任何促成设计决策的因素说到底，一个软件系统的软件架构最终设计成什么样， 是由软件需求决定的。咨询专家Brian Lawrence提出：“需求是任何促成设计决策的因素(Anything that drives desig n choices)。”Wf求是任诃促琏设计决董的因5S *6.1.2 很

3、少有开发者能奢侈地拥有一个稳定的需求集“需求决定架构”。话虽这么说，但现实要复杂得多，因为软件需求本身会 因需求背景的变化和项目人员的理解等问题发生变更。正如软件需求管理：统一方法的作者Dea n Leffin gwell 所说：“很少有开发者能奢侈地拥有一个稳定的需求集”礙少育幵发雷能害侈抱 拥有一个律定的爲求SU专业技术知识共享6.1.3 关键性的第一步是缩小范围勿在浮沙筑高台。倘若作为架构设计重要依据的软件需求变化了， 你建起的软件架构这个“高台”岂不是要倒塌？杰拉尔德温伯格的话让人更深刻地体会到了“运筹帷幄”应有的含义，他说：“关键性的第一步是缩小范围关键性的第一歩理赠小范囤”6.1.

4、4 要择战而斗穷兵黩武还是择战而斗，这或许不是问题，因为我们已经倾向于择战而斗了但问题在于，择战而斗怎么个“择”法。PeopleSoft公司的首席技术官Rick Bergquist说得精辟：“我的第一个老板John Grillos曾说过，要择战而斗。择战的标准如下：它们要具有重要性，它们要具有可能性，它们的数量要少。”要择战而斗6.1.5功能、质量和商业需求的某个集合塑造了构架方向已经明确了，不是吗？软件架构师要着重深入分析的是软件需求的一个 子集，再结合自己的经验，最终设计出软件架构。卡内基梅隆大学软件工程研究所的 Len Bass指出：“功能、质量和商业需求的某个集合塑造了构架。我们把这些

5、塑造需求称为构架驱动因素。知道了构架驱动因素后，就可以开始构架设计了。”功能、质:和商业霁蕈6.2 关键需求决定架构6.2.1实践中的常见问题在从需求工作向架构设计工作转移的环节上， 我们在实践中暴露出一些问题。 对于软件架构师而言，这些问题在一定程度上相当普遍，所以我们一起来解决它 们。问题一：抱怨留给架构设计的时间太短，而不是接受项目节奏普遍加快的现 实。从根本上讲，这是没有意识到软件开发所根植于的业务背景一一当然，我相信或多或少也受到瀑布模型的影响。无论是对于企业业务还是个人业务，在复杂 和高速变化的经济环境里，在对手云集的竞争条件下，软件系统“上马”太慢本 身就潜藏着巨大风险。在非程序

6、员第 50期中有一篇来自Markus V?lter和 Jorn Bettin的论文模型驱动软件开发模式，其中强调新的商业应用的开发 期最多不得超过9个月：每三个月至少要提供可交付代码。理想情况下，每三个月应将代码部署到产品中，并得到实际反馈。新的商业应用的开发，必须在九个月之内“哇哇坠地”，否则就可能危及“妈妈”（开发组）或“婴儿”（应用）的生命问题二：认为必须详细分析所有的需求，只有这样才能设计出满足所有需求的软件架构有仗就打、有人讨敌骂阵就出战，这种情形在历史小说里经常见到，但往往出现在有勇无谋的武将身上。与此类似，想要将所面对的所有需求都分析一遍的 软件架构师是否想过：这是否现实？在有限

7、的时间里，将精力分散在过多的问题 上，其结果往往是效果更差。我们的策略是：关键需求决定架构，其余需求验证架构。顺着“全面认识需求”的策略思考开去， 很容易让人产生疑问：你是在说瀑 布式开发吗？当然不是。我们的策略是：在架构设计期间，关键需求决定架构， 其余需求验证架构。也就是说，“关键需求决定架构”和“全面认识需求”的策 略是不矛盾的。非关键需求可以用来验证架构，比如以架构方案评审的方式，从每项非关键 需求的角度对架构方案进行走查。问题三：认为软件架构必须是完美的技术解决方案。关于这一点，Philippe Kruchten 在他的论文CommoMisconceptions aboutSoftw

8、are Architecture 中明确地进行了批评，并指出架构“够用就好”：通常，在进行系统架构设计时，时间非常关键。架构师根本没有时间去系统 地研究每一种可能的解决方案，以找出最佳解决方案；而是必须快速决策，以便 让软件开发工作进行下去。项目开发就像一场“战斗”，如果慢慢吞吞地研究出 了最佳解决方案，只怕整场“战斗”早已结束多时了， 这显然毫无意义。我经常 这样描述架构师的工作：在有些事情并未完全清楚的情况下，快速做出一系列并 不算完美的设计决策。架构并不是静态功能，因此无法优化至最佳一一无论是设 计约束，还是棘手问题，都不会长时间不变而“等”你找到最佳方案。 架构不是 要完美，而是要足够

9、满意。622 关键需求决定架构采用关键需求决定架构的方法，其好处有二：一曰防守，二曰进攻。说到“防守”，多少有些“不得不为”的意味。的确如此。一方面，把所有需求统统确定下来之后再开始下游活动是不现实的。需求来自于实践的需要，而实践是发展的，所以“确定的需求”只能是暂时的。于是， 我们不得不在“部分需求已确定”的情况下进行架构设计。另一方面，项目何时交付往往是由客户业务的需要决定的， 或者是由市场形 势决定的，这使得项目工期成了不可改变的“外部限制”（上市时间是一种非功能需求）。时间有限，我们不得不在就项目的业务目标及核心需求达成共识之后 开始架构设计，而这时需求并未完全清晰化。至于“进攻”就是

10、对期望目标的“主动追求”了。 我们希望追求的目标有两 个：第一，用有限的精力深入分析最为重要的需求。人的思维能力所能应对的复 杂性是有限的，因此人们总是有意识地将问题分解、 化简和转换。当我们把全部 精力放在相对少的需求上时，可以更为深入地分析这些需求，有利于得到透彻的 认识，从而设计出合理的架构。第二，因为需求是“促成设计决策的因素”， 因此需求的变更可能会引起架 构设计不再适合。因此，我们希望能通过所有需求的一个子集来“驱动”我们的 架构决策过程，这样可以减少需求变更对架构设计方案带来的冲击， 使架构设计 趋于稳定。如图6-1所示。壽求捕获販穎认识蛮更12 需求捕获 畫新认识块定架构锻址舉

11、构设计图6-1关键需求决定架构，其余需求验证架构特别是，功能需求的数量是相当巨大的；通过选取不到20%勺典型功能需求, 进行有重点的深入分析来带动架构设计， 可以节约很多时间。如果再考虑到需求 变更的问题，在架构设计期间80%勺功能需求的变更都不会对架构设计的推进造 成冲击，这太有诱惑力了；毕竟，架构设计之时一般难以达到所有需求都稳定的 状态。6.3 确定关键需求在软件过程中所处的位置6.3.1对架构关键的需求vs.需求优先级在软件过程上游的需求分析活动中，我们有必要识别并记录需求的优先级，这对项目管理乃至控制交付范围等都有重要影响。那么，项目经理所关心的需求优先级和软件架构师所关心的对架构关

12、键的需求之间，到底是什么关系呢？图”以蔽之。如图6-2所示，高优先级的需求和对软件架构关键的需求之间，既有区别又有联系ff离代先级的靈从対戟件架构功能霜卓邮甘关键前11求图6-2对架构关键的需求vs.需求优先级一个事物是否关键、是否优先考虑，要视具体目标不同而定。我们通常所说 的“需求优先级”是针对客户而言的（同时要从技术角度考虑需求之间的依赖关 系），而本章的主题“对软件架构关键的需求”是对架构设计的影响而言的，请读者注意区分。需求优先级主要是针对功能需求而言的，除却被依赖的需求应当优先实现之外，需求优先级主要反映了客户希望最终系统提供某功能需求的迫切程度。一般而言，需求优先级可以分为三级：

13、高优先级。必不可少的功能。只有在这些需求上达成一致意见，软件才可能 被接受。这些功能的实现质量必须趋于完美;中优先级。必要的功能。这些功能是系统所需要的，如果有必要可以延迟实 现。虽然不提供这些功能系统也有可能被接受， 但最好不要忽略它们。值得为这 些功能的质量付出努力；低优先级。锦上添花式的功能增强。低优先级的需求可以实现也可以不实现； 但如果资源允许的话，实现这些需求将会使产品更臻完美。 另外，对于这些需求 的实现质量要求不是很高，甚至可以容忍不严重的缺陷存在。鉴于此，我们也就不难理解，一个项目中，需求优先级为高、中、低的需求 的比例应该科学（比如3:4:3 ），从而有利于项目管理。如果将

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

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

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

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

18、达到高要求比较困难。例如，“互操作性”需求往往给“安全性”需求造成 威胁，而为了满足“高性能”需求，往往需要使用特定平台的非标准能力， 这势 必影响了系统的“可移植性”，不一而足。于是，我们自然应该权衡哪一 部分质量属性是架构设计的重点目标。综上所述，对架构至关重要的质量属性需求是那些经过权衡取舍、最终决定重点 支持的质量属性需求。643 关键的商业需求商业需求又称业务需求（其实对应的英文都为 Business Requirement ）。 一般情况下，商业需求指“组织或客户高层次的目标”。但作为“架构设计驱动因素”的商业需求有着更宽泛的含义：它关注从客户群、企业现状、未来发展、 预算、立项、

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

20、动与便携支持哪些协议、哪些客户端是否按产品线进行规划可移植性企业现状遗留系统的集成互操作性因素分类因素对架构的影响企业人员和部门分布分布式系统架构可维护性、安全性未来发展期望的系统生存期可伸缩性、可扩展性、可移植性续表因素分类因素对架构的影响可重用性阶段性计划可伸缩性、可扩展性、可移植性可扩展性法律法规可修改性、可维护性其他因素技术选择竞争对手易用性6.5 如何确定对软件架构关键的需求图6-6展示了确定对软件架构关键需求的步骤，下面我们将一一讨论图6-6确定对软件架构关键需求的步骤6.5.1全面整理需求软件架构师为了确定关键需求，他需要全面整理需求，从而对需求建立通盘认识。为此，软件架构师可能

21、需要：研究愿景和范围文档研究软件需求规格说明书参加需求讨论会询问客户、用户、领域专家、系统分析员大多数情况下需求文档未必有软件架构师需要的所有信息，例如易扩展性、 易测试性等开发期质量属性往往是软件需求规格说明书相对薄弱的环节，所 以软件架构师必须通过通盘理解需求，将缺失的、隐含的需求找出来。如果条件允许，软件架构师应该多参与需求活动，这样更有利于把握需求的 轻重缓急6.5.2分析约束性需求对约束性需求进行分析非常有必要，因为很多约束之中“藏”着一些隐含的 需求，我们必须将它们找出来。总体而言，约束性需求可能通过三种途径影响设计（如图6-7所示）图6-7 约束性需求影响设计的三种途径直接制约设

22、计决策。例如，“系统运行于 Linux平台之上”作为一条约束, 架构师直接遵守即可；转化为功能需求。例如，“本银行系统必须严格执行人行统一规定的利率” 是一条约束，但分析后发现，正是它引出了一条功能需求：即必须提供调整利率 设置的实用功能；转化为质量属性需求。例如，有经验的系统分析员发现了一条重要约束：要开发的软件系统的预期用户计算机水平普遍不高。由此，未来的软件系统必须具 有很高的易用性（否则不会用）和鲁棒性（否则可能把系统搞瘫痪了）就是非常 必要的啦。6.5.3 确定关键功能需求如何确定关键功能需求？对此,Per Kroll和Philippe Kruchten在Rational统一过程实践

23、者指南中所论述的相当令人信服（或许读者需要一点RUP知识基础）：在初始阶段，应该确定出一些（大概占总数的20疥30%对系统起关键作用的用例。这些用例通常对创建架构具有重要影响。A. 作为应用程序的核心或实现了系统的主要接口的功能，因此，对系统架 构有很重要的影响。通常系统架构师通过分析冗余的管理策略、资源互斥风险、 性能风险和数据安全风险等来识别出哪些用例是最重要的。例如，在销售系统中，从信用卡划账和支付是最主要的用例，因为它是与信用卡确认系统的接口，它的负载和性能特性也很重要。B. 必须被实现的功能。这些功能反映了系统的本质，如果这些功能不能实现，那么开发出的应用程序就没有价值了。 通常领域

24、专家和相关方面的专家知道 用户最需要哪些功能（主要行为、数据处理的峰值和关键的控制操作等）。比如， 如果没有接受订单的功能，就不能实现一个订单发布系统。C. 覆盖了系统架构的一些方面，但没有被其他重要的用例覆盖到的功能。要确保解决所有主要技术风险，就必须全面了解系统的每个方面。否则，即使架 构中的某个方面看起来没有重大风险， 但是在设计、实现和测试时就很有可能发 现这个部分中潜伏着巨大的技术风险。读者还要识别用户需求中的一些难于实现的、未知的或者存在风险的元素（也许包括一些非功能性的元素），并且要找到一些用例（或者用例的一部分）来说明当前遇到的困难以及解决方案的风险。 在这个过程中，通常会有一

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