确定对架构的关键需求Word格式文档下载.docx
《确定对架构的关键需求Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《确定对架构的关键需求Word格式文档下载.docx（15页珍藏版）》请在冰点文库上搜索。
勿在浮沙筑高台。
倘若作为架构设计重要依据的软件需求变化了，你建起的软件架构这个“高台”岂不是要倒塌？
杰拉尔德·
温伯格的话让人更深刻地体会到了“运筹帷幄”应有的含义，他说：
“关键性的第一步是缩小范围……”
6.1.4
要择战而斗
穷兵黩武还是择战而斗，这或许不是问题，因为我们已经倾向于择战而斗了。
但问题在于，择战而斗怎么个“择”法。
PeopleSoft公司的首席技术官RickBergquist说得精辟：
“我的第一个老板JohnGrillos曾说过，要择战而斗。
择战的标准如下：
它们要具有重要性，它们要具有可能性，它们的数量要少。
6.1.5
功能、质量和商业需求的某个集合塑造了构架
方向已经明确了，不是吗？
软件架构师要着重深入分析的是软件需求的一个子集，再结合自己的经验，最终设计出软件架构。
卡内基梅隆大学软件工程研究所的LenBass指出：
“功能、质量和商业需求的某个集合‘塑造’了构架。
我们把这些塑造需求称为‘构架驱动因素’。
……知道了构架驱动因素后，就可以开始构架设计了。
6.2
关键需求决定架构
6.2.1
实践中的常见问题
在从需求工作向架构设计工作转移的环节上，我们在实践中暴露出一些问题。
对于软件架构师而言，这些问题在一定程度上相当普遍，所以我们一起来解决它们。
问题一：
抱怨留给架构设计的时间太短，而不是接受项目节奏普遍加快的现实。
从根本上讲，这是没有意识到软件开发所根植于的业务背景——当然，我相信或多或少也受到瀑布模型的影响。
无论是对于企业业务还是个人业务，在复杂和高速变化的经济环境里，在对手云集的竞争条件下，软件系统“上马”太慢本身就潜藏着巨大风险。
在《非程序员》第50期中有一篇来自MarkusVö
lter和JornBettin的论文《模型驱动软件开发模式》，其中强调新的商业应用的开发期最多不得超过9个月：
……
每三个月至少要提供可交付代码。
理想情况下，每三个月应将代码部署到产品中，并得到实际反馈。
新的商业应用的开发，必须在九个月之内“哇哇坠地”，否则就可能危及“妈妈”（开发组）或“婴儿”（应用）的生命……
问题二：
认为必须详细分析所有的需求，只有这样才能设计出满足所有需求的软件架构
有仗就打、有人讨敌骂阵就出战，这种情形在历史小说里经常见到，但往往出现在有勇无谋的武将身上。
与此类似，想要将所面对的所有需求都分析一遍的软件架构师是否想过：
这是否现实？
在有限的时间里，将精力分散在过多的问题上，其结果往往是效果更差。
我们的策略是：
关键需求决定架构，其余需求验证架构。
顺着“全面认识需求”的策略思考开去，很容易让人产生疑问：
你是在说瀑布式开发吗？
当然不是。
在架构设计期间，关键需求决定架构，其余需求验证架构。
也就是说，“关键需求决定架构”和“全面认识需求”的策略是不矛盾的。
非关键需求可以用来验证架构，比如以架构方案评审的方式，从每项非关键需求的角度对架构方案进行走查。
问题三：
认为软件架构必须是完美的技术解决方案。
关于这一点，PhilippeKruchten在他的论文《CommonMisconceptionsaboutSoftwareArchitecture》中明确地进行了批评，并指出架构“够用就好”：
通常，在进行系统架构设计时，时间非常关键。
架构师根本没有时间去系统地研究每一种可能的解决方案，以找出最佳解决方案；
而是必须快速决策，以便让软件开发工作进行下去。
项目开发就像一场“战斗”，如果慢慢吞吞地研究出了最佳解决方案，只怕整场“战斗”早已结束多时了，这显然毫无意义。
我经常这样描述架构师的工作：
在有些事情并未完全清楚的情况下，快速做出一系列并不算完美的设计决策。
架构并不是静态功能，因此无法优化至最佳——无论是设计约束，还是棘手问题，都不会长时间不变而“等”你找到最佳方案。
架构不是要完美，而是要足够满意。
6.2.2
采用关键需求决定架构的方法，其好处有二：
一曰防守，二曰进攻。
说到“防守”，多少有些“不得不为”的意味。
的确如此。
一方面，把所有需求统统确定下来之后再开始下游活动是不现实的。
需求来自于实践的需要，而实践是发展的，所以“确定的需求”只能是暂时的。
于是，我们不得不在“部分需求已确定”的情况下进行架构设计。
另一方面，项目何时交付往往是由客户业务的需要决定的，或者是由市场形势决定的，这使得项目工期成了不可改变的“外部限制”（上市时间是一种非功能需求）。
时间有限，我们不得不在就项目的业务目标及核心需求达成共识之后开始架构设计，而这时需求并未完全清晰化。
至于“进攻”就是对期望目标的“主动追求”了。
我们希望追求的目标有两个：
第一，用有限的精力深入分析最为重要的需求。
人的思维能力所能应对的复杂性是有限的，因此人们总是有意识地将问题分解、化简和转换。
当我们把全部精力放在相对少的需求上时，可以更为深入地分析这些需求，有利于得到透彻的认识，从而设计出合理的架构。
第二，因为需求是“促成设计决策的因素”，因此需求的变更可能会引起架构设计不再适合。
因此，我们希望能通过所有需求的一个子集来“驱动”我们的架构决策过程，这样可以减少需求变更对架构设计方案带来的冲击，使架构设计趋于稳定。
如图6-1所示。
图6-1
关键需求决定架构，其余需求验证架构
特别是，功能需求的数量是相当巨大的；
通过选取不到20%的典型功能需求，进行有重点的深入分析来带动架构设计，可以节约很多时间。
如果再考虑到需求变更的问题，在架构设计期间80%的功能需求的变更都不会对架构设计的推进造成冲击，这太有诱惑力了；
毕竟，架构设计之时一般难以达到所有需求都稳定的状态。
6.3
确定关键需求在软件过程中所处的位置
6.3.1
对架构关键的需求vs.需求优先级
在软件过程上游的需求分析活动中，我们有必要识别并记录需求的优先级，这对项目管理乃至控制交付范围等都有重要影响。
那么，项目经理所关心的需求优先级和软件架构师所关心的对架构关键的需求之间，到底是什么关系呢？
一“图”以蔽之。
如图6-2所示，高优先级的需求和对软件架构关键的需求之间，既有区别又有联系。
图6-2
一个事物是否关键、是否优先考虑，要视具体目标不同而定。
我们通常所说的“需求优先级”是针对客户而言的（同时要从技术角度考虑需求之间的依赖关系），而本章的主题“对软件架构关键的需求”是对架构设计的影响而言的，请读者注意区分。
需求优先级主要是针对功能需求而言的，除却被依赖的需求应当优先实现之外，需求优先级主要反映了客户希望最终系统提供某功能需求的迫切程度。
一般而言，需求优先级可以分为三级：
高优先级。
必不可少的功能。
只有在这些需求上达成一致意见，软件才可能被接受。
这些功能的实现质量必须趋于完美；
中优先级。
必要的功能。
这些功能是系统所需要的，如果有必要可以延迟实现。
虽然不提供这些功能系统也有可能被接受，但最好不要忽略它们。
值得为这些功能的质量付出努力；
低优先级。
锦上添花式的功能增强。
低优先级的需求可以实现也可以不实现；
但如果资源允许的话，实现这些需求将会使产品更臻完美。
另外，对于这些需求的实现质量要求不是很高，甚至可以容忍不严重的缺陷存在。
鉴于此，我们也就不难理解，一个项目中，需求优先级为高、中、低的需求的比例应该科学（比如3:
4:
3），从而有利于项目管理。
如果将需求优先级统统定为高，或者需求优先级为高的需求明显占了压倒性的比例，这显然是不科学的做法，违背了设定需求优先级的初衷，不利于项目管理中权衡与调整。
鉴于项目管理不是本书的主题，对此我们不再展开讨论。
总之，可以这么说，需求优先级是项目经理的一种权衡和决策的工具（如图6-3所示）。
该工具使项目经理可以在一定程度上获得对项目管理的灵活调整的余地，为了在项目的时间、成本和质量要求范围内顺利完成目标，对项目所提供的功能范围（Scope）进行调整。
图6-3
需求优先级是项目经理的一种权衡和决策工具
6.3.2
关键需求对后续活动的影响
确定了对架构关键的需求之后，软件架构师下面的活动将主要针对这些关键需求展开（如图6-4所示）：
无论对于概念性架构的设计（第14章），还是实际架构的设计（第16章），都需要对关键用例进行分析。
此时将采用鲁棒图等用例分析技术，最终将各鲁棒图进行综合，得到整体的软件系统职责划分模型（也被称为逻辑设计模型或分析模型）；
质量属性分析中，采用“质量属性—场景—决策”表等技术手段，分析质量属性要求，制定架构级设计决策；
当然，经过质量属性分析之后得到的架构决策，可能引起软件系统职责划分模型的调整。
以高性能设计为例，无论是“对消息采用多线程并发处理”还是“将图片服务器独立出来以便进行专门的缓存和索引等加速处理”都需要对软件系统职责划分模型进行细化等调整。
图6-4
关键需求与后续活动
6.4
什么是对软件架构关键的需求
对软件架构关键的需求包括功能需求、质量（属性）需求、商业需求三类，下面一一讨论之。
6.4.1
关键的功能需求
任何功能需求，都是由一条特定的“模块协作链”完成的。
所谓软件架构就是关于如何构建软件的一些最重要的设计决策，这些决策往往是围绕将系统分为哪些部分、各部分之间如何交互展开的。
而一个完整的软件功能的实现，则需要这些不同的“部分”之间相互配合，形成一条“模块协作链”，从而才能满足一个完整的应用功能。
控制权在模块协作链中来回传递，而功能需求就相当于串起不同模块的线索（如图6-5所示）。
图6-5
功能需求与模块协作链（参考《AOSD中文版》）
所以，所谓对软件架构关键的功能需求，就是它涉及（或串起）的模块最多、最典型的功能需求。
毕竟，由于功能需求数量众多，其实会有很多功能需求的完成所涉及的“模块协作链”都非常相似。
软件架构师通过分析少数关键的功能需求，往往就可以完成一般性的模块划分、职责分配、协作机制定义等和功能需求密切相关的架构设计工作。
6.4.2
关键的质量属性需求
要达到高质量属性要求，是有成本的。
例如，持续可用性的成本最为明显，它往往要求通过硬件及网络连接的冗余来实现，使成本投入非常可观。
因此，现实中一般应慎重考虑对哪些质量属性提出高要求。
另一方面，不同质量属性之间往往具有相互制约性，使得有些质量属性需求同时达到高要求比较困难。
例如，“互操作性”需求往往给“安全性”需求造成威胁，而为了满足“高性能”需求，往往需要使用特定平台的非标准能力，这势必影响了系统的“可移植性”，……，不一而足。
于是，我们自然应该权衡哪一部分质量属性是架构设计的重点目标。
综上所述，对架构至关重要的质量属性需求是那些经过权衡取舍、最终决定重点支持的质量属性需求。
6.4.3
关键的商业需求
商业需求又称业务需求（其实对应的英文都为BusinessRequirement）。
一般情况下，商业需求指“组织或客户高层次的目标”。
但作为“架构设计驱动因素”的商业需求有着更宽泛的含义：
它关注从客户群、企业现状、未来发展、预算、立项、开发、运营、维护在内的整个软件生命周期涉及的商业因素，包括了商业层面的目标、期望和限制等。
目标和期望的例子很多。
例如投资开发一个软件系统的企业可能期望“业务处理能力提高50%”，产品型的软件公司可能期望“半年内该产品的市场占有率达40%”或者“半年内销售20万套”，等等。
出于商业方面考虑的限制因素五花八门，但它们往往对架构设计有很大影响。
表6-1进行了归纳总结。
表6-1
商业需求中可能的限制因素
因素分类
因素
对架构的影响
经济因素
成本收益
·
预算多少会影响架构师对技术的选择
可重用性、可维护性、可移植性
上市时间
重用程度、技术选型
通过采购模块或平台减少开发工作量
客户群
多国语言
架构对多国语言的支持
移动与便携
支持哪些协议、哪些客户端
是否按产品线进行规划
可移植性
企业现状
遗留系统的集成
互操作性
企业人员和部门分布
分布式系统架构
可维护性、安全性
未来发展
期望的系统生存期
可伸缩性、可扩展性、可移植性
续表
阶段性计划
可重用性
其他因素
法律法规
可扩展性
可修改性、可维护性
竞争对手
技术选择
易用性
6.5
如何确定对软件架构关键的需求
图6-6展示了确定对软件架构关键需求的步骤，下面我们将一一讨论。
图6-6
确定对软件架构关键需求的步骤
6.5.1
全面整理需求
软件架构师为了确定关键需求，他需要全面整理需求，从而对需求建立通盘认识。
为此，软件架构师可能需要：
研究《愿景和范围文档》
研究《软件需求规格说明书》
参加需求讨论会
询问客户、用户、领域专家、系统分析员
大多数情况下需求文档未必有软件架构师需要的所有信息，例如易扩展性、易测试性等开发期质量属性往往是《软件需求规格说明书》相对薄弱的环节，所以软件架构师必须通过通盘理解需求，将缺失的、隐含的需求找出来。
如果条件允许，软件架构师应该多参与需求活动，这样更有利于把握需求的轻重缓急。
6.5.2
分析约束性需求
对约束性需求进行分析非常有必要，因为很多约束之中“藏”着一些隐含的需求，我们必须将它们找出来。
总体而言，约束性需求可能通过三种途径影响设计（如图6-7所示）。
图6-7
约束性需求影响设计的三种途径
直接制约设计决策。
例如，“系统运行于Linux平台之上”作为一条约束，架构师直接遵守即可；
转化为功能需求。
例如，“本银行系统必须严格执行人行统一规定的利率”是一条约束，但分析后发现，正是它引出了一条功能需求：
即必须提供调整利率设置的实用功能；
转化为质量属性需求。
例如，有经验的系统分析员发现了一条重要约束：
要开发的软件系统的预期用户计算机水平普遍不高。
由此，未来的软件系统必须具有很高的易用性（否则不会用）和鲁棒性（否则可能把系统搞瘫痪了）就是非常必要的啦。
6.5.3
确定关键功能需求
如何确定关键功能需求？
对此，PerKroll和PhilippeKruchten在《Rational统一过程实践者指南》中所论述的相当令人信服（或许读者需要一点RUP知识基础）：
在初始阶段，应该确定出一些（大概占总数的20%至30%）对系统起关键作用的用例。
这些用例通常对创建架构具有重要影响。
A.作为应用程序的核心或实现了系统的主要接口的功能，因此，对系统架构有很重要的影响。
通常系统架构师通过分析冗余的管理策略、资源互斥风险、性能风险和数据安全风险等来识别出哪些用例是最重要的。
例如，在销售系统中，从信用卡划账和支付是最主要的用例，因为它是与信用卡确认系统的接口，它的负载和性能特性也很重要。
B.必须被实现的功能。
这些功能反映了系统的本质，如果这些功能不能实现，那么开发出的应用程序就没有价值了。
通常领域专家和相关方面的专家知道用户最需要哪些功能（主要行为、数据处理的峰值和关键的控制操作等）。
比如，如果没有接受订单的功能，就不能实现一个订单发布系统。
C.覆盖了系统架构的一些方面，但没有被其他重要的用例覆盖到的功能。
要确保解决所有主要技术风险，就必须全面了解系统的每个方面。
否则，即使架构中的某个方面看起来没有重大风险，但是在设计、实现和测试时就很有可能发现这个部分中潜伏着巨大的技术风险。
读者还要识别用户需求中的一些难于实现的、未知的或者存在风险的元素（也许包括一些非功能性的元素），并且要找到一些用例（或者用例的一部分）来说明当前遇到的困难以及解决方案的风险。
在这个过程中，通常会有一些技术性风险转移到系统架构的基础部分中。
例如，如果系统对时间响应特性或负载特性有特殊的要求，就要识别出一个用例（或者用例的一个事件流）来说明这个需求，同时还要表现出对特性的要求。
还有其他一些例子，比如错误恢复策略和系统初始化策略等。
最后，还要识别出这样的一些用例：
它们既不会对系统架构产生重要影响也没有技术风险，但是它们描述了尚未涉及到的系统功能。
这样，在细化阶段结束时，才能创建出体现系统要领的整体架构。
例如，要确保每个主要的“业务实体”都至少与一个核心用例交互。
6.5.4
确定关键质量属性需求
为了确定对架构设计关键的质量属性需求，需要做如下三方面的工作：
考虑为了提高要开发的软件系统受认可的程度，应着重提高哪些方面的质量属性要求
接下来，充分考虑这些质量属性的相互制约或相互促进关系，以调整不同质量属性的要求标准——例如，你可能会决定高性能要求最最重要，而可扩展性也比较重要；
同时，必须满足各种约束性需求。
升级会员 