确定对架构的关键需求

《确定对架构的关键需求》由会员上传分享，免费在线阅读，更多相关内容在工程资料-天天文库。

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

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

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

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

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

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

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