《软件架构设计》阅读

1，转自 百度百科 “MVC模式”：

http://baike.baidu.com/view/739359.htm

 

2，关键需求决定架构

软件架构师没有时间对“所有需求”进行深入分析，这是现实——大多数项目都面临项目工期的压力，软件架构师必须在一定的时间内定夺架构设计方案；否则，没有软件架构所提供的对技术的足够指导以及对分工协作的足够限制，后期的团队开发将面临巨大风险。

软件架构师没有必要对“所有需求”进行深入分析，这是策略——把大部分时间和精力花在对决定架构最重要的一部分需求上，好钢用在刀刃上，最终你设计出的软件架构的质量反而会更高；否则，所有需求的分析都不够深入，导致最终设计出的软件架构可能会流于形式。

 

3，关键性的第一步是缩小范围

PeopleSoft公司的首席技术官Rick Bergquist说得精辟：“我的第一个老板John Grillos曾说过，要择战而斗。择战的标准如下：它们要具有重要性，它们要具有可能性，它们的数量要少。”

 

4，实践中的常见问题

问题一：抱怨留给架构设计的时间太短，而不是接受项目节奏普遍加快的现实。

从根本上讲，这是没有意识到软件开发所根植于的业务背景——当然，我相信或多或少也受到瀑布模型的影响。无论是对于企业业务还是个人业务，在复杂和高速变化的经济环境里，在对手云集的竞争条件下，软件系统“上马”太慢本身就潜藏着巨大风险。在《非程序员》第50期中有一篇来自Markus Völter和Jorn Bettin的论文《模型驱动软件开发模式》，其中强调新的商业应用的开发期最多不得超过9个月：

……

每三个月至少要提供可交付代码。

理想情况下，每三个月应将代码部署到产品中，并得到实际反馈。

新的商业应用的开发，必须在九个月之内“哇哇坠地”，否则就可能危及“妈妈”（开发组）或“婴儿”（应用）的生命……

 

 

问题二：认为必须详细分析所有的需求，只有这样才能设计出满足所有需求的软件架构。

有仗就打、有人讨敌骂阵就出战，这种情形在历史小说里经常见到，但往往出现在有勇无谋的武将身上。与此类似，想要将所面对的所有需求都分析一遍的软件架构师是否想过：这是否现实？在有限的时间里，将精力分散在过多的问题上，其结果往往是效果更差。

我们的策略是：关键需求决定架构，其余需求验证架构。

顺着“全面认识需求”的策略思考开去，很容易让人产生疑问：你是在说瀑布式开发吗？当然不是。我们的策略是：在架构设计期间，关键需求决定架构，其余需求验证架构。也就是说，“关键需求决定架构”和“全面认识需求”的策略是不矛盾的。

非关键需求可以用来验证架构，比如以架构方案评审的方式，从每项非关键需求的角度对架构方案进行走查。

 

 

问题三：认为软件架构必须是完美的技术解决方案。

关于这一点，Philippe Kruchten在他的论文《Common Misconceptions about Software Architecture》中明确地进行了批评，并指出架构“够用就好”：

通常，在进行系统架构设计时，时间非常关键。架构师根本没有时间去系统地研究每一种可能的解决方案，以找出最佳解决方案；而是必须快速决策，以便让软件开发工作进行下去。项目开发就像一场“战斗”，如果慢慢吞吞地研究出了最佳解决方案，只怕整场“战斗”早已结束多时了，这显然毫无意义。我经常这样描述架构师的工作：在有些事情并未完全清楚的情况下，快速做出一系列并不算完美的设计决策。架构并不是静态功能，因此无法优化至最佳——无论是设计约束，还是棘手问题，都不会长时间不变而“等”你找到最佳方案。架构不是要完美，而是要足够满意。（Usually, time is of the essence when designing system architectures. The architects have no latitude to systematically study all possible solution paths and their combinations in order to come up with the optimal solution; they must rapidly make decisions to allow work to proceed. There is no point in coming up with the ideal solution after the battle is lost. I often describe the life of a software architect as a long and rapid succession of suboptimal design decisions taken partly in the dark. It is not a static function that we are optimizing anyway. Neither the constraints nor any parts of the problem are static enough for long enough to approach anything "optimal". Architecture is not about the optimal, or ideal; it is about the adequate, or satisfactory.）

 

5，如何确定关键需求——需求的优先级

对软件架构关键的需求包括功能需求、质量（属性）需求、商业需求三类。

所谓对软件架构关键的功能需求，就是它涉及（或串起）的模块最多、最典型的功能需求。

对架构至关重要的质量属性需求是那些经过权衡取舍、最终决定重点支持的质量属性需求。