有什么样的认识，就有什么样的行为。《心智模式》一再强调正确认识对正确实践的作用。

从“用例驱动”到“需求驱动”

主动思考以下2种说法是否正确：

1.架构设计是功能需求驱动的，对吗？

2.架构设计是用例驱动的，对吗？

说法1，错误。因为，架构设计的驱动力 = 功能 + 质量 + 约束。

说法2，同样错误。用例技术是功能需求实际上的标准，用例技术涉及、但无法全面涵盖非功能需求。所以，说法2和说法1其实并无本质区别。

总之，“用例驱动的架构设计”这种观点有严重缺陷：

• 需求 = 功能 + 质量 + 约束
• 用例是功能需求实际上的标准
• 用例涉及、但不涵盖非功能需求

纵观业界，有不少书持“用例驱动的架构设计”的观点，例如《Rational统一过程：实践者指南》一书（本文献英文书名为《Rational Unified Process Made Easy: A Practitioner's Guide to the RUP》）。书中有一节名为“使用对架构重要的用例来驱动架构设计（Use Architecturally Significant Use Cases to Drive the Architecture）”，其中写道：

对架构重要的用例驱动了架构设计。对大多数系统而言，你通过选择仅仅20%至30%的用例，然后设计、实现并测试每个用例的一两个场景，就能够降低大部分技术风险、并驱动架构的实现。为了实现某个特定用例，你要识别出那些支持用例功能的必要软件元素（Architecturally Significant Use Cases Drive the Architecture. For most systems, you can drive out a majority of technical risks and drive the implementation of the architecture by choosing the right 20 to 30 percent of use cases, and designing, implementing, and testing one or two scenarios for each use case. To implement a given use case, you need to identify which software elements are required to provide the ality of that use case.）。

实际中，也有实践者误认为概念架构就是只考虑功能、而设计出来的理想化架构。其实，这是关于概念架构的最大误解，实践中应当注意避免。

回顾历史：经典4+1视图不是“用例驱动”，而是“场景驱动”

Philippe Kruchten较早的图，+1视图是场景视图，而不是用例视图。

场景≠用例。简要而言：

• 有书上说，场景就是用例，此观点错误。
• 用例是能给外部角色带来可见价值的交互序列，1个用例 = N个场景。
• 用例是功能需求实际上的标准，它不能全面涵盖系统的非功能需求。
• 场景既可以是功能场景，也可以是非功能场景。

用例技术，覆盖面比场景小得多。本质而言，用例是场景的一种应用。但反过来，场景可用于很多其他方面：架构评估（例如ATAM方法）、架构设计（例如目标-场景-决策表方法）、业务需求……不一而足。

所以，4+1视图方法的“+1视图”从“场景视图”变成了“用例视图”令人百思不解。……莫非乃商业因素使然（Use Case是RUP的重要商业标签）？

从“需求驱动”到“质疑驱动”

需求驱动的说法，不太传神——当你很清楚需求却依然设计不出架构时就足以说明“需求驱动的架构设计”的总结还“缺点儿什么”。

架构设计是一门艺术，你不可能把“一桶需求”倒进某台神奇的机器然后等着架构设计自动被“加工生产”完毕，因此“需求驱动的架构设计”的总结给架构师的启发不够。

缺点儿什么呢？答案是，缺“人的因素”、“架构师的因素”！

架构设计实际上是个“质疑驱动的过程”： 

在保留“需求驱动的架构设计”所有正确内涵的同时，“质疑驱动的架构设计”告诉架构师：你的头脑，才是架构设计全过程的发动机。质疑意识，是架构师最宝贵的意识之一。

一图总结